Preserve the source application’s business rules
Loan servicing, private banking and wealth management platforms hold information people want to use in AI workflows. They also contain business rules that are easy to miss if you approach the integration as a data lookup. Having worked with those systems, I start with the supported operation and its permissions. A custom MCP server has to preserve that meaning while making the operation useful to an assistant.
MCP gives you a standard way to expose tools and resources to an assistant. It does not supply the source application's business rules. A custom MCP server is a translation layer between a useful, assistant-facing operation and the application's supported interface, and your organization owns that translation, including how identities map and what happens when the source returns something incomplete or ambiguous.
Start with one operation the business understands
The first design question is what users need to accomplish. Checking an order's fulfillment status, or a relationship manager confirming whether a client's account transfer has completed, is a better starting point than exposing every endpoint in a vendor API. A narrow operation creates clear scope for authorization, testing and explanation. It also maps to work people already do, which is where adoption actually happens.
Design for predictable behavior. Choose clear tool names, input schemas and descriptions. Define what happens when a record does not exist, belongs to another business unit or has multiple parts. The assistant should never have to guess whether an empty response means no records, denied access or an outage. Bound response sizes, handle pagination and return freshness timestamps; for a status question, an accurate as-of time often matters more than a paragraph of explanation.
Let the source system keep its authority
Use supported vendor APIs or documented integration interfaces. The absence of native MCP support is not permission to bypass an application's controls or read its database directly. Identify which account or delegated identity each operation uses and what it can actually reach. If the adapter runs as a shared service account, the design must explicitly enforce the user's narrower authority, or you have built a privilege escalation path with a friendly interface.
Avoid exposing a general query language when a small read operation will do. A tool that retrieves any object by arbitrary ID creates a much larger review than one constrained to the user's permitted accounts and a documented set of fields. In my experience, the CISO conversation goes faster when the scope is small enough to explain on one page. Security first: settle identity, permissions and data boundaries before the first user ever connects.
Keep credentials and actions on separate tracks
Credentials should never appear in model-visible arguments or results. The MCP server should obtain authority through a controlled integration path, with scopes matched to the operation. The protocol's security best practices address this boundary directly, including the risk of passing tokens through to downstream systems without validation. A working authentication demo is the start of the security review, not the end.
Treat write operations as a separate phase. Updating an order, approving a payment or sending a message needs confirmation rules, validation and protection against duplicate execution, because a network retry can become a business event if the action is not idempotent. Start read-only when that meets the need. Add actions only with a named business owner and tested recovery. Regulators and audit committees will ask who approved the first write path; have the answer ready.
Ship an integration someone owns
Acceptance testing should cover access denial, expired credentials, rate limits, partial results and changing source data, through the real client experience as well as the server interface. An adapter can pass protocol checks while presenting confusing errors to a user. Both the integration contract and the user experience need an owner before release.
Before calling the connector ready, have someone other than its original developer diagnose a failed request using the documentation. Watch where they need undocumented knowledge and fix those gaps. If more teams will build connectors, turn the useful parts into a shared review pattern and keep a catalog of supported operations. Expansion should reuse what the first implementation taught you about permissions, failure handling and support.