Gate your Mastra agent's MCP tool calls

Zero runtime dependencies; @mastra/core is an optional peer you already have.

npm i @mcp-index/mastra

Pass the mcpindex server id whose tools your agent calls. That is the whole integration.

import { Agent } from "@mastra/core/agent";
import { mcpindexGate } from "@mcp-index/mastra";

const agent = new Agent({
  id: "gated-agent",
  name: "gated-agent",
  instructions: "You are a helpful assistant.",
  model: "openai/gpt-4o-mini",
  hooks: {
    beforeToolCall: mcpindexGate({ serverId: "your-mcp-server-id" }),
  },
});

In the default warn mode you now get a log line before every tool call with the tool's trust directive, and nothing about your agent's behavior changes.

Two policies, and the default is deliberately the non-breaking one.

mcpindexGate({ serverId: "your-mcp-server-id", policy: "warn" })    // default
mcpindexGate({ serverId: "your-mcp-server-id", policy: "enforce" }) // fail-closed

• warn never blocks a call. It logs and annotates. Pure visibility.
• enforce is fail-closed: only an explicit ALLOW directive proceeds; DENY, REVIEW, and UNVERIFIED are blocked, and the model receives a short 'not cleared' message in place of the tool's output.

The mcpindex public advisory API is at verdict contract 1.1.0, and it does not yet emit ALLOW or DENY - every verdict today is REVIEW or UNVERIFIED. So today this is a visibility and early-warning tool, and warn is the sane default. enforce blocks every tool call right now, because nothing is ALLOW yet; that is correct fail-closed behavior, and it becomes a real allow-list the moment mcpindex ships ALLOW/DENY verdicts, with no code change on your side. If mcpindex is slow or unreachable, the check fails closed to UNVERIFIED rather than silently trusting.

Two more tokens worth knowing when you read honest_limits. Verdicts today are description-level, so the server's screen comes back for whatever tool name you pass, and every per-tool response says so with tool_name_not_independently_verified. And each verdict is bound to the exact registry description it judged: if that text has since been replaced, the response carries content_drift, and a clean verdict renders STALE until re-screened rather than posing as a live assessment of text the registry no longer publishes.

One thing changed in contract 1.1.0, and it affects you if you gate on expires_at. What the field means is unchanged: do not act on a verdict once it has passed. What changed is how the date is set. It used to be stamped once at screen time and left to run down, so a verdict aged out even when the server it describes had not changed at all. It is now rolled forward on read whenever the description the registry publishes today still matches the exact text the screen judged. The practical effect is that your expires_at gate fires far less often than it used to. When a window was extended by re-confirming rather than by a fresh screen, freshness_confirmed appears in honest_limits so you can tell the two cases apart in code. Confirmation only ever moves the date: it never appears on a server whose description has changed, and it cannot turn a flagged verdict clean.

Need the verdict without the hook? The client is exported.

import { TrustClient } from "@mcp-index/mastra";

const client = new TrustClient();
const v = await client.checkTool("your-server-id", "send_email");
console.log(v.directive, v.honest_limits);