Building an MCP server means you're not just shipping a tool — you're shipping a decision-maker. When an AI agent invokes your server on behalf of a user, it's acting with delegated authority. That delegation needs to be explicit, scoped, and verifiable. MCP author guidelines exist precisely to enforce this discipline before agents cause harm that users never consented to.
What MCP Author Guidelines Cover
MCP (Model Context Protocol) author guidelines set the expectations for developers who publish tools that AI agents can call. At their core, they address three questions:
- Who authorized this action? The user, not the agent, must be the source of permission.
- What exactly was authorized? Consent must map to specific operations, not blanket access.
- Can you prove it? Every consequential action should leave a verifiable record.
Guidelines also touch on data handling, error transparency, rate limiting, and graceful degradation — but consent and auditability are the hardest problems for most MCP authors to solve in practice. The rest of this article focuses there.
Why Consent Is a Core MCP Responsibility
AI agents are increasingly autonomous. They browse, send emails, book services, modify files, and call APIs — often in sequences that complete before a user even notices. The MCP protocol enables this capability, which means MCP server authors sit at the exact point where autonomous action meets user data.
Without an explicit consent layer, your server becomes a vector for unintended or unauthorized behavior. This isn't a hypothetical risk:
- A user installs an agent assistant and connects it to their calendar MCP server.
- The agent interprets a vague instruction as permission to reschedule all pending meetings.
- The MCP server executes because it received a valid tool call — no consent check happened.
This is why MCP author guidelines treat consent not as a UX nicety but as a runtime safety requirement. If your server can take irreversible or sensitive actions, it must verify that a real user explicitly approved those actions before execution.
Key Permission Principles for MCP Server Authors
Scoping Actions to Explicit User Approval
Broad permissions are a smell. If your MCP server has a send_email tool, the consent scope should not be "email access" — it should be something like send_email:on_behalf_of_user for a specific workflow or session.
Practical scoping rules:
- Define one consent scope per consequential action category.
- Tie consent to a session or time window, not indefinitely.
- Never infer expanded permission from adjacent consent (approval to read files ≠ approval to delete them).
- Expose your scope definitions in your server's manifest so consuming agents and platforms can present them clearly to users.
Agents built on LLMs — whether using OpenAI function calling, Claude tool use, or an orchestration layer — should receive scoped tokens that your server validates, not raw user credentials that grant unlimited access.
Logging and Auditability Requirements
MCP author guidelines increasingly reflect enterprise and regulatory realities. Enterprise AI teams deploying agents need to answer audit questions: What did the agent do? Who approved it? When was approval granted or revoked?
Your server should log:
- The identity of the requesting agent or session
- The specific tool or action invoked
- Whether a valid consent record existed at invocation time
- The timestamp and any relevant metadata
Logs must be immutable — append-only, tamper-evident records that can be presented in a compliance review. Storing logs in a mutable database table that anyone can UPDATE is not sufficient for enterprise deployment.
Handling Revocation Gracefully
Users change their minds. A consent granted at 9 AM may be revoked at 11 AM when the user realizes the agent's scope is wider than intended. Your MCP server must handle this scenario without breaking.
Revocation-aware server design means:
- Checking consent validity at invocation time, not just at session start.
- Returning a structured error (not a 500) when consent is absent or revoked.
- Surfacing revocation reasons to the calling agent so it can communicate clearly to the user.
- Never caching consent approvals locally in a way that outlives the user's intent.
How to Add a Consent Layer to Your MCP Server
Adding a consent gate to an MCP server doesn't require building infrastructure from scratch. The pattern looks like this:
- Define your consent scopes — map each consequential tool call to a named permission scope.
- Request consent before first use — redirect or prompt the user through a consent screen before the agent takes action.
- Receive a signed credential — after approval, obtain a signed token or JWT that encodes the approved scopes and expiry.
- Verify at runtime — your MCP tool handler checks the token before executing any action.
- Log every verification — record approvals, denials, and revocations to your audit trail.
The hard part historically has been steps 2–4: hosting a consent UI, issuing signed tokens securely, and building an audit log. That's the gap Permitly was built to close.
Using Permitly to Meet MCP Consent Standards
Permitly is consent infrastructure purpose-built for AI agents and MCP server authors. Instead of building your own consent screen, token issuance, and audit database, you drop in three lines of code and redirect your user to Permitly's hosted consent flow.
import { Permitly } from "@permitly/sdk";
const consent = await Permitly.request({
scopes: ["send_email:on_behalf_of_user"],
redirectUri: "https://yourapp.com/callback",
});
The user sees a clear consent screen describing exactly what the agent is asking to do. On approval, Permitly returns a signed JWT encoding the approved scopes. Your MCP server verifies this token at runtime before any tool executes.
Every approval, decline, and revocation is recorded in Permitly's immutable audit trail — giving enterprise AI teams the compliance evidence they need without you building logging infrastructure.
Verifying Signed JWTs at MCP Runtime
At the tool handler level, verification is straightforward:
import { verifyConsentToken } from "@permitly/sdk";
async function handleSendEmail(args, context) {
const token = context.headers["x-consent-token"];
const consent = await verifyConsentToken(token, {
requiredScope: "send_email:on_behalf_of_user",
});
if (!consent.valid) {
return { error: "CONSENT_REQUIRED", message: consent.reason };
}
// proceed with action
}
This pattern means your MCP server never executes a sensitive action without a cryptographically verified user approval. If the token is expired, revoked, or scoped incorrectly, the action is blocked and the rejection is logged — exactly what MCP author guidelines and enterprise compliance teams require.
FAQ
Do MCP author guidelines require a specific consent format or SDK? No single format is mandated, but signed JWTs with explicit scope claims have become the de facto standard because they're verifiable without a live database call. Permitly issues these automatically as part of its consent flow.
What counts as a "consequential action" that needs consent? Any action that writes, deletes, sends, or irreversibly modifies data on behalf of a user. Reading public data generally doesn't require the same gate, but any action the user couldn't easily undo should require explicit approval.
How does revocation work in practice with Permitly?
Users can revoke consent through Permitly's dashboard or your product's UI. Permitly marks the JWT as revoked server-side. Your next verifyConsentToken call returns valid: false, and the action is blocked — no code changes required on your MCP server.
Can I use Permitly with any MCP framework or orchestration layer? Yes. Permitly is framework-agnostic. Whether you're using a TypeScript MCP SDK, a Python-based tool server, or a custom LLM orchestration setup, the JWT verification step is a standard HTTP header check that works anywhere.