MCP + Grantex

Grantex for MCP Applications and Servers

Use Grantex management tools from an MCP client, or verify an agent-specific Grantex grant at an MCP tool boundary.

View Integration DocsRelease Status

How MCP authorization and Grantex fit together

MCP transport authorization

The current MCP specification defines optional OAuth-based authorization for HTTP transports. Stdio deployments obtain credentials from the host environment. This authenticates access to the MCP resource, but it does not by itself model an internal agent or delegated sub-agent chain.

Agent-specific authority

After MCP transport access succeeds, a tool can verify a Grantex grant to identify the acting agent and principal, require a narrow scope, and enforce delegation or grant-state policy before execution.

Choose the correct Grantex path

Management tools: @grantex/mcp

Expose Grantex agent, grant, token, budget, and audit-management operations to a host-configured MCP client.

Agent-specific tool enforcement

Use @grantex/sdk@0.8.2 or direct JWKS validation at the MCP tool boundary. Require the exact agent scope and check current grant state when revocation must take effect before token expiry.

Human-confirmed MCP Auth 4.1.0

@grantex/mcp-auth@4.1.0 renders consent and binds authorization to a host-authenticated human. Production deployment requires a principal resolver, durable shared state, resource binding, and configured current-grant verification.

MCP transport authorization

For HTTP transports, follow the current MCP authorization specification. Test your actual client, discovery flow, host login, and protected resource; package installation alone does not establish end-to-end interoperability.

Audit tool execution separately

Record the agent, principal, grant, tool, outcome, and timestamp at the execution boundary; a valid token is not an execution record.

Run Grantex management tools from an MCP client

npm install @grantex/mcp
{
  "mcpServers": {
    "grantex": {
      "command": "npx",
      "args": ["@grantex/mcp"],
      "env": {
        "GRANTEX_API_KEY": "set-in-the-host-environment"
      }
    }
  }
}

This configuration gives the selected MCP client access to Grantex management operations. Review the client, host, and tool permissions before exposing administrative functions.

Security boundaries to test

Issuer and audience

Reject tokens from an unexpected issuer or intended for another MCP resource.

Per-tool scopes

Require the exact scope at each protected tool, not only at session creation.

Current grant state

Use online or synchronized state when revocation must take effect before JWT expiry.

Session separation

Never use an MCP session identifier as authentication or authorization evidence.

Secret handling

Keep API keys and grant tokens in trusted host storage and redact them from logs.

Host responsibilities

Configure shared state, verified human sessions, passkey enrollment for live consent, and a current-grant verifier that fails closed on outages.

Verification, revocation, and audit boundary

This integration enforces authorization only where its wrapper or middleware is installed. Local JWT verification checks signatures and claims after JWKS retrieval; it does not prove current revocation unless the verifier performs an online state check or synchronizes revocation data.

Token verification does not create a consent record or prove that a tool executed. Use the configured authorization flow for grant decisions and add an audit integration at the execution boundary when action records are required.

Evaluate the right MCP authorization layer

Start with the current MCP transport requirements, then add agent-specific grant enforcement where the tool needs it.

Read the integration guideCompare MCP options