MCP + Intended: Governing Every Tool Call in 5 Lines of Code

MCP Is the Hot Protocol

The Model Context Protocol has rapidly become the standard for how AI agents interact with external tools and services. MCP provides a clean, typed interface for tool discovery, parameter passing, and result handling. It works with LangChain, PydanticAI, OpenAI Agents, and a growing ecosystem of frameworks.

But MCP has a governance gap. The protocol defines how tools are called. It does not define whether tools should be called. There is no built-in mechanism for authorization, risk evaluation, or audit logging. Every MCP tool call executes with whatever permissions the underlying service account has -- no policy check, no risk score, no proof.

For prototypes and development environments, that is fine. For production deployments where AI agents are making real decisions with real consequences, it is a problem.

The Governance Gap

Consider what happens when an AI agent makes an MCP tool call in a typical setup:

// Standard MCP tool call -- no governance
const result = await mcp.callTool("github.createPullRequest", {
  repo: "acme/production-api",
  title: "Refactor payment processing",
  base: "main",
  head: "ai/payment-refactor",
});

This call goes directly to GitHub. The AI agent has whatever permissions the GitHub token provides. There is no check on whether this particular agent should be creating pull requests against this particular repository. There is no risk evaluation. There is no audit trail beyond what GitHub itself logs. If the AI agent decides to create 50 pull requests in a minute, nothing stops it.

Now consider the same call with Intended:

// MCP tool call with Intended governance
const result = await meritt.mcp.callTool("github.createPullRequest", {
  repo: "acme/production-api",
  title: "Refactor payment processing",
  base: "main",
  head: "ai/payment-refactor",
});

Same interface. Same parameters. But now the call passes through Intended's authority engine before reaching GitHub. The intent is classified (MIR-100, software development, pull request creation). The risk is scored (production repository, main branch target -- elevated risk). The policy is evaluated (this agent is authorized for PR creation in non-production repos, but production repos require human approval). The decision is recorded (escalated, pending human review, evidence bundle created).

The developer experience is nearly identical. The governance difference is enormous.

Setup in 5 Lines

Here is the complete setup:

import { IntendedMCPGateway } from "@intended/mcp-gateway";

const meritt = new IntendedMCPGateway({
  apiKey: process.env.Intended_API_KEY,
  orgId: process.env.Intended_ORG_ID,
});

That is it. Five lines. The gateway wraps your existing MCP client and intercepts every tool call. Each call is submitted as an intent, evaluated against your policies, and either approved, denied, or escalated -- before it reaches the downstream tool.

What Happens Under the Hood

When the gateway intercepts an MCP tool call, it executes a four-step pipeline:

Step 1: Intent Classification

The gateway maps the MCP tool name and parameters to a MIR category. "github.createPullRequest" maps to MIR-100 (Software Development), category "pull-request-create." The classification includes the tool name, the target resource, and the action parameters.

The mapping is automatic for built-in connectors (GitHub, Jira, Salesforce, etc.) and configurable for custom tools. You can define custom mappings in a configuration file:

const meritt = new IntendedMCPGateway({
  apiKey: process.env.Intended_API_KEY,
  orgId: process.env.Intended_ORG_ID,
  mappings: {
    "internal.deployService": {
      domain: "MIR-100",
      category: "deploy",
      riskFactors: ["production", "service-restart"],
    },
  },
});

Step 2: Policy Evaluation

The classified intent is evaluated against your organization's policies. Policies can be as simple as "allow all read operations" or as granular as "deny production deployments by AI agents between 9 AM and 5 PM unless the agent has Tier 3 authorization and the deployment was pre-approved in a change management ticket."

Policies are defined in the Intended console or via the API. They reference MIR categories, risk thresholds, time windows, agent identities, and resource patterns. The policy engine evaluates all applicable policies and returns a decision: ALLOW, DENY, or ESCALATE.

Step 3: Token Issuance

If the decision is ALLOW, the authority engine issues a signed token. The token contains the decision metadata: what was authorized, which policies were evaluated, the risk score, the timestamp, and the cryptographic signature. The token is attached to the tool call as evidence of authorization.

If the decision is ESCALATE, the tool call is held in the queue. A notification is sent to the designated reviewers. When a human approves or denies the escalation, the tool call either proceeds with a token or is rejected.

If the decision is DENY, the tool call is blocked. The gateway returns a structured error to the AI agent explaining why the action was denied and what policy triggered the denial.

Step 4: Audit Recording

Regardless of the decision, the event is recorded in the audit chain. The entry includes the intent, the classification, the policies evaluated, the decision, the risk score, and the evidence bundle. The entry is hash-linked to the previous entry, creating a tamper-proof chain.

Configuration Options

The gateway supports several configuration options for production deployments:

const meritt = new IntendedMCPGateway({
  apiKey: process.env.Intended_API_KEY,
  orgId: process.env.Intended_ORG_ID,
  // Fail-closed: block tool calls if Intended is unreachable
  failMode: "closed",
  // Cache approved decisions for 60 seconds
  cacheSeconds: 60,
  // Batch mode: pre-authorize a list of intents
  batchPreAuth: true,
  // Custom agent identity for policy evaluation
  agentId: "deploy-bot-prod",
  // Timeout for authority evaluation (ms)
  evaluationTimeoutMs: 5000,
});

The `failMode: "closed"` setting is the default and the recommended configuration. If Intended is unreachable, tool calls are blocked. For development environments, you can set `failMode: "open"` -- but we strongly recommend against this in production.

Framework Compatibility

The MCP Gateway works with every major AI agent framework:

LangChain

import { IntendedMCPGateway } from "@intended/mcp-gateway";

const gateway = new IntendedMCPGateway({ apiKey, orgId });
const tools = await gateway.wrapTools(langchainTools);
const agent = new AgentExecutor({ tools });

PydanticAI

from meritt import MCPGateway

gateway = MCPGateway(api_key=os.environ["Intended_API_KEY"])
agent = Agent(tools=gateway.wrap_tools(my_tools))

OpenAI Agents

const gateway = new IntendedMCPGateway({ apiKey, orgId });
const functions = gateway.wrapFunctions(openAIFunctions);

In each case, the integration is a thin wrapper. Your existing tool definitions, agent logic, and orchestration code remain unchanged. The gateway adds governance transparently.

What It Catches

In production deployments, the MCP Gateway catches patterns that raw MCP tool calls miss entirely:

• Velocity anomalies: an agent making 10x its normal rate of tool calls
• Scope creep: an agent calling tools outside its designated domain
• Risk escalation: routine operations that shift to high-risk when combined (e.g., modifying a security group and then deploying code)
• Policy violations: actions that violate time-based, resource-based, or role-based policies
• Audit gaps: tool calls that would otherwise execute without any record

Every denied or escalated action is an incident that was prevented, not investigated after the fact.

Getting Started

Install the MCP Gateway, set your API key, and wrap your existing MCP tools. Every tool call is now governed -- classified, evaluated, and audited. No changes to your agent logic. No changes to your tool definitions. Five lines of code, and your AI agents operate under authority.

Install the MCP Gateway today. Free tier includes 5,000 governed tool calls per month.