MCP, tool calling and integrating agents with your systems

MCP is an open standard for connecting AI applications to external systems: data sources such as files and databases, tools such as search and calculation, and predefined workflows. Its own documentation compares it to USB-C, a standardised connector so that a tool built once can be used by any client that speaks the protocol. Practically, it means an integration with your CRM is built against the standard rather than separately for each assistant, which is a real saving once you have more than one. It is supported across a range of assistants and development tools, and it is a connection standard rather than a security model.

For one agent and three integrations, plain function calling is enough and adding a protocol buys you nothing. MCP starts paying when the same systems have to be reachable by several different agents or assistants, because the alternative is an adapter per pair and a maintenance burden that grows faster than the value. The decision is about how many consumers of an integration you expect, not about capability. Whichever you choose, the authorisation questions are identical, which is the more useful thing to notice: no protocol decides for you whether a call carries the user's authority or the agent's.

That the call carries an authority nobody decided on. The specific anti-pattern the protocol specification forbids is token passthrough, where a server accepts a token that was not issued for it and forwards it downstream: it breaks rate limiting and request validation, it makes the downstream logs name the wrong caller, and a stolen token turns your server into a proxy for exfiltration. The second risk is scope: broad standing permissions granted at setup because it was simpler, so a prompt injection through retrieved content or a reasoning error acts with the whole permission set rather than the task's. Both are design decisions taken in week one, and both are expensive to reverse.

By classifying the tools rather than trusting the model. Every tool is labelled by consequence and reversibility before it is exposed: read, reversible write, and irreversible or consequential action. The third class either requires a human confirmation that names what is about to happen, or is not exposed to the agent at all and is instead raised as a request for a person to execute. Write tools carry idempotency keys so a retry cannot double-post, and the boundary is written down per decision class with your second line as co-author rather than settled in a code review.

Fewer than you will be tempted to give it, and the constraint is not the model, it is your ability to state the blast radius. The protocol's own guidance on scope minimisation makes the argument well: broad permission sets granted up front expand what a stolen token reaches, make revocation disruptive enough that nobody does it, and turn consent screens into something users click through. In practice we would rather run three narrow agents with defensible permission sets than one that can do everything, and the audit trail is legible either way.

By logging the tool calls rather than the conclusions. Each call records the agent identity, the human accountable for that agent, the arguments passed, the result returned, the latency and the token cost, against the version of the tool contract in force at the time. That record answers the three questions you will be asked after any incident, which are what it was asked, what it did, and under whose authority, and it does so without an archaeology exercise. It is also the input to trajectory scoring, so the same logging pays for itself twice.

Benchmark numbers would describe our workloads rather than yours, so we publish none. Both are measurable from day one if you log them, and the drivers are known: the number of model turns, which rises with the number of tools and falls with a tighter tool set; the tokens in context on each turn, which retrieval design controls; the latency of your own systems, which is usually the dominant term and is not something a model choice fixes; and retries. Give each stage an explicit budget in the design, measure against it in the build, and our audits produce an estimated run cost per candidate workflow before anything is committed to.

The connector is an afternoon in every one of those. The authorisation model is the quarter, and it differs per system in ways that decide the architecture. Salesforce uses OAuth 2.0 against an external client app, with the JWT bearer flow or the client credentials flow for an unattended agent, and even the client credentials flow requires you to nominate an execution user whose permission sets are the real permission model. ServiceNow resolves an inbound REST call to a platform user, and that user's roles plus table, field and record-level access control rules decide everything, so the agent sees what that user would see in the interface. SharePoint and Microsoft 365 run on Entra ID, where delegated permissions intersect with the signed-in user's own access and application permissions do not, and where a certificate rather than a secret is required for app-only access to the SharePoint APIs. Snowflake is role-based with inheritance, and is retiring single-factor password authentication for service users on a published schedule that completes in the August to October 2026 window. Databricks uses OAuth machine-to-machine for a service principal with one-hour tokens scoped either to the account or to a single workspace. Workday uses an OAuth 2.0 API client registered in the tenant with scopes selected at registration, and a tenant-side security configuration behind it that you should confirm with your own administrator. Tenhaw has not built a production agentic integration into any of these six, and the delivered integration work we can point at is a document pipeline calling third-party enrichment APIs on a live insurance engagement.

It is the single most consequential design decision in an enterprise retrieval build, and it is usually taken by accident in week one. With delegated permissions the app acts on behalf of a signed-in user and its access is intersected with that user's own, so it can never return a document that person could not already open. With application permissions there is no user in the picture and no intersection: an app granted a tenant-wide read permission app-only can read every file in the organisation, which is exactly what a crawler is usually given because it is the fastest way to build an index. Between the two sit the Selected scopes, Sites.Selected and the newer Lists, ListItems and Files variants, which grant nothing when consent is given and require an explicit per-resource grant with a role of read, write, owner or fullcontrol, so all three steps have to be completed before the app has any access at all. The design that holds is Selected scopes for what may be indexed, delegated access at query time, and a test in the build pipeline where a named user who should not see a document asks the question that would surface it and the run fails if it comes back. Retrofitting this after indexing usually means rebuilding the index.

Start with none of them. That is a position rather than a finding: we have not delivered a client system on any of the five. For one agent and a handful of integrations, the native tool calling in the model API is the whole answer and a framework is a dependency you will still be carrying in year two. Where a framework earns its place, the property to buy is explicit, inspectable, resumable state, which is what a graph with checkpoints gives you and what a chain of implicit calls does not, because a trajectory you cannot reconstruct is one you cannot score, debug or explain to an auditor. On an Azure estate, Semantic Kernel is the layer closest to the platform we have actually delivered on and is what we would evaluate first, against your own tool contracts rather than against a demonstration. On multi-agent frameworks we are openly sceptical: a crew multiplies the trajectories you have to evaluate, usually before anyone has a ground-truth set for one, and most workflows sold as needing several agents are one agent with a well-designed tool list and a clear stopping rule. Whichever you pick, keep the model interface, the prompts, the tool contracts, the retrieval corpora and the evaluation sets as your assets, so they survive you replacing the thing that composes them.