Use Grantex management tools from an MCP client, or verify an agent-specific Grantex grant at an MCP tool boundary.
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.
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.
@grantex/mcpExpose Grantex agent, grant, token, budget, and audit-management operations to a host-configured MCP client.
Use @grantex/sdk@0.3.13 or direct JWKS validation at the MCP tool boundary and require the exact agent scope.
@grantex/mcp-auth@2.0.2 has process-local code storage, metadata-only consent, incomplete code handoff, and no live revocation lookup. Do not use it as the production path today.
For HTTP transports, use an established authorization server and maintained MCP SDK that implement the current protected-resource discovery and token validation requirements.
Record the agent, principal, grant, tool, outcome, and timestamp at the execution boundary; a valid token is not an execution record.
{
"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.
Reject tokens from an unexpected issuer or intended for another MCP resource.
Require the exact scope at each protected tool, not only at session creation.
Use online or synchronized state when revocation must take effect before JWT expiry.
Never use an MCP session identifier as authentication or authorization evidence.
Keep API keys and grant tokens in trusted host storage and redact them from logs.
Track the documented MCP Auth 2.0.2 limitations until a corrected release is verified.
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.
Start with the current MCP transport requirements, then add agent-specific grant enforcement where the tool needs it.