MCP Infrastructure: Connecting AI Agents Is the Easy Part

---

In a hurry? The executive brief of this article — “MCP: The Plug Is Standard. The Permissions Are Yours.” — is a four-minute read.

MCP is doing something important: it is making agent connectivity ordinary. An AI client can discover a server, inspect its tool schemas, and invoke a capability without learning another proprietary integration protocol. A product team can expose useful operations once and make them reachable from many MCP clients.

That is real progress. It also changes where the hard problem lives.

When connectivity becomes cheap, the number of possible connections grows. More agents can see more services. More external clients can reach internal capabilities. A tool that once lived behind one application UI can become callable by a model, a script, an employee assistant, a partner agent, or an automated workflow.

The strategic question is no longer only:

Can these systems connect?

It becomes:

Should this agent see this tool?
May this client call this operation on behalf of this user?
Which data can the call reach?
Which identity owns the action, and which identity funds it?
What happens if generated code is involved?
How are retries, files, costs, failures, and revocation handled?
What record proves what happened?

MCP is the protocol in the middle of those questions. It is not the answer to all of them, and it should not be forced to become one.

The official MCP architecture already puts connection permissions, security policy, consent, and authorization decisions around the protocol host. The authorization specification defines how protected HTTP resources participate in an OAuth-based flow. Those are necessary protocol boundaries. A production system still has to connect them to its own users, roles, resources, product data, agent inventories, execution boundaries, and economics.

This is the third article in KDCube's opening industry series. The first, AI Agent Infrastructure: The Runtime Around Your Framework, explains the operating layer around an agent. The second, How Companies Govern Agentic AI, follows policy to its enforcement point. MCP brings both questions into one high-growth integration surface.

01The protocol problem is being solved

Before MCP, every agent integration tended to bring its own tool definition, transport, discovery mechanism, authentication instructions, and result shape. Teams wrote adapters repeatedly. Tool providers had to choose which agent ecosystems to support. Agent builders accumulated one-off client code.

MCP creates a common contract for that exchange. Clients and servers negotiate capabilities. Servers expose tools, resources, and prompts. Tools carry names, descriptions, and input schemas. HTTP-based servers can participate in a standard authorization flow. Local servers can use a process transport.

This lowers the cost of making a capability reachable. It also makes a clean architectural separation possible:

MCP owns the interoperable conversation between client and server.

The application runtime owns why this connection exists,
who may use it, where it runs, and what it is allowed to change.

That separation matters. If every product-specific policy is pushed into the protocol layer, interoperability becomes another bespoke platform. If policy is ignored because the protocol works, connectivity silently becomes ambient authority.

The winning architecture keeps the wire standard and makes the operating context explicit.

02Every MCP strategy has two directions

An enterprise AI system participates in MCP in two independent directions.

As a consumer

Your agents call MCP servers supplied by your own teams or by external providers.

The business questions are:

• Which servers are approved?
• How are endpoints, transports, and credentials managed?
• Which agents receive which concrete tools?
• Can a user narrow the configured inventory further?
• Where does the call execute, and does unsafe code receive the credential?
• How are remote costs and returned data handled?

In KDCube this side is declared under surfaces.as_consumer. A server connection is registered once. Each agent receives a separate allow-listed view of that connection.

As a provider

Your applications expose MCP capabilities to external agents, scripts, partners, and other KDCube applications.

The business questions are different:

• Is the endpoint intentionally public, application-authenticated, or platform-managed?
• Can an external operator act for a user without becoming that user?
• Which resource, grants, and selected tools does consent cover?
• Which product records may the approved user actually access?
• Can paid work be admitted and settled before cost escapes?
• Can one connection be revoked without rotating a shared organizational key?

In KDCube this side is declared under surfaces.as_provider. An application can expose ordinary FastMCP tools directly. It does not have to adopt a KDCube-specific object model or become a named-service provider first.

                               KDCUBE RUNTIME

external MCP services                                external MCP clients
         |                                                      |
         v                                                      v
  AS CONSUMER                                              AS PROVIDER
  connection registry                                     app MCP surface
  per-agent inventory                                     auth boundary
         |                                                      |
         v                                                      v
 KDCube-hosted agents                                  KDCube app capabilities

      outbound control                                  inbound control
      what agents receive                               what clients may do

An application can use either direction or both. They should not be conflated. A company may be comfortable letting one internal agent call an external search server while being unwilling to expose any internal tool externally. Another may provide a tightly governed partner MCP API without allowing its own agents to connect to arbitrary servers.

03One server should not create one universal agent catalog

The easiest MCP configuration is often the least durable one: connect a server and expose every discovered tool to every agent.

That collapses three different decisions:

We trust this server connection.
We want this agent to know this server exists.
We authorize this agent to call every tool on it.

Those statements are not equivalent.

Consider one CRM MCP server. A research agent may need customer search and read-only account context. An operations agent may also need to update a case. A public-facing summarizer may need no CRM tools at all.

one approved CRM MCP connection
        |
        +-> research agent:   search_customer, read_customer
        +-> operations agent: search_customer, read_customer, update_case
        `-> public assistant: no CRM tools

KDCube separates connection ownership from agent inventory. Endpoint, transport, and credential references live once in the application-level MCP registry. Each configured agent receives an explicit server alias and concrete tool allow-list. The resulting model catalog contains only that narrowed view.

This has several business consequences.

First, the organization can approve one technical connection without granting equal operational authority to every assistant. Second, the same server can support several job roles without duplicated tokens and endpoints. Third, changes become reviewable: adding update_case to one agent is a policy change, not an incidental consequence of a server advertising a new tool.

Tool descriptions and annotations still matter. They help a model and client understand intent. They are not authorization. A server saying that a tool is read-only does not prove that the tool implementation, current user, or target record makes the call safe.

04Exposing MCP should not require rebuilding the product

The provider side should be equally direct.

If an application already has async domain methods such as search_reports, read_report, or create_forecast, those methods can be wrapped as ordinary FastMCP tools and exposed through one application MCP surface. The business logic remains in the domain service. MCP supplies discovery, schemas, and the call transport. KDCube supplies loading, routing, request context, configuration, secrets, observability, and the selected authorization mode.

This is an important product choice. KDCube does not require every MCP service to pass through named services. A product-specific MCP contract can remain the clearest interface:

search_reports(query, limit)
get_report(report_id)
create_forecast(request_id, assumptions)

Named services become useful when the organization wants something more than a tool collection: a reusable object realm shared by agents, generated code, widgets, scenes, and external clients. Memories, conversations, canvases, mail, or another domain can expose stable object references and a common discovery, schema, search, get, update, action, and file-hosting grammar.

That is an optional higher-level abstraction:

product-specific need
  -> ordinary app-native FastMCP tools

reusable object realm across many surfaces
  -> named-service provider
  -> optional generic named-services MCP projection

MCP remains easy in both cases. Named services add shared semantics when those semantics earn their place; they are not a toll booth in front of the protocol.

05A valid token is not a complete authority decision

MCP authorization gives protected HTTP servers and clients a standard way to obtain and present access tokens. That solves an important transport-level problem. The application still needs to know what the token means inside the product.

For an enterprise action, "the token is valid" is only the beginning:

Who is the external client?
Which user approved it?
Which exact MCP resource did that user approve?
Which grants were delegated?
Which tools were selected?
Has the connection expired or been revoked?
Can the approving user access this product record now?

KDCube supports three clear authorization owners for application-provided MCP:

The route and authorization mode are separate. A remotely discoverable MCP route can still require a managed bearer for every useful operation.

For platform-managed access, Connection Hub stores the durable grant record. That record connects a derived external actor to an approving user, a concrete resource, resource grants, selected tools, identity scope, expiry, and revocation. The bearer is a short-lived handle to that server-side authority; it is not a portable copy of the user's platform session.

On each tools/call, the runtime checks the credential issuer, the concrete resource, required grants, and the selected tool before the application tool body executes. Product storage then performs its own record-level check. A valid reports:read grant does not make a report visible if the approving user cannot read that report.

This is how consent becomes operational rather than ceremonial.

06Keep the actor and the approving user separate

Delegation creates at least two identities:

actor
  the external agent, script, or application making the call

grantor / platform subject
  the KDCube user who approved the connection and whose scoped data is used

Collapsing them loses the answer to "who actually acted?" Treating only the external client as the product user loses the answer to "whose data and policy apply?"

KDCube carries both through the managed MCP boundary. Application code receives the external delegate for provenance and the approving platform user for product scope. The caller does not choose a user_id in a tool argument. The runtime projects the accepted authority from the grant record.

The same projection can identify the economics subject. A partner agent may be the actor, while the approving user's plan or wallet funds the permitted operation. Audit records can retain both facts.

external agent
    |
    | delegated bearer
    v
managed MCP boundary
    |
    +-> actor: external agent
    +-> grantor: approving user
    +-> resource + grants + selected tool
    +-> economics subject
    |
    v
application domain check -> governed operation

07Connectivity does not answer who pays

MCP can carry a call to a free local lookup, a metered SaaS API, an expensive model operation, or a custom service priced by records, tokens, seconds, or rendered pages. The protocol envelope does not identify the price.

Three responsibilities must remain explicit:

accounting:  what service and units were used?
pricing:     what did those units cost?
economics:   may this work run, who funds it, and how is actual cost settled?

Inbound: an external agent calls your paid MCP service

A managed KDCube MCP request already carries the delegate actor and projected economics subject. A paid application operation can therefore use the same runtime economics lifecycle as chat, REST, jobs, and other paid surfaces:

verify -> reserve -> run tracked work -> settle actual usage

The organization can answer before execution whether the plan, quota, or funding source permits the operation. After execution, actual instrumented cost is settled and unused reservation is released. The external actor remains in provenance while the approved subject funds the work.

This is inbound payment control around an MCP surface. It is not a claim that MCP itself is a billing protocol.

Outbound: your agent calls somebody else's MCP service

KDCube can preserve the local request and accounting lineage around the call. It cannot infer what an arbitrary remote MCP vendor charged. If the remote cost must affect a KDCube budget, the provider integration needs an instrumented adapter that reports supported usage or actual cost.

This distinction prevents a common category error: observing that an MCP call happened is not the same as knowing its commercial cost.

08Files, credentials, and generated code need physical boundaries

An MCP tool may return a short JSON result, a large report, or a file. It may be called directly by a trusted application process or indirectly from generated code. Those cases should not inherit equal authority.

Large binary data should travel by reference or short-lived URL rather than as base64 inside a model-facing result. Search results should be bounded and paginated. Stable object or file references let the receiving application decide when bytes should be materialized.

Generated code presents a separate trust question. In KDCube's split isolated execution profile, unsafe code does not receive the MCP credential or the full application configuration. It runs without network access and sends an approved tool request through an authenticated local bridge. A trusted supervisor owns secret resolution and the actual MCP transport.

generated code executor                    trusted supervisor
no MCP token                               agent tool inventory
no network in split isolation              credential resolution
current authorized workspace    ------->   approved MCP call
                                 bounded
                                  request

The model can request an allowed tool. It cannot turn that request into ambient network or credential access. This is the same principle used throughout runtime governance: the requester proposes; the trusted boundary resolves and enforces.

09Follow one governed MCP call end to end

Consider an external financial-analysis agent that has been approved to search reports for one customer. The report search invokes an accounted embedding and may return a generated spreadsheet.

1. client discovers the MCP resource
   -> protected-resource metadata points to the authorization service

2. user signs in and approves the concrete resource and search tool
   -> Connection Hub stores actor, grantor, grants, selected tool, expiry

3. client sends tools/call with the delegated bearer
   -> runtime validates issuer, audience/resource, grant, tool, revocation

4. runtime projects actor, grantor, product user, and economics subject
   -> application code does not trust a caller-supplied owner id

5. report service checks record visibility for the approving user
   -> delegated grant and product authorization both have to pass

6. economics verifies and reserves the permitted paid work
   -> embedding/search usage is tracked in the same accountable scope

7. result returns bounded rows and a hosted file reference
   -> large bytes do not enter the model context

8. actual cost settles and structured evidence remains
   -> actor, authority, operation, usage, result, and failure state correlate

MCP standardizes steps one and three at the protocol boundary. The production runtime connects the whole journey.

10What leaders should ask about an MCP platform

The most useful evaluation questions are concrete.

Inventory

• Is a server registered once and then narrowed separately for each agent?
• Does a newly advertised server tool enter every agent automatically?
• Can administrators and users narrow capability without duplicating endpoint and credential configuration?

Inbound authority

• Is authorization bound to an exact MCP resource and concrete tool?
• Are the external actor and approving user preserved separately?
• Can one connection be revoked without rotating unrelated credentials?
• Does product storage still enforce record-level access?

Execution and data

• Which process receives MCP credentials?
• Can generated code access the network or the raw token?
• Are large files returned by reference rather than injected into model context?
• What limits apply to result size, retries, and write idempotency?

Economics and evidence

• Which paid calls are checked before execution?
• How are estimated and actual costs reconciled?
• Can the platform distinguish local accounted cost from an unknown remote MCP vendor charge?
• Which records connect actor, grantor, resource, tool, usage, and outcome?

Broad claims such as "secure MCP" or "MCP governance" are not enough. Specific answers reveal whether the control exists at the point where the action becomes real.

11MCP changes the integration operating model

The long-term value of MCP is not that every company will install more tools. It is that applications and agents can participate in a shared capability market without agreeing on one agent framework.

That makes the operating model more important, not less.

Organizations need a way to:

1. approve a connection once without granting it everywhere;
2. expose product capabilities without rewriting the domain application;
3. attach authority to concrete resources and operations;
4. preserve user, delegate, and funding identities across the call;
5. keep credentials and side effects on trusted runtime boundaries;
6. account for paid work without pretending transport equals price;
7. revoke, investigate, and evolve the connection independently of the agent framework.

These are platform responsibilities around MCP, not arguments against MCP. The protocol is most valuable when it stays interoperable and the surrounding runtime makes its use operationally honest.

12The KDCube position

KDCube treats MCP as a first-class application surface in both directions.

Under as_consumer, an application registers MCP connections once and grants each agent an explicit tool view. Existing ReAct, LangGraph, Claude Code, and custom agent integrations can consume that governed configuration through their appropriate adapters.

Under as_provider, any KDCube application can expose ordinary FastMCP tools. The application can choose intentionally public, application-owned, or Connection Hub managed authorization. Managed calls preserve delegate and grantor identity, concrete resource and selected-tool grants, revocation, and the projected economics subject before application code runs.

Named services remain optional. They add a common object grammar when domains need stable references and reusable semantics across agents, UI, scenes, and external clients. They do not gate MCP.

Accounting and economics remain explicit. KDCube can admit and settle paid work whose usage and price are known. It does not invent the cost of an opaque remote provider call. Isolated execution keeps credentials on the trusted side even when generated code requests an MCP tool.

The result is a simple strategic position:

MCP makes capabilities portable.
KDCube makes their use governable and operable.
Your application keeps the product logic.
Your agent framework keeps the agent logic.

13Start with one useful connection

The first step does not require an enterprise-wide MCP program.

For consumption, register one approved server, expose two or three concrete tools to one agent, and verify that another agent cannot see them.

For provision, wrap one existing async domain operation as a FastMCP tool. Keep it bounded. Choose the real authorization owner. If it is delegated, attach one resource grant and one selected tool. Add accounting only if the work is paid.

Then test revocation, a denied tool, a different user, a large result, and a retry. Those tests reveal more than a successful demo call.

Connecting the systems should be the easy part. Operating the connection well is where the product earns trust.

·Read more

KDCube technical foundation and builder recipes:

Related KDCube articles:

Official MCP references:

KDCube is MIT licensed. Start with the repository and govern one MCP connection end to end.