Using Mandaitor with Anthropic Claude & MCP

Module 04 · Agentic systemsInteroperability

Using Mandaitor with Anthropic Claude & MCP

Intermediate12–16 min2 prerequisites

Before you start

• Understand Mandaitor's action, resource, and mandate model.
• Basic familiarity with Claude tool use or the Model Context Protocol.

After this lesson you can

• explain how Mandaitor governs Claude tool use and MCP tool calls
• verify an MCP tool invocation against a mandate before it runs
• see why MCP makes a neutral authority layer especially valuable

Anthropic's Claude uses tool use to call functions you define, and the Model Context Protocol (MCP) standardizes how agents connect to tools and context servers. MCP is an open protocol — Anthropic originated it, but it is adopted well beyond any single provider. That is precisely why a neutral authority layer matters: an MCP tool call should be checked against a mandate no matter which model or client made it. Mandaitor is that check.

For Anthropic's own framing of what an agent is, hear it from the source: this talk distinguishes workflows (LLMs orchestrated through predefined code paths) from agents (models that dynamically direct their own process and tool use), and argues for starting simple — the same tool-call boundary this lesson teaches you to authorize.

Anthropic's Barry Zhang on the workflow-vs-agent distinction and practical agent design — the tool-call loop Mandaitor's runtime checks wrap.

Claude tool use and MCP, briefly

• Claude tool use: you pass Claude a set of tools; when it decides to use one, your application receives a tool-use request, runs your handler, and returns the result to Claude.
• MCP: instead of hard-wiring tools into one app, an MCP server exposes tools and resources over a standard protocol, and any MCP-capable client (Claude and others) can call them.

In both cases the action runs in your handler or your MCP server — the same enforcement point Mandaitor uses everywhere.

Protocol-neutral

One check, any client

Because MCP is a shared standard, the mandate check lives in the server — so every client that calls the tool inherits the same authority boundary.

Server-side gate

Verify inside the tool

The MCP server (or Claude tool handler) calls verify() before executing. The model receives the decision as a tool result.

Evidence by default

Every allowed call is provable

An ALLOW returns a signed proof. MCP tool calls become reviewable authority decisions, not opaque side effects.

The pattern in code

Wrap the tool's real work with a verification. This example is an MCP-style tool handler; the same shape applies to a direct Claude tool-use handler.

import { MandaitorClient } from "@mandaitor/sdk";

const mandaitor = new MandaitorClient({
  apiKey: process.env.MANDAITOR_API_KEY,
  tenantId: "tnt_your_tenant_id",
});

// An MCP tool the server exposes. `agentSubjectId` identifies the delegate the
// current session is acting as (e.g. resolved from the caller's credentials).
async function handleApproveInvoice(input: { invoiceId: string }, agentSubjectId: string) {
  const result = await mandaitor.verify({
    delegate_subject_id: agentSubjectId, // e.g. "construction:agent:finance-assistant"
    action: "finance.invoice.approve",
    resource: `example:invoice:${input.invoiceId}`,
    context: { channel: "mcp" },
  });

  if (result.decision !== "ALLOW") {
    // Surface a structured authorization error the model can reason about.
    return { isError: true, authorized: false, reason_codes: result.reason_codes };
  }

  const approval = await finance.approveInvoice(input.invoiceId); // real side effect
  return { authorized: true, approval, proof: result.proof }; // keep proof as evidence
}

ScenarioPlatform team

A shared MCP tool, two different clients

Your finance MCP server exposes an "approve invoice" tool. One team's Claude assistant calls it; another team's internal agent calls the same server. Because the mandate check lives in the server, both are held to the same authority boundary — a finance agent may approve invoices under a threshold, and every approval carries a signed proof. You did not have to trust each client to police itself.

Claude / MCP concept	Mandaitor concept
Tool use request	A proposed action on a resource to verify
MCP server tool	The enforcement point where verify() runs
Session / caller identity	The delegate acting under a mandate
Tool input arguments	context for the verification decision
Tool result / error	The decision + reason_codes returned to the model

Check your understanding

Why is MCP a natural fit for a neutral authority layer like Mandaitor?

• Because MCP is a shared protocol, the mandate check can live in the server, so every client that calls the tool inherits the same authority boundary.
• Because MCP replaces the need for authorization entirely.
• Because only Anthropic clients can call MCP tools, so the risk is limited.

Reveal answer

MCP standardizes tool access across clients and models. Putting the verification in the server means the authority boundary is enforced once and applies to every caller — you do not have to trust each individual client to authorize itself.

From concept to implementation

Mandaitor has a dedicated, hands-on guide for wiring authorization into MCP tool calls — use it when you move from this mental model to real code.

• MCP Authorization — the full guide to gating MCP tool calls with Mandaitor.
• Verifying Actions — the verification contract and response fields.
• Agentic Authorization and Runtime Evidence — the concept behind runtime checks and evidence.

Progress

Save your learning progress

Mark this lesson as complete to update the Academy overview without requiring an account.