MCP
A standard way for an agent to discover and call tools; LoopNow exposes workspace tools over MCP with scoped keys for Claude and Cursor.
MCP is a standard way for an agent to discover and call tools. LoopNow exposes workspace tools through MCP so clients such as Claude and Cursor can use them with scoped keys.
MCP is a standard way for an agent to discover and call tools. LoopNow exposes workspace tools through MCP so clients such as Claude and Cursor can use them with scoped keys.
All glossary terms
The short version
- The Model Context Protocol is an open, JSON-RPC 2.0 based specification for connecting an AI application to external capabilities, so that a tool written once can be discovered and called by many clients.
- It defines three roles, not two: the host application, the client inside it, and the server that exposes capabilities. One host can hold several clients, each connected to a different server.
- Servers expose tools, resources and prompts. Tools are actions the model may request, resources are read-only context the application chooses to attach, and prompts are templates a user selects.
- Authorisation for network transports runs on OAuth 2.1 with PKCE, protected resource metadata and resource indicators, so a token minted for one server cannot be replayed against another.
- MCP standardises discovery and transport, not policy. Per-tool permissions, approval gates, rate limits, cost ceilings and audit trails remain the host’s job, and most real incidents live in that gap.
- For an Indian team the protocol question is easy and the data question is not: a desktop client can pull workspace data onto a laptop, so scopes, residency and logging have to be decided before the first server is connected.
What the Model Context Protocol actually specifies
MCP is an open specification, published by Anthropic in late 2024 and maintained in public, that describes how an AI application talks to a source of tools and context. The wire format is JSON-RPC 2.0. A connection begins with an initialise handshake in which both sides declare a protocol version and a set of capabilities, and every later message is a request, a response or a notification within that negotiated envelope. That is the whole architecture. It is closer to a language server protocol for AI than to an agent framework.
The scope is deliberately narrow. MCP does not say how a model decides to call a tool, how an agent plans, how memory is stored, or how a workflow is orchestrated. It says how a capability is described, discovered, invoked and how results come back. Everything that makes an agent reliable, which is policy, evaluation, retries, idempotency and human approval, sits above the protocol and remains the responsibility of whoever builds the host.
That narrowness is the point, and it is also the source of most disappointment. A team connects three servers, watches the model call a tool successfully, and concludes that the hard part is done. The hard part has not started. What MCP removes is the integration tax: instead of writing a bespoke function-calling adapter for every model vendor and every data source, you write a server once and any conforming host can use it.
Host, client and server: three roles, not two
The most common misunderstanding is that MCP is a client and a server. It is three things. The host is the application the person actually uses: an editor, a chat client, a desktop assistant, an agent runtime. The client is a component inside the host that maintains a one-to-one connection with a single server. The server is the process or service that exposes tools, resources and prompts. A host with four connected servers holds four clients, and the model sees a merged view of what those servers offer while the host keeps them isolated from each other.
The isolation matters for security. Servers do not talk to each other. They talk to their client, and the host decides what the model is allowed to see and call. That means the host is the only place where a cross-server policy can be enforced, and it is the only place where an audit trail can be complete. A server that logs its own calls sees one slice. A host that logs nothing leaves you with fragments.
In practice, the word server is misleading. An MCP server can be a local process launched over standard input and output, in which case it is a small program running with the user’s own permissions and filesystem access. It can also be a remote HTTP service with its own identity provider. Those two deployment shapes have completely different threat models, and treating them as the same thing is how teams end up shipping a local server that can read the entire home directory.
Tools, resources and prompts are three different contracts
A tool is a callable function with a JSON Schema for its arguments and a description written for a model to read. Tools are model-controlled in the sense that the model proposes a call and the host decides whether to execute it. A resource is a piece of readable context identified by a URI, such as a file, a record or a document, and it is application-controlled: the host or the user attaches it, and the model does not go fetching on its own. A prompt is a named template with arguments that a user can select, typically surfaced as a slash command.
The distinction is not cosmetic. A read-only resource is a much smaller risk than a tool that writes. When a team wraps a database and exposes both a query tool and a table resource, they have created two paths with different guarantees, and only one of them can mutate state. If everything is exposed as a tool because tools were easier to implement, every read becomes an action, every action needs approval, and the approval fatigue destroys the value of the gate.
The descriptions are part of the interface, and they are untrusted input. A tool description is text written by whoever published the server, injected into the model’s context, and capable of influencing behaviour. It is not documentation in the ordinary sense; it is executable influence. Treat a third-party server’s description the way you would treat a third-party script on your checkout page.
Transports: standard input, and Streamable HTTP
The original specification shipped two transports. The first is standard input and output, used when the host launches the server as a child process on the same machine. It is simple, it needs no authentication because the process boundary is the security boundary, and it is what most desktop integrations use. The second was HTTP with server-sent events for server-to-client messages, replaced in a later revision by Streamable HTTP, which uses ordinary POST requests for client-to-server messages and can upgrade to a stream when the server needs to push.
The transport choice determines almost everything about the security model. A stdio server runs as the user. It can read the files the user can read, it inherits the environment, and if it is compromised the blast radius is the laptop. A remote server runs behind an authorisation server, holds its own credentials, and must be reachable over the network. The first is a local capability, the second is a third-party integration, and the second is the one that needs scopes, consent screens and revocation.
Streamable HTTP also matters for the boring reason that it survives proxies. Long-lived event streams break on corporate networks that buffer responses, and Indian enterprise networks with TLS inspection are no exception. A transport that falls back to plain request and response, and only streams when asked, is easier to operate and easier to debug. If you are building a server for internal use, start there and add streaming only where a long-running tool genuinely needs progress.
Authorisation is OAuth, and the details matter
For HTTP transports, the specification describes an authorisation framework built on OAuth 2.1. The client discovers the authorisation server from protected resource metadata, registers or identifies itself, and obtains a token through an authorisation code flow with PKCE. Two additions do most of the safety work. Resource indicators let the client ask for a token that is bound to a specific server, so a token issued for the CRM server cannot be presented to the billing server. Protected resource metadata lets the server publish where its authorisation server lives, which removes the guesswork that produced a generation of hard-coded endpoints.
The practical consequence is that scopes should be narrow and per-tool. A token that grants read access to contacts is a different object from a token that grants write access to deals, and they should not be the same grant. Where the authorisation server supports it, request the smallest scope that makes the integration useful, and let the user see what is being asked for in plain language. A consent screen that says read and write your CRM is not consent in any meaningful sense.
Revocation is the part teams forget. A token issued to a desktop client lives on a machine you do not control, and the person may leave the company. You need a way to revoke a specific grant without rotating every secret in the estate, and you need the revocation to propagate to the server’s session, not just to the authorisation server. Test the revocation path before the first user is onboarded, not after the first offboarding.
What MCP is not, and which neighbour it is confused with
MCP is not an agent framework. It has no notion of a plan, a goal, a task queue or a retry policy. Frameworks such as LangGraph or a vendor agent runtime sit above it. MCP is not a model API either: it does not define inference, tokenisation or streaming of generated text. It defines how capabilities are described and invoked, which is why the same server works with different models.
It is also not a security boundary, although it is frequently deployed as if it were. The specification tells you how to present a scope and how to authenticate; it does not tell you which tool calls a given human is allowed to make at 3pm on a Tuesday, and it does not define an approval workflow. That is host policy. A server that trusts any valid token to run a destructive tool has implemented authentication and skipped authorisation.
The nearest neighbour is ordinary function calling, which is a model-vendor-specific way to declare tools inline in a request. Function calling is simpler and has no discovery, no transport and no standard for reuse; you redeclare the same tool in every request, in every vendor’s dialect. MCP externalises that declaration into a server that many hosts can query. The other neighbour is agent-to-agent protocols, which describe how two autonomous agents delegate work to each other. MCP connects an agent to a capability. It does not connect two agents as peers, and using it for that is a category error that produces awkward architectures.
The threat model that demos leave out
The first risk is tool poisoning. A malicious or careless server writes a description that instructs the model to read a file and include its contents in a later call. The model sees this as guidance, not as an attack. The defence is not a better prompt. It is treating descriptions as untrusted, pinning the servers you allow, reviewing descriptions on change, and never letting a tool result silently become an instruction in the same context window.
The second is the rug pull. A server is approved with a harmless description and later updates the tool to do something else. Any registry or allowlist that validates once and never again is defeated by a single deploy. Pin by version and hash where the host supports it, and re-review on update. The third is the confused deputy: a server holds broad credentials and acts on behalf of any caller, so a user with narrow rights can reach data they could not otherwise see. The fix is per-user tokens, not a service account with god mode.
The fourth is the one that actually happens in Indian enterprises: an over-broad token. An integration is set up with an admin account because it was easier than building a consent flow, and six months later the token is in a config file on a laptop, granting write access to the CRM, with no expiry and no owner. That is not an MCP flaw, it is a deployment choice, and it is the one an auditor will find first.
The limits of the specification, stated plainly
The protocol does not define a standard audit record, so two hosts will log a tool call in two incompatible shapes and neither will match your SIEM. It does not define cost, quota or rate-limit semantics, which means a runaway loop is a host problem and a server has no standard way to say slow down. It does not define idempotency keys, so retrying a payment tool is a decision each implementer makes alone, usually badly. These are not criticisms of the design so much as a description of its scope, and they are the questions to ask before a procurement review.
Nor does it define approval. A host can implement a human gate, and most serious ones do, but the protocol gives you no standard way for a server to declare that a tool requires one. That declaration lives in your policy layer, keyed by tool name and argument shape. Which means the policy is only as good as its coverage, and any tool added without a matching policy rule is, by default, ungated.
The specification is versioned by date and revisions land several times a year. Any statement about what MCP does, including this one, has a shelf life. Read the changelog for the revision you are implementing, and record the revision in your architecture decision record so that a future reader knows which contract you actually built against.
Running an MCP server on an Indian Agent OS
When the workspace is the server, the first design question is what a remote client is allowed to pull. A sales manager connecting a desktop assistant to the CRM should see their own pipeline, not the whole org, and the token should encode that. Row-level authorisation belongs in the server, evaluated per request against the authenticated subject, never inferred from a workspace-wide API key. If the underlying database has row-level security, use it; if it does not, the server is the last line and has to implement the check explicitly.
The second question is residency. The DPDP Act does not impose a general localisation mandate; it permits processing abroad except in territories the government restricts by notification, while making the fiduciary responsible for the processor’s conduct. That is not permission to ignore location. If a desktop client in another country caches a customer list, the data has left your control regardless of what your primary region is. State which fields can leave the country, redact the rest at the server, and log the egress. Personal data minimisation at the boundary is cheaper than a transfer impact assessment after the fact.
The third is consent and purpose. An MCP server that exposes support tickets to a general-purpose assistant has created a new purpose for that data, and purpose limitation is a statutory principle, not a preference. Scope servers by function, name them after the purpose they serve, and keep the tool list small enough that a reviewer can read it. A server called workspace with forty tools is unreviewable, and unreviewable means ungated in practice.
Measuring an MCP deployment
Three numbers tell you whether the deployment is healthy. Tool call success rate, split by error class, because a validation error and a timeout need different fixes. End-to-end latency at p50 and p95, measured from the moment the model requests the call to the moment the result enters the context, including your own auth check. And the approval rate, meaning the share of gated calls a human accepts, because a rate near one hundred percent usually means the gate is theatre and a rate near zero means the tool is wrong.
Two more are worth tracking for cost and safety. Scope breadth, the average number of distinct scopes held by an active token, which should fall over time as integrations mature and should never include an admin scope for a read use case. And unattributed calls, meaning calls in the server log with no corresponding entry in the host audit, which should be zero. A non-zero value means some client is bypassing the path you instrumented.
Do not measure prompts or conversational quality here. Those belong to the eval suite above the protocol. What you are measuring at this layer is whether the plumbing is reliable and whether the policy is real. Mixing the two produces dashboards that nobody trusts, because a drop in tool success gets blamed on the model and a drop in answer quality gets blamed on the server, and neither claim is testable.
Worked example: exposing CRM lookups to a desktop client
A fifteen-person sales team wants its account managers to ask a desktop assistant questions about their pipeline. The naive build is one server with a database connection string, a tool called query that accepts SQL, and an API key in an environment file. It works in the demo and it is a data breach waiting for a resignation letter. Any account manager can read any deal, the key never expires, and the queries are not logged in a form anyone can audit.
The defensible build has four tools and no SQL. Get account by identifier, list my open deals, get recent activity, and draft a follow-up note. Each takes a validated argument, each resolves the caller from the token, each applies row-level scope in code, and each returns a fixed shape with fields chosen for the purpose. The draft tool is gated, because it writes. There is no tool that accepts a free-form query, because a free-form query cannot be scoped by argument inspection.
On the hosting side, the server runs in the Mumbai region, logs subject, tool, argument hash, latency and outcome for every call, and refuses any request whose token lacks an explicit scope. Revocation runs through the identity provider and propagates within a minute. The whole thing is perhaps a week of work, and most of it is the boring part: defining the four shapes, writing the scope check, and testing what happens when a user leaves. The model, in this design, is the least interesting component, which is exactly what a protocol layer should be.
Frequently asked questions
Is MCP a standard, or just an Anthropic project?
It is an open specification published with public documentation, a versioned schema and a change process, and multiple vendors ship clients and servers that implement it. Anthropic originated it, and the ecosystem now includes independent implementations. For procurement purposes, treat it as a de facto standard with a living specification, not as a ratified ISO-style standard.
Does MCP replace function calling?
No. Function calling is how a model proposes a call inside a request, and it still happens. MCP moves the declaration and the execution of those functions out of the request and into a discoverable server. In a typical host, the MCP client lists tools and converts them into the model vendor’s function-calling format. Both layers exist, and conflating them leads to design mistakes.
Can one MCP server talk to another?
Not through the protocol as specified. Servers expose capabilities to clients, and clients belong to hosts. If a server needs another capability, the host composes them, or the server calls the underlying system directly. Architectures that try to chain servers server-to-server end up rebuilding routing, authentication and audit outside the specification, which defeats the purpose.
How should I scope tokens for an MCP server?
Per user, per server, per purpose, with the narrowest scopes that make the integration useful and a revocation path that propagates to the server session. Avoid service accounts with admin rights, avoid tokens without expiry, and avoid one grant that covers both read and write. A resource indicator should bind the token to the specific server so it cannot be replayed elsewhere.
Is a stdio server safe?
It runs as the user, with the user’s filesystem and environment, so the blast radius of a compromised or malicious server is that user’s machine. That is acceptable for a server you wrote and pin, and risky for one you installed from a registry without review. Sandbox it, restrict its working directory, and never pass secrets through the environment of a third-party process.
Does MCP solve prompt injection?
No, and it can widen the surface, because a server can return content that the model treats as instructions. The protocol has no mechanism for marking a tool result as untrusted. Defence is architectural: separate reading from acting, gate writes, validate arguments against a schema, and never let a retrieved document cause a privileged call in the same turn.
What does DPDP mean for an MCP server holding customer data?
The fiduciary remains responsible for the processor, so the server operator needs a contract, a defined purpose and a retention rule. Design for minimisation: expose the fields the task needs, redact the rest at the boundary, and log access. The Act does not ban cross-border processing, but it does allow the government to restrict specific territories, so document where each field can travel.
How do I audit what an agent did through MCP?
At the host, because that is the only place with a complete view. Record the tool name, the argument hash, the resolved subject, the decision, the latency and the outcome for every call, and join it to the run trace that contains the plan and the model output. A server-side log is necessary but not sufficient, since it cannot see calls that never reached it.
Which revision should I build against?
Pin the most recent revision your clients support, and record it in your design notes, because the specification changes several times a year and transports and authorisation details have already moved. Pin the server version too, ideally by hash, and re-review the tool descriptions whenever it changes. A protocol that improves quickly is also a protocol that invalidates last year’s assumptions.