This server exposes an MCP gateway with session-context management and an identity echo probe.
context.inspect: Read the current session pack, token-tax report, session tool names, saved vs allowlisted tools, and optionally the full catalog estate with oversized flags.
context.need: Admit extra tools or named packs into the session (allow-by-need), intersected with the principal allowlist; denied requests are recorded on the ledger.
echo.ping: Echo arguments and the authenticated principal identity (id, kind, org) to verify Bearer credentials reached the tool worker; appends an audit-ledger entry but makes no network/vault/charge side effects.
Vaulted credential rotation for named inputs such as github_token, enabling credential lifecycle management on the governed MCP gateway.
Settlement rail for the agent spend & mandate plane, allowing spend proposals to settle via Stripe meter events.
The gateway uses vaulted credential storage for rotating secrets like GitHub tokens in place.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@governed-mcp-gateway @governed-mcp-gateway call echo.ping with my bearer token"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Identity, money, and evidence for agents that actually ship.
Three SKUs, one workspace. MCP clients keep a Bearer principal through tools/call and SSE. Spend cannot settle without a mandate and, over cap, a human second key. Board claims cannot seal without an agent, a CHP lock, and a hashed document.
SKU | Port | Source | Job |
| Principal on every tool call and SSE frame. Vaulted credential rotation. Tool allowlists. Schema token-tax ledger and pack / allow-by-need | ||
| this workspace | Propose → mandate → countersign → settle. Stripe by default; x402 is a rail. | |
| this workspace | Claim → agent → lock → document. ASC 842 / 606 / 718 engines. HMAC-chained evidence pack. |
Shared primitives (packages/shared): CHP gate, HMAC ledger, HTTP/SSE helpers. Zero runtime npm dependencies. Stripe and x402 are rails — tests never call live networks.
npm install
npm test
npm run gateway # :7474
npm run spend # :7475
npm run cfo # :7476Demo Bearer keys (also in .env.example):
Role | Key |
Gateway agent |
|
Gateway human |
|
Gateway research (no |
|
Spend agent |
|
Spend human |
|
CFO agent |
|
CFO human |
|
Regenerate the README cards from live local APIs:
npm run shotsRelated MCP server: production-grade-mcp-agentic-system
Production MCP drops identity. listTools runs on the request thread; tools/call and SSE run somewhere else. This gateway resolves a Bearer credential to a Principal, injects it on every JSON-RPC call, and repeats it on every SSE frame. Named vault inputs rotate in place — github_token stays github_token.
curl -sS -H "Authorization: Bearer mcp_agt_payops_demo" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"echo.ping","arguments":{"hello":"world"}}}' \
http://127.0.0.1:7474/mcpMethod | Path | What |
|
| Liveness ( |
|
| Streamable HTTP JSON-RPC |
|
| Local SSE notification with |
|
| Schema token-tax estate + session report |
|
| Admit allowlisted tools into the session pack |
|
| Human-only vault rotate; old hash dies |
|
| Check a secret against the current hash |
Glama can health-check a stateless Streamable HTTP remote at https://$VERCEL_URL/mcp with Bearer auth. This is the hosted HTTPS path. Stdio (npm run mcp / Dockerfile CMD) remains the Glama Docker build path.
Vercel project settings (import this GitHub repo; do not invent a hostname):
Setting | Value |
Root Directory |
|
Framework Preset | Other ( |
Fluid Compute | On ( |
Node.js | 20 or later |
Install Command |
|
Build Command |
|
Output Directory |
|
npm run build runs scripts/build-vercel.mjs (esbuild). That emits dist/web.mjs. api/index.mjs imports that compiled file — it does not load TypeScript via runtime tsx. Demo allowlist and oversized-schema seed are inlined in that bundle so Fluid does not open test/fixtures/ (the function only includes dist/**). The Other preset still expects a static output folder after a custom buildCommand; public/ is that folder (outputDirectory: "public"). If the Vercel dashboard still has a Build Command of tsc, clear it or set it to npm run build so TS5097 does not come back. Dashboard overrides are not required if vercel.json is honored.
Environment variables (Vercel Project → Settings → Environment Variables). Rotate the demo values before a public URL:
Name | Local demo | Role |
|
| Glama connector Bearer (PayOps allowlist) |
|
| Vault / locks |
|
| Research allowlist (no |
| unset | Optional hook to |
Glama connector fields after deploy (replace $VERCEL_URL with the deployment host Vercel prints):
URL: https://$VERCEL_URL/mcp
Transport: Streamable HTTP
Authorization: Bearer $GATEWAY_AGENT_KEY
Local smoke (no public hostname):
npm run mcp:http:smoke
# or:
npm run gateway
curl -sS http://127.0.0.1:7474/health
curl -sS -H "Authorization: Bearer mcp_agt_payops_demo" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"smoke","version":"0"}}}' \
http://127.0.0.1:7474/mcpinitialize does not mint Mcp-Session-Id. Pass params.pack / params.need on the same tools/list when you need more than the session pack. GET /mcp is 405 (no sticky SSE on the remote).
Agents propose. Mandates authorize. A human countersigns when the amount is over the auto cap. The proposing agent cannot countersign itself. Settlement is a rail: Stripe meter event by default, x402 payment-required if you ask for it. No chain calls in this MVP.
curl -sS -H "Authorization: Bearer spend_agt_payops_demo" \
-H "Content-Type: application/json" \
-d '{"agent":"agt_payops","merchant":{"name":"Stripe","url":"https://stripe.com","country":"US"},"total":"12.00","rationale":"tool meter"}' \
http://127.0.0.1:7475/v1/proposalsMethod | Path | What |
|
| Operator creates remaining-cents coverage |
|
| Agent propose; lane |
|
| Human second key; agents are rejected |
|
|
|
A board claim is not done until it has an agent, a LOCKED CHP state, and at least one source document hash. Engines measure (ASC 842 lease rollforward, ASC 606 constrained POC, ASC 718 SBC). They do not decide facts of law. Token spend attaches as a source on the same HMAC-chained ledger.
curl -sS -H "Authorization: Bearer cfo_agt_lease_demo" \
-H "Content-Type: application/json" \
-d '{"title":"AI spend is $12.00 this period","narrative":"Token ledger supports the board claim.","agentId":"agt_lease"}' \
http://127.0.0.1:7476/v1/claimsMethod | Path | What |
|
| Open a claim |
|
| Attach a named source; SHA-256 stored |
|
| Human lock → |
|
| ASC 842 classification + rollforward |
|
| Seal; |
OpenSpec changes: ship-three-sku-platform, tools-list-token-tax, glama-streamable-http-remote, vercel-compiled-fluid-entry, vercel-public-output-directory.
MIT
Read the current session pack and schema token-tax report for the authenticated principal. Returns the bytes→tokens heuristic, session tool names, savedTokens versus the full allowlist, and (unless includeEstate=false) the estate including oversized flags. Does not admit tools and does not execute other tools. Call this before context.need to see what is already loaded. Fail-closed: requires the same principal as the session.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | No | Optional session id; defaults to ses_<principalId> when omitted. | |
| includeEstate | No | When false, omit the full catalog estate and return only session tax. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses fail-closed authentication requirements, confirms no side effects ('Does not admit tools and does not execute other tools'), and specifies conditional output based on includeEstate. This is strong behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with no filler. The main purpose is front-loaded, followed by return details, exclusions, a direct usage pointer, and the auth requirement. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description explains the return contents, the conditional estate flag, the lack of side effects, and the auth constraint. It is nearly complete; only edge-case error behavior is not described, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some context by tying includeEstate to the estate report and showing how the returned data varies, but it largely restates what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Read the current session pack and schema token-tax report.' It also explicitly differentiates itself by saying it 'does not admit tools and does not execute other tools,' and names context.need as the related sibling to compare against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Call this before context.need to see what is already loaded.' It also clarifies what the tool does not do, helping an agent avoid using it for admission or execution. It does not explicitly address echo.ping, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Admit extra tools or a named pack into this session (allow-by-need). Always intersected with the principal allowlist — fail-closed. Research cannot admit stripe.charge. Does not run the admitted tools; call tools/list afterwards to see the new pack, or context.inspect to see tax. sessionId defaults to ses_. Denied names are returned in denied[] and recorded on the ledger.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | No | Named pack to admit (catalog, core, payments, research). Intersected with the allowlist. | |
| tools | No | Concrete tool names to admit (e.g. stripe.charge). Ignored when not allowlisted. | |
| sessionId | No | Optional session id; defaults to ses_<principalId> when omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden and does so thoroughly: allowlist intersection, fail-closed behavior, the stripe.charge restriction for research, non-execution of admitted tools, denied[] output, ledger recording, and sessionId defaulting are all disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. The core purpose is front-loaded, followed by restrictions, post-conditions, defaults, and failure behavior, all in a compact, readable form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description explains key return behavior (denied[]) and points to tools/list and context.inspect for further observation. It does not specify the full success response shape, but the essential operational context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the fail-closed intersection, the specific research/stripe.charge restriction, and the denied[]/ledger behavior tied to the tools parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Admit extra tools or a named pack into this session (allow-by-need).' It clearly distinguishes what the tool does from the siblings context.inspect and echo.ping by framing it as an admission action rather than inspection or echo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when extra tools or a pack need to be admitted. It also provides follow-up guidance (tools/list, context.inspect), though it does not explicitly enumerate when not to use it or systematically contrast it with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identity probe. Echoes the call arguments and the authenticated Principal the gateway injected onto this tools/call (id, kind, org). Use it to confirm Bearer identity survived onto the tool worker. Does not hit a network, mutate vault state, or charge. Idempotent except for an audit-ledger append. Not a substitute for context.inspect.
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | Optional ping payload echoed back in the result. Omit to send an empty ping. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool does not hit the network, mutate vault state, or charge, and that it is idempotent except for an audit-ledger append. This gives an agent a clear behavioral safety profile without needing structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with purpose, followed by usage guidance, side-effect transparency, and a sibling distinction. Every sentence earns its place and there is no redundant prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter tool with no output schema, the description is complete: it explains what is echoed, what authentication context is returned, when to use it, and what side effects to expect. An agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one optional parameter, message, and schema description coverage is 100%. The schema already explains that the message is echoed back and that omitting it sends an empty ping, so the description adds little beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Identity probe' and states precisely what the tool does: echoes call arguments and the authenticated Principal. It also distinguishes itself from the sibling context.inspect with the explicit 'Not a substitute for context.inspect' note, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: 'Use it to confirm Bearer identity survived onto the tool worker.' It also provides a clear when-not-to-use signal by stating it is not a substitute for context.inspect, naming the relevant alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0context.inspectcontext.needecho.pingScored across 3 tools
context.inspect is read-only session state, context.need is a mutating admission action, and echo.ping is an identity probe. The descriptions explicitly distinguish their purposes, so an agent should not confuse them.
All tool names follow a consistent namespace.action pattern: context.inspect, context.need, and echo.ping. Even though the namespaces differ, the lowercase dot-separated verb suffix style is uniform across the set.
Three tools is small but well-scoped for a governance gateway: inspect current state, request admission, and verify identity. Each tool provides a distinct, non-redundant operation that earns its place.
The core read and admit operations are covered, and built-in tools/list handles discovery, but there is no way to revoke, release, or reset previously admitted tools or packs. This creates a notable lifecycle gap for an over-admission scenario.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Hosted MCP server for AI agent identity, permissions, verification, and reusable proof.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
