Glama vs Gram (Speakeasy)

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Glama✓fullprobed8/10

   Glama serves a live llms.txt at the root (HTTP 200) describing the directory, and additionally exposes a machine-discoverable API catalog (.well-known/api-catalog) and an OpenAPI 3.0.3 spec, giving agents multiple agent-oriented discovery docs. Missing for 10: a dedicated docs-md fallback (mcp.md returns 404) and independent confirmation that agents actually consume llms.txt successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://glama.ai/llms.txt # Glama > A directory of 81,811 Model Context Protocol servers and 15,990 remote conn…”
   • [probe] “PROBE openapi (2026-09-05): GET https://glama.ai/api/mcp/openapi.json returned HTTP 200 with an OpenAPI 3.0.3 description (9 documented path…”
   • [probe] “PROBE api-catalog (2026-09-05): GET https://glama.ai/.well-known/api-catalog returned HTTP 200 with an RFC 9727 linkset naming the platform …”
   • [probe] “PROBE docs-md: HTTP 404 at https://glama.ai/mcp.md”

   proof ↗⚑ flag

   Gram (Speakeasy)✓fullprobed8/10

   Speakeasy directly hosts a working llms.txt (HTTP 200, confirmed by probe) plus a docs.md markdown-native page, meaning an agent can be pointed at agent-oriented docs formats; the docs also emphasize AI-native/agent workflows throughout (SKILL.md, platform MCP server, CLI). missing for 10: no evidence of llms.txt existing for Gram product docs specifically (only the root Speakeasy domain), and no independent/hands-on confirmation an agent actually consumed and acted on the llms.txt content.

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.speakeasy.com/llms.txt # Speakeasy > Speakeasy is the AI control plane for the AI-native enterprise…”
   • [probe] “PROBE docs-md: HTTP 200 at https://www.speakeasy.com/docs/ai-control-plane.md # AI Control Plane Documentation {/* * Renders through the …”
   • [claimed-docs] “A skill is a versioned `SKILL.md` manifest: reusable instructions that agents load on demand.”
   • [claimed-docs] “An org admin working in Claude Code, Cursor, Codex, or another MCP client can find and add MCP servers, finish their setup, put them on a pl…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Gram (Speakeasy)
   Glama!disputedcontradicted4/10

   Glama documents automation hooks (schedules/webhooks, docs-10) and exposes a live registry/platform API with an OpenAPI spec that an agent could script against in CI (glama-probe-rt-1, glama-probe-rt-2, glama-probe-rt-3), suggesting headless automation is possible. However, hands-on community reports show the automated rebuild/rescore trigger silently failed for days despite manual resyncs and API attempts, requiring an undocumented workaround (adding billing credits) to unblock — a concrete case where headless automation did not work as claimed (glama-comm-2, glama-comm-3). Missing for 10: a documented CLI or CI-specific guide, confirmation the API supports full server-management lifecycle non-interactively, and resolution of the demonstrated automation failure.

   • [claimed-docs] “Automate workflows using schedules or webhooks.”
   • [probe] “PROBE registry-api (2026-09-05): GET https://glama.ai/api/mcp/v1/servers?first=3 without credentials returned HTTP 401 with a JSON auth chal…”
   • [probe] “PROBE openapi (2026-09-05): GET https://glama.ai/api/mcp/openapi.json returned HTTP 200 with an OpenAPI 3.0.3 description (9 documented path…”
   • [probe] “PROBE api-catalog (2026-09-05): GET https://glama.ai/.well-known/api-catalog returned HTTP 200 with an RFC 9727 linkset naming the platform …”
   • [community] “After uploading a new MCP version, the quality score test wouldn't rerun for 3 days despite manual resyncs and API attempts. Turned out a cr…”
   • [community] “Neither I nor my AI agent could figure out over 4 days of searching documentation why the quality score retest wasn't triggering on the late…”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialprobed6/10

   Gram ships an official CLI (verified runnable via runtime probe) that can build/publish MCP servers and toolsets, which supports CI/headless automation, and docs confirm a working command-line reference. However, there is no explicit CI/CD pipeline documentation, no GitHub Actions example, and no headless auth/service-account guidance for unattended runs. Missing for 10: documented CI examples (e.g., GitHub Actions/pipeline configs), non-interactive/service-account authentication flow for the CLI, and independent hands-on confirmation of full automation beyond version-check.

   • [claimed-docs] “install toolsets as MCP servers in AI agents, and keep the CLI itself up to date”
   • [probe] “official CLI documented at https://www.speakeasy.com/docs/ai-control-plane/reference/command-line”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/gram/): downloaded the official cli@0.16.0 release artifact (gram_dar…”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Glama✓fullclaimed7/10

   Glama's MCP gateway explicitly routes agent tool calls through hosted/connected MCP servers, with a catalog to discover servers, an inspector to test them, and per-tool access controls — directly enabling an AI-native user to plug in MCP servers for tool use. Missing for 10: independent hands-on confirmation that agent tool-calling through the gateway works reliably end-to-end (community evidence focuses on quality-score/rebuild issues, not tool invocation itself), and no third-party review specifically validating the plug-in/tool-use flow.

   • [claimed-docs] “Test any MCP server from your browser. Supports every Model Context Protocol feature”
   • [claimed-docs] “Every MCP call from your agents flows through Glama – so you know exactly what your AI is doing, and you decide what it's allowed to do.”
   • [claimed-docs] “Per-tool access control – enable or disable individual tools”
   • [claimed-docs] “Search Glama's curated catalog of open-source servers and remote connectors, inspect their capabilities, and keep your own directory synchro…”
   • [claimed-docs] “MCP clients are the applications that connect to MCP servers.”

   proof ↗⚑ flag

   Gram (Speakeasy)✓fullclaimed7/10

   Gram documents fronting/governing third-party MCP servers ('put a governed endpoint in front of an MCP server someone else runs') and an in-dashboard harness to connect, authenticate, and chat with a model that calls tools from a connected server, plus a real-world case (MoonPay, 200+ MCP servers aggregated under the gateway). This directly satisfies plugging external MCP servers in so their tools become usable. Missing for 10: independent/hands-on verification of third-party server integration in production and more detail on tool-call fidelity across diverse upstream servers.

   • [claimed-docs] “Put a governed endpoint in front of an MCP server someone else runs, so access control, audit, and upstream credentials apply without changi…”
   • [claimed-docs] “An in-dashboard agent harness for testing MCP servers before connecting a real client: pick a server, authenticate, chat with a model that c…”
   • [claimed-docs] “MoonPay brought 200+ MCP servers under the MCP Gateway, going from proof of concept to a company-wide rollout in 30 days.”
   • [claimed-docs] “unsanctioned shadow MCP servers are blocked by default”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Gram (Speakeasy)
   Glama✓fullprobed7/10

   Glama's docs describe an official MCP gateway/hosting service through which agents connect to MCP servers, with per-tool access control, inspector testing, and a hosted catalog (glama-docs-1,4,5,6). This directly satisfies the story since Glama is a hosting/gateway platform, not an agent, so serving MCP is a core in-scope capability. Missing for 10: independent hands-on verification of an agent actually connecting through the gateway, and community feedback highlights friction in publishing/quality-score workflows (glama-comm-2,3) rather than the connection experience itself.

   • [claimed-docs] “Test any MCP server from your browser. Supports every Model Context Protocol feature”
   • [claimed-docs] “Every MCP call from your agents flows through Glama – so you know exactly what your AI is doing, and you decide what it's allowed to do.”
   • [claimed-docs] “Per-tool access control – enable or disable individual tools”
   • [claimed-docs] “Search Glama's curated catalog of open-source servers and remote connectors, inspect their capabilities, and keep your own directory synchro…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://glama.ai/llms.txt # Glama > A directory of 81,811 Model Context Protocol servers and 15,990 remote conn…”

   proof ↗⚑ flag

   Gram (Speakeasy)✓fullprobed9/10

   Gram documents and exposes an official 'Platform MCP' server that lets MCP clients (Claude Code, Cursor, Codex, etc.) connect directly, plus generates/hosts MCP servers as its core product function, and a CLI/runtime probe confirms the tooling actually installs and runs. missing for 10: independent (non-vendor) hands-on confirmation that an external agent successfully connects to and operates the Platform MCP server end-to-end.

   • [claimed-docs] “An org admin working in Claude Code, Cursor, Codex, or another MCP client can find and add MCP servers, finish their setup, put them on a pl…”
   • [probe] “official MCP server documented at https://www.speakeasy.com/docs/ai-control-plane/reference/platform-mcp”
   • [claimed-docs] “Built — the Control Plane generates the server itself from a first-party source: an OpenAPI document or a TypeScript Functions project.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/gram/): downloaded the official cli@0.16.0 release artifact (gram_dar…”
   • [claimed-docs] “An in-dashboard agent harness for testing MCP servers before connecting a real client: pick a server, authenticate, chat with a model that c…”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Gram (Speakeasy)
   Glama—none0/10

   No evidence of an official Glama CLI tool anywhere in the docs, probes, or community discussion; the product exposes web UI, APIs (OpenAPI, registry API), and a browser-based inspector, but nothing indicating a dedicated CLI for AI-native workflows.

   ⚑ flag

   Gram (Speakeasy)✓fullprobed8/10

   Gram ships an official CLI documented at reference/command-line, used to install toolsets as MCP servers and keep itself updated, and a runtime probe confirms the binary actually downloads and runs (`gram --version`). missing for 10: independent/third-party review of CLI usage beyond the vendor docs and a single runtime probe, and more detail on the full breadth of CLI commands beyond install/update.

   • [claimed-docs] “install toolsets as MCP servers in AI agents, and keep the CLI itself up to date”
   • [probe] “official CLI documented at https://www.speakeasy.com/docs/ai-control-plane/reference/command-line”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/gram/): downloaded the official cli@0.16.0 release artifact (gram_dar…”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round to Gram (Speakeasy)
   Glama~partialprobed6/10

   Glama exposes a live registry API with an OpenAPI 3.0.3 spec (9 documented paths) and a machine-discoverable API catalog via .well-known/api-catalog, confirming a real documented public API surface. However, the API requires a key and returns 401 without one, no standalone human-readable API docs page was found (mcp.md 404, openapi.json at root 404), and community feedback notes confusion even for API-based automation attempts (quality score retrigger via API failed silently). Missing for 10: a clear top-level API documentation page/portal, broader endpoint coverage beyond 9 paths, and independent confirmation of smooth API-driven workflows.

   • [probe] “PROBE registry-api (2026-09-05): GET https://glama.ai/api/mcp/v1/servers?first=3 without credentials returned HTTP 401 with a JSON auth chal…”
   • [probe] “PROBE openapi (2026-09-05): GET https://glama.ai/api/mcp/openapi.json returned HTTP 200 with an OpenAPI 3.0.3 description (9 documented path…”
   • [probe] “PROBE api-catalog (2026-09-05): GET https://glama.ai/.well-known/api-catalog returned HTTP 200 with an RFC 9727 linkset naming the platform …”
   • [probe] “PROBE docs-md: HTTP 404 at https://glama.ai/mcp.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://glama.ai/openapi.json, https://glama.ai/swagger.json, https://glama.ai/api/openapi.json, htt…”
   • [community] “Neither I nor my AI agent could figure out over 4 days of searching documentation why the quality score retest wasn't triggering on the late…”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialprobed7/10

   Gram exposes a documented Platform MCP server and CLI that let an AI-native user/agent drive the product programmatically (find/add MCP servers, author skills, manage policies, read logs) without the dashboard, and the CLI was independently verified to install and run. However, a direct probe for a conventional public REST/OpenAPI API (openapi.json, swagger.json, etc.) returned 404s, so there is no evidence of a general-purpose documented HTTP API beyond the MCP/CLI surfaces. Missing for 10: a documented REST/OpenAPI public API endpoint, independent confirmation of the Platform MCP server's functional breadth beyond docs.

   • [claimed-docs] “An org admin working in Claude Code, Cursor, Codex, or another MCP client can find and add MCP servers, finish their setup, put them on a pl…”
   • [probe] “official MCP server documented at https://www.speakeasy.com/docs/ai-control-plane/reference/platform-mcp”
   • [claimed-docs] “install toolsets as MCP servers in AI agents, and keep the CLI itself up to date”
   • [probe] “official CLI documented at https://www.speakeasy.com/docs/ai-control-plane/reference/command-line”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/gram/): downloaded the official cli@0.16.0 release artifact (gram_dar…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.speakeasy.com/openapi.json, https://www.speakeasy.com/swagger.json, https://www.speakeas…”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Gram (Speakeasy)
   Glama—none0/10

   Evidence shows per-tool access control and gateway visibility into MCP calls, but no mention of scoped/least-privilege API key issuance, credential scoping, or granular permission grants for agent credentials — the API key system found in probes appears to be a single account-level key, not scoped tokens. Missing for 10: scoped credential creation, permission/role definitions per key, evidence of least-privilege token issuance for agents.

   • [claimed-docs] “Per-tool access control – enable or disable individual tools”
   • [claimed-docs] “Every MCP call from your agents flows through Glama – so you know exactly what your AI is doing, and you decide what it's allowed to do.”
   • [probe] “PROBE registry-api (2026-09-05): GET https://glama.ai/api/mcp/v1/servers?first=3 without credentials returned HTTP 401 with a JSON auth chal…”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialclaimed6/10

   Gram supports OAuth 2.0/2.1 integration with external providers, RBAC enforced at team/server/tool level synced to enterprise IDPs, and governs upstream credentials for third-party MCP servers with shadow-server blocking — collectively enabling scoped access control for agent tool use. However, there's no explicit documentation of per-agent least-privilege token minting/vending or fine-grained scope selection at credential-issuance time; the emphasis is on gateway-level RBAC and OAuth pass-through rather than dynamically scoped credential issuance. Missing for 10: explicit per-agent credential scoping/token minting mechanism, documented least-privilege scope configuration UI, and independent verification of enforcement.

   • [claimed-docs] “you can use any OAuth 2.0 provider you have set up (such as Auth0, Okta, Keycloak, or your own OAuth server)”
   • [claimed-docs] “Put a governed endpoint in front of an MCP server someone else runs, so access control, audit, and upstream credentials apply without changi…”
   • [github] “Team, server, and tool level permissions enforced through RBAC and Oauth2.1. Synced to your enterprise IDP (Okta, Azure AD, Google Workspace…”
   • [claimed-docs] “unsanctioned shadow MCP servers are blocked by default”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to Glama
   Glama~partialprobed3/10

   Glama exposes a documented OpenAPI 3.0.3 spec and machine-discoverable API catalog that could be used to generate a client, but there is no evidence of an official first-party SDK (e.g., published npm/PyPI client library) for building against the platform. missing for 10: official SDK packages, SDK usage docs/examples, language coverage, independent confirmation of SDK reliability.

   • [probe] “PROBE openapi (2026-09-05): GET https://glama.ai/api/mcp/openapi.json returned HTTP 200 with an OpenAPI 3.0.3 description (9 documented path…”
   • [probe] “PROBE api-catalog (2026-09-05): GET https://glama.ai/.well-known/api-catalog returned HTTP 200 with an RFC 9727 linkset naming the platform …”
   • [probe] “PROBE registry-api (2026-09-05): GET https://glama.ai/api/mcp/v1/servers?first=3 without credentials returned HTTP 401 with a JSON auth chal…”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   The evidence pack documents Gram's CLI, MCP server distribution, OAuth, skills, and observability features, but nowhere mentions official client SDKs (e.g., Python/TypeScript/Go libraries) for building against Gram's platform itself — this is a fair question for a platform product but is simply unaddressed.

   ⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Glama
   Glama~partialclaimed4/10

   Glama's pricing page mentions automating workflows via 'schedules or webhooks,' indicating some webhook capability exists, but there is no documentation of a webhook subscription API, event types, payload format, or setup instructions, and no independent/hands-on confirmation. Missing for 10: documented webhook subscription endpoint or event catalog, setup/configuration guide, and community or probe evidence confirming it works in practice.

   • [claimed-docs] “Automate workflows using schedules or webhooks.”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   Gram's evidence covers MCP server generation, tool logs, CLI, and RBAC, but nothing describes webhook subscriptions or event-driven push notifications for AI agents; missing for 10: webhook subscription mechanism, event schema/documentation, or any mention of push-based event delivery.

   ⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Glama
   Glama~partialclaimed4/10

   Glama's pricing page mentions automating workflows via schedules or webhooks (glama-docs-10), which suggests background automation capability, but there is no first-party documentation detailing setup, configuration, or behavior of scheduled/webhook-triggered automations, nor any community or hands-on evidence confirming this works. missing for 10: detailed docs on schedule/webhook automation setup, examples of autonomous background runs, independent confirmation the feature works as claimed.

   • [claimed-docs] “Automate workflows using schedules or webhooks.”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to Glama
   Glama~partialprobed5/10

   Glama exposes an OpenAPI 3.0.3 spec (9 documented paths) and an RFC 9727 API catalog, enabling agent-driven client generation, plus an interactive MCP Inspector for testing servers in-browser — but this is not a fully documented, runnable 'API reference' experience with examples for the platform API itself, and the openapi.json/mcp.md at top-level paths 404. missing for 10: a human/agent-facing interactive docs UI (like Swagger UI/Redoc) with runnable examples against the documented OpenAPI paths, and confirmation the 9-path spec covers the full registry API rather than a subset.

   • [probe] “PROBE openapi (2026-09-05): GET https://glama.ai/api/mcp/openapi.json returned HTTP 200 with an OpenAPI 3.0.3 description (9 documented path…”
   • [probe] “PROBE api-catalog (2026-09-05): GET https://glama.ai/.well-known/api-catalog returned HTTP 200 with an RFC 9727 linkset naming the platform …”
   • [claimed-docs] “Test any MCP server from your browser. Supports every Model Context Protocol feature”
   • [probe] “PROBE docs-md: HTTP 404 at https://glama.ai/mcp.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://glama.ai/openapi.json, https://glama.ai/swagger.json, https://glama.ai/api/openapi.json, htt…”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   Gram is positioned as an AI control plane/MCP gateway focused on server generation, governance, and observability; there is no evidence of an interactive API reference UI with runnable examples for exploring endpoints, nor documentation of such a feature.

   ⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Glama
   Glama✓fullprobed8/10

   A live probe confirms Glama serves a machine-readable OpenAPI 3.0.3 spec at /api/mcp/openapi.json describing the platform API, plus an RFC 9727 api-catalog linkset for discovery, though an earlier probe found the naive /openapi.json path 404s. missing for 10: no first-party docs page linking/announcing the spec, and no independent/community confirmation of using it to generate a client.

   • [probe] “PROBE openapi (2026-09-05): GET https://glama.ai/api/mcp/openapi.json returned HTTP 200 with an OpenAPI 3.0.3 description (9 documented path…”
   • [probe] “PROBE api-catalog (2026-09-05): GET https://glama.ai/.well-known/api-catalog returned HTTP 200 with an RFC 9727 linkset naming the platform …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://glama.ai/openapi.json, https://glama.ai/swagger.json, https://glama.ai/api/openapi.json, htt…”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   The evidence shows Gram consumes OpenAPI documents as input to build MCP servers, but there is no evidence Gram itself publishes a downloadable machine-readable spec of its own API — the direct probe for openapi.json/swagger.json/well-known paths all returned 404.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.speakeasy.com/openapi.json, https://www.speakeasy.com/swagger.json, https://www.speakeas…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   Glama~partialclaimed4/10

   Glama's inspector lets users test MCP servers interactively via browser/tunnel and hosting has 'private by default' listing, but there is no explicit sandbox/staging environment concept distinct from production, nor any mention of test data isolation. missing for 10: explicit sandbox environment separate from production, documentation on data isolation/test fixtures, independent confirmation of safe non-production testing.

   • [claimed-docs] “Test any MCP server from your browser. Supports every Model Context Protocol feature”
   • [claimed-docs] “Test your local MCP servers with the inspector by exposing them via a public tunnel using mcp-proxy.”
   • [claimed-docs] “Private by default – flip to public listing when ready.”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialclaimed4/10

   Gram provides an in-dashboard 'Connect' harness to test MCP servers with a model before wiring up a real client, which offers some sandbox-like isolation from production agent traffic, but there is no explicit mention of separate sandbox vs. production data/environments, test fixtures, or guarantees that tool calls in this harness avoid hitting live production data sources. missing for 10: explicit sandbox/staging environment concept, isolation guarantees from production data, mock or test data support during agent testing.

   • [claimed-docs] “An in-dashboard agent harness for testing MCP servers before connecting a real client: pick a server, authenticate, chat with a model that c…”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Glama—none0/10

   Evidence shows an OpenAPI spec and API catalog exist (glama-probe-rt-2, glama-probe-rt-3), but there is no mention anywhere of API versioning scheme or a documented deprecation policy for the platform API. Missing for 10: explicit API version numbering, changelog/migration guides, and a stated deprecation/support-lifetime policy.

   • [probe] “PROBE openapi (2026-09-05): GET https://glama.ai/api/mcp/openapi.json returned HTTP 200 with an OpenAPI 3.0.3 description (9 documented path…”
   • [probe] “PROBE api-catalog (2026-09-05): GET https://glama.ai/.well-known/api-catalog returned HTTP 200 with an RFC 9727 linkset naming the platform …”
   • [probe] “PROBE registry-api (2026-09-05): GET https://glama.ai/api/mcp/v1/servers?first=3 without credentials returned HTTP 401 with a JSON auth chal…”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   The evidence pack covers OpenAPI-generated MCP servers, OAuth, governance, CLI, observability, and skills, but contains no documentation of API versioning practices or a deprecation policy for Gram's own APIs/servers.

   ⚑ flag

Multi tenant

1. platform-engineerMaintain separate connected accounts and scoped tokens per end user of my product, so each user's agent acts only on that user's credentials

   weight 3 · round drawn
   Glama—none0/10

   No evidence of per-end-user connected accounts or scoped tokens; Glama's gateway/hosting docs describe per-tool access control and a single API-key model for the platform itself, not multi-tenant credential isolation for a product's end users.

   • [claimed-docs] “Every MCP call from your agents flows through Glama – so you know exactly what your AI is doing, and you decide what it's allowed to do.”
   • [claimed-docs] “Per-tool access control – enable or disable individual tools”
   • [probe] “PROBE registry-api (2026-09-05): GET https://glama.ai/api/mcp/v1/servers?first=3 without credentials returned HTTP 401 with a JSON auth chal…”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   Gram's evidence describes OAuth 2.0 provider integration and team/server/tool-level RBAC synced to an enterprise IDP (gram-docs-2, gram-gh-2), but nothing documents per-end-user connected accounts or scoped tokens so that each of a platform-engineer's own product's end users gets isolated credentials — the RBAC described is org/team-level, not end-user-level multi-tenant credential isolation. Missing for 10: explicit documentation of per-end-user connected-account/token scoping, any multi-tenant credential isolation guide, and evidence of enforcement that one end user's agent cannot use another's credentials.

   • [claimed-docs] “you can use any OAuth 2.0 provider you have set up (such as Auth0, Okta, Keycloak, or your own OAuth server)”
   • [github] “Team, server, and tool level permissions enforced through RBAC and Oauth2.1. Synced to your enterprise IDP (Okta, Azure AD, Google Workspace…”
   • [claimed-docs] “Put a governed endpoint in front of an MCP server someone else runs, so access control, audit, and upstream credentials apply without changi…”

   proof ↗⚑ flag

Oauth

1. developerLet the platform run OAuth flows for downstream tools and vault the resulting credentials encrypted, with automatic token refresh

   weight 3 · round to Gram (Speakeasy)
   Glama—none0/10

   No evidence Glama manages OAuth flows for downstream tools or vaults credentials with encrypted storage and automatic refresh; the docs cover hosting, gateway logging, per-tool access control and inspector testing but nothing about OAuth/credential vaulting.

   • [claimed-docs] “Every MCP call from your agents flows through Glama – so you know exactly what your AI is doing, and you decide what it's allowed to do.”
   • [claimed-docs] “Per-tool access control – enable or disable individual tools”
   • [claimed-docs] “Connect a GitHub repository and Glama builds the image straight from source.”
   • [claimed-docs] “Ship a Dockerfile, an npm package, or a PyPI module. Configure Node or Python versions, build steps, and CMD arguments – or let Glama infer …”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialclaimed5/10

   Docs confirm Gram lets you configure external OAuth 2.0 providers (Auth0, Okta, Keycloak, custom) for downstream tool auth and enforces OAuth2.1/RBAC for platform access, implying it manages OAuth flows for connected servers, but there is no explicit documentation of encrypted credential vaulting or automatic token refresh mechanics. Missing for 10: explicit description of credential encryption at rest, automatic refresh-token handling, and any hands-on/independent verification of these security claims.

   • [claimed-docs] “you can use any OAuth 2.0 provider you have set up (such as Auth0, Okta, Keycloak, or your own OAuth server)”
   • [github] “Team, server, and tool level permissions enforced through RBAC and Oauth2.1. Synced to your enterprise IDP (Okta, Azure AD, Google Workspace…”
   • [claimed-docs] “Put a governed endpoint in front of an MCP server someone else runs, so access control, audit, and upstream credentials apply without changi…”

   proof ↗⚑ flag

White label

1. platform-engineerWhite-label the authorization flow with my own branding and my own OAuth app credentials

   weight 1 · round to Gram (Speakeasy)
   Glama—none0/10

   No evidence in the pack mentions white-labeling, custom branding, or bringing your own OAuth app credentials for the authorization flow; the docs cover hosting, gateway access control, and inspector tooling but nothing about customizable OAuth/branding. Missing for 10: any mention of custom OAuth client ID/secret configuration, branded consent screens, or white-label auth flow documentation.

   ⚑ flag

   Gram (Speakeasy)~partialclaimed6/10

   Gram supports bringing your own OAuth 2.0 provider (Auth0, Okta, Keycloak, or a custom server) so the underlying credentials are fully controlled by the platform-engineer, and RBAC/OAuth2.1 syncs to enterprise IDPs. However, there is no documented evidence of UI-level 'white-labeling' — custom branding/logo/domain on the consent or login screen itself — only backend provider configuration. Missing for 10: evidence of custom branding/theming of the OAuth consent screen or hosted login page, and confirmation that the authorization UI itself (not just the provider) can be rebranded.

   • [claimed-docs] “you can use any OAuth 2.0 provider you have set up (such as Auth0, Okta, Keycloak, or your own OAuth server)”
   • [github] “Team, server, and tool level permissions enforced through RBAC and Oauth2.1. Synced to your enterprise IDP (Okta, Azure AD, Google Workspace…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Glama—none0/10

   Glama's evidence covers MCP server hosting, gateway access control, and API discovery, but nothing describes bulk operations across many items (e.g., batch server management, mass tool invocation) for an AI-native user. No evidence of bulk/batch capability exists.

   ⚑ flag

   Gram (Speakeasy)—none0/10

   The evidence pack covers MCP server hosting, governance, observability, RBAC, and CLI/skills features, but nowhere describes any bulk or batch operation capability (e.g., bulk approving tools, bulk managing servers, or batch tool invocation across many items). This is a plausible axis for a control-plane product managing many servers/toolsets, but no evidence shows it delivers.

   ⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Glama
   Glama~partialclaimed4/10

   Glama mentions 'automate workflows using schedules or webhooks' on its pricing page, which implies some event/trigger-based automation, but there is no documented rule-definition system, no description of conditions/actions, and no independent evidence of this working in practice. missing for 10: documented rule/condition-action definition interface, examples of triggers mapping to automated actions, and independent corroboration that scheduled/webhook automation works as claimed.

   • [claimed-docs] “Automate workflows using schedules or webhooks.”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   Gram's evidence covers governance, observability, tool logging, RBAC, and MCP server management, but there is no mention of user-definable rule/trigger systems that automatically fire actions in response to events (e.g., event-driven automation, if-this-then-that rules, webhooks-to-action). Risk policies and access controls are governance constructs, not event-triggered automation rules.

   ⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Glama
   Glama~partialclaimed4/10

   Glama's pricing page mentions automating workflows via schedules or webhooks, but there is no documentation of how to define recurring jobs, what triggers/scheduling syntax exist, or any hands-on/community confirmation of this feature working. Missing for 10: dedicated scheduler docs/UI, workflow-definition examples, independent confirmation of recurring job execution.

   • [claimed-docs] “Automate workflows using schedules or webhooks.”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   Gram is an MCP control plane focused on generating, governing, observing, and distributing MCP servers/toolsets/skills, but nothing in the evidence describes scheduling recurring jobs or workflows (e.g., cron-like triggers or automated recurring execution) — it only covers request-time tool calls, logging, and access control.

   ⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Gram (Speakeasy)
   Glama—none0/10

   Glama's evidence covers MCP server hosting, gateway routing, access control, and a directory/inspector — nothing about versioning automations, reviewing changes, or rolling back configurations/workflows. The only 'automate workflows' mention (schedules/webhooks) does not touch version control or rollback. missing for 10: version history for automations, diff/review UI, rollback mechanism, any changelog or revision tracking feature.

   • [claimed-docs] “Automate workflows using schedules or webhooks.”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialclaimed4/10

   Gram documents that skills are versioned (`SKILL.md` manifest) and provides audit/observability logs of tool calls, giving some traceability, but there is no evidence of a review workflow or an explicit rollback mechanism for automations/toolsets. missing for 10: explicit review process, rollback/revert functionality, version history UI for toolsets or MCP server configs.

   • [claimed-docs] “A skill is a versioned `SKILL.md` manifest: reusable instructions that agents load on demand.”
   • [claimed-docs] “the raw execution log for every tool call the platform observes across hosted MCP servers, tunneled and shadow MCP servers, skills, and loca…”

   proof ↗⚑ flag

Bridge

1. developerBridge a locally running MCP server into the platform as a managed remote connection without deploying it

   weight 1 · round drawn
   Glama~partialclaimed5/10

   Glama's inspector explicitly supports testing local MCP servers by exposing them via a public tunnel (mcp-proxy), which is a bridging mechanism for locally running servers rather than deploying them into Glama's hosting. However, this is framed as a testing/inspection use case, not as a persistent 'managed remote connection' comparable to a hosted server with access control, gateway routing, and catalog listing. Missing for 10: explicit documentation of a persistent managed-connection mode for local servers (vs. one-off inspector testing), independent confirmation that tunneled local servers get the same gateway/access-control/catalog treatment as hosted ones.

   • [claimed-docs] “Test your local MCP servers with the inspector by exposing them via a public tunnel using mcp-proxy.”
   • [claimed-docs] “Test any MCP server from your browser. Supports every Model Context Protocol feature”
   • [claimed-docs] “Every MCP call from your agents flows through Glama – so you know exactly what your AI is doing, and you decide what it's allowed to do.”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialclaimed5/10

   Docs mention 'tunneled MCP servers' alongside hosted and shadow servers in the observability/tool-logs reference, implying a mechanism to bridge a locally running server into the platform without redeploying it, and the third-party governance guide covers fronting externally-run servers. However, no dedicated guide, CLI command, or hands-on walkthrough for setting up a local-to-remote tunnel is included in the evidence pack. Missing for 10: a dedicated tunnel setup guide/CLI reference, concrete steps for exposing a local dev MCP server, and independent confirmation the tunnel actually works.

   • [claimed-docs] “the raw execution log for every tool call the platform observes across hosted MCP servers, tunneled and shadow MCP servers, skills, and loca…”
   • [claimed-docs] “Put a governed endpoint in front of an MCP server someone else runs, so access control, audit, and upstream credentials apply without changi…”
   • [claimed-docs] “install toolsets as MCP servers in AI agents, and keep the CLI itself up to date”

   proof ↗⚑ flag

Access control

1. platform-engineerRestrict which servers and individual tools an agent may call through allowlists or per-tool access control

   weight 2 · round to Gram (Speakeasy)
   Glama~partialclaimed6/10

   Docs explicitly mention gateway routing all MCP calls and per-tool access control (enable/disable individual tools), directly supporting the story's core requirement of per-tool restriction. However, evidence lacks detail on allowlisting specific servers per-agent, role-based policies, or independent/hands-on confirmation that these controls work as described. missing for 10: server-level allowlist granularity, agent-specific policy configuration examples, independent verification of gateway enforcement in practice.

   • [claimed-docs] “Every MCP call from your agents flows through Glama – so you know exactly what your AI is doing, and you decide what it's allowed to do.”
   • [claimed-docs] “Per-tool access control – enable or disable individual tools”

   proof ↗⚑ flag

   Gram (Speakeasy)✓fullclaimed8/10

   Gram documents team/server/tool-level RBAC enforced with OAuth2.1 synced to enterprise IDPs, and explicitly blocks unsanctioned shadow MCP servers by default, directly matching allowlist/per-tool access control for a platform-engineer persona. This is corroborated by third-party rollout evidence (MoonPay) and governance guides for wrapping third-party MCP servers with access control. Missing for 10: independent hands-on verification of the RBAC/permission enforcement mechanics beyond vendor docs and GitHub README claims.

   • [github] “Team, server, and tool level permissions enforced through RBAC and Oauth2.1. Synced to your enterprise IDP (Okta, Azure AD, Google Workspace…”
   • [claimed-docs] “unsanctioned shadow MCP servers are blocked by default”
   • [claimed-docs] “MoonPay brought 200+ MCP servers under the MCP Gateway, going from proof of concept to a company-wide rollout in 30 days.”
   • [claimed-docs] “Put a governed endpoint in front of an MCP server someone else runs, so access control, audit, and upstream credentials apply without changi…”

   proof ↗⚑ flag

Audit

1. platform-engineerSee a log of every tool call that passed through the platform, with enough detail to audit or replay what an agent did

   weight 2 · round to Gram (Speakeasy)
   Glama~partialclaimed4/10

   Glama's gateway routes all MCP calls and gives visibility ('you know exactly what your AI is doing') plus per-tool access control, implying some logging capability, but there is no documented evidence of a persistent, queryable call log with per-call detail (params, responses, timestamps) or replay functionality. missing for 10: detailed audit log schema/UI, replay capability, retention/export controls, independent confirmation of logging fidelity.

   • [claimed-docs] “Every MCP call from your agents flows through Glama – so you know exactly what your AI is doing, and you decide what it's allowed to do.”
   • [claimed-docs] “Per-tool access control – enable or disable individual tools”

   proof ↗⚑ flag

   Gram (Speakeasy)✓fullclaimed8/10

   Gram documents a raw execution log capturing every tool call across hosted, tunneled, shadow MCP servers, skills, and local tools ([gram-docs-5]), plus usage/cost tracking and session deep-dives ([gram-gh-1]) that support audit and replay-style analysis. RBAC/OAuth-scoped access adds context for auditability of who called what ([gram-gh-2]). Missing for 10: independent/hands-on verification of log completeness or replay functionality specifically, and detail on log retention/export format.

   • [claimed-docs] “the raw execution log for every tool call the platform observes across hosted MCP servers, tunneled and shadow MCP servers, skills, and loca…”
   • [github] “Track AI usage across teams and measure impact with either tokens or cost. Deep dive expensive sessions, create budgets and measure tool eff…”
   • [github] “Team, server, and tool level permissions enforced through RBAC and Oauth2.1. Synced to your enterprise IDP (Okta, Azure AD, Google Workspace…”
   • [claimed-docs] “unsanctioned shadow MCP servers are blocked by default”

   proof ↗⚑ flag

Catalog

1. developerReach a deep catalog of third-party apps and APIs (hundreds to thousands of integrations) through the platform

   weight 3 · round to Glama
   Glama✓fullprobed8/10

   Glama's directory contains 81,811 MCP servers and 15,990 remote connectors per its own llms.txt, giving developers access to a massive catalog of third-party integrations, with search and inspection tooling and a registry API. missing for 10: independent verification of catalog usability/quality at scale beyond vendor-reported counts, and community feedback notes it's easy to 'get lost in the sea' of listings suggesting discoverability friction.

   • [probe] “PROBE llms.txt: HTTP 200 at https://glama.ai/llms.txt # Glama > A directory of 81,811 Model Context Protocol servers and 15,990 remote conn…”
   • [claimed-docs] “Search Glama's curated catalog of open-source servers and remote connectors, inspect their capabilities, and keep your own directory synchro…”
   • [community] “Its really easy to get lost in the sea of existing ones on the glama site or github in general - asking for recommendations on how to market…”
   • [probe] “PROBE registry-api (2026-09-05): GET https://glama.ai/api/mcp/v1/servers?first=3 without credentials returned HTTP 401 with a JSON auth chal…”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   Gram's documented model is generating MCP servers from your own OpenAPI/TypeScript source or governing a third-party MCP server you already run — there is no evidence of a pre-built catalog of hundreds/thousands of ready-made third-party app/API integrations comparable to a connector marketplace. The MoonPay case study mentions bringing 200+ existing internally-run MCP servers under governance, not a Gram-provided catalog to browse and connect.

   • [claimed-docs] “Built — the Control Plane generates the server itself from a first-party source: an OpenAPI document or a TypeScript Functions project.”
   • [claimed-docs] “Put a governed endpoint in front of an MCP server someone else runs, so access control, audit, and upstream credentials apply without changi…”
   • [claimed-docs] “MoonPay brought 200+ MCP servers under the MCP Gateway, going from proof of concept to a company-wide rollout in 30 days.”

   proof ↗⚑ flag

Connect

1. developerPoint my MCP-compatible client at a hosted remote server URL and reach downstream tools without deploying any infrastructure

   weight 3 · round to Gram (Speakeasy)
   Glama✓fullcommunity7/10

   Glama hosts MCP servers (built from GitHub repos, Dockerfiles, npm/PyPI packages) and exposes them as remote connectors/servers reachable by MCP clients, with a gateway routing all calls and per-tool access control, removing the need for developers to self-host infrastructure. Community evidence confirms real usage of hosting/scoring, though it also reveals friction (undocumented billing gating rebuilds) that adds operational caveats. Missing for 10: independent hands-on confirmation of a client successfully connecting to a hosted remote URL end-to-end, and clearer public docs on connection URL format/reliability.

   • [claimed-docs] “Connect a GitHub repository and Glama builds the image straight from source.”
   • [claimed-docs] “Ship a Dockerfile, an npm package, or a PyPI module. Configure Node or Python versions, build steps, and CMD arguments – or let Glama infer …”
   • [claimed-docs] “Every MCP call from your agents flows through Glama – so you know exactly what your AI is doing, and you decide what it's allowed to do.”
   • [claimed-docs] “Per-tool access control – enable or disable individual tools”
   • [claimed-docs] “Private by default – flip to public listing when ready.”
   • [community] “I love the TDQS system. I've personally revised my MCPs to improve the quality of the score... Really love the idea behind this and Glama in…”
   • [community] “After uploading a new MCP version, the quality score test wouldn't rerun for 3 days despite manual resyncs and API attempts. Turned out a cr…”

   proof ↗⚑ flag

   Gram (Speakeasy)✓fullprobed8/10

   Gram's Control Plane auto-generates hosted MCP servers from an OpenAPI doc or TypeScript project, so developers get a remote server URL to point MCP clients at without deploying infra themselves, and this is corroborated by the CLI runtime probe and a real customer rollout (MoonPay's 200+ servers under the MCP Gateway). missing for 10: independent hands-on confirmation of an end-to-end client connecting to a hosted URL (only the CLI tool itself was runtime-verified, not the hosted server reachability).

   • [claimed-docs] “Built — the Control Plane generates the server itself from a first-party source: an OpenAPI document or a TypeScript Functions project.”
   • [claimed-docs] “MoonPay brought 200+ MCP servers under the MCP Gateway, going from proof of concept to a company-wide rollout in 30 days.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/gram/): downloaded the official cli@0.16.0 release artifact (gram_dar…”
   • [claimed-docs] “the raw execution log for every tool call the platform observes across hosted MCP servers, tunneled and shadow MCP servers, skills, and loca…”

   proof ↗⚑ flag

Generate

1. developerTurn an existing API definition (OpenAPI) or custom code into a hosted MCP server without writing protocol plumbing

   weight 2 · round to Gram (Speakeasy)
   Glama~partialclaimed4/10

   Glama's hosting lets you ship a Dockerfile, npm package, PyPI module, or connect a GitHub repo and it builds/runs the server for you (docs-2, docs-3, docs-5, docs-8), which removes protocol plumbing for custom code you already wrote. However, there is no evidence of an OpenAPI-spec-to-MCP-server generator or converter — the docs only describe hosting pre-built code, not turning an API definition into a server. Missing for 10: OpenAPI import/definition-to-server generation feature, documentation or example of spec-driven server creation, independent confirmation of this specific workflow.

   • [claimed-docs] “Connect a GitHub repository and Glama builds the image straight from source.”
   • [claimed-docs] “Ship a Dockerfile, an npm package, or a PyPI module. Configure Node or Python versions, build steps, and CMD arguments – or let Glama infer …”
   • [claimed-docs] “Per-tool access control – enable or disable individual tools”
   • [claimed-docs] “Private by default – flip to public listing when ready.”

   proof ↗⚑ flag

   Gram (Speakeasy)✓fullprobed8/10

   Gram's Control Plane generates a hosted MCP server directly from an OpenAPI document or a TypeScript Functions project, with no protocol plumbing required from the developer, and a CLI/runtime probe confirms the tooling actually installs and runs. missing for 10: independent (non-vendor) hands-on account of the OpenAPI-to-MCP generation flow itself, and more detail on custom-code/TypeScript function support beyond the docs mention.

   • [claimed-docs] “Built — the Control Plane generates the server itself from a first-party source: an OpenAPI document or a TypeScript Functions project.”
   • [probe] “official CLI documented at https://www.speakeasy.com/docs/ai-control-plane/reference/command-line”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/gram/): downloaded the official cli@0.16.0 release artifact (gram_dar…”

   proof ↗⚑ flag

Publish

1. developerPublish my own MCP server on the platform for distribution, discovery, and installation by others

   weight 2 · round to Gram (Speakeasy)
   Glama✓fullcommunity7/10

   Glama's hosting docs describe end-to-end publishing: connect a GitHub repo or ship a Dockerfile/npm/PyPI package, configure build/run settings, set per-tool access control, and toggle from private to public listing for discovery in Glama's catalog of servers/connectors — matching publish, distribution, discovery, and installation. Community evidence corroborates real users publishing/updating MCP servers and having them scored/listed, though also reports friction (undocumented billing requirement blocking rebuild/rescoring). Missing for 10: independent hands-on confirmation of a smooth end-to-end publish flow without the billing/support friction reported in the community thread, and clearer documentation of the installation step for end users.

   • [claimed-docs] “Connect a GitHub repository and Glama builds the image straight from source.”
   • [claimed-docs] “Ship a Dockerfile, an npm package, or a PyPI module. Configure Node or Python versions, build steps, and CMD arguments – or let Glama infer …”
   • [claimed-docs] “Per-tool access control – enable or disable individual tools”
   • [claimed-docs] “Private by default – flip to public listing when ready.”
   • [claimed-docs] “Search Glama's curated catalog of open-source servers and remote connectors, inspect their capabilities, and keep your own directory synchro…”
   • [community] “I love the TDQS system. I've personally revised my MCPs to improve the quality of the score... Really love the idea behind this and Glama in…”
   • [community] “After uploading a new MCP version, the quality score test wouldn't rerun for 3 days despite manual resyncs and API attempts. Turned out a cr…”
   • [community] “Its really easy to get lost in the sea of existing ones on the glama site or github in general - asking for recommendations on how to market…”

   proof ↗⚑ flag

   Gram (Speakeasy)✓fullprobed8/10

   Gram lets developers generate/host MCP servers from OpenAPI or TypeScript sources on its Control Plane, with governance, RBAC, tool logs, and a CLI/dashboard to publish, discover, and install servers into MCP clients, and the CLI was independently verified to install and run. missing for 10: no independent (non-vendor) evidence of a public discovery/marketplace listing showing other developers actually finding and installing a third party's published server, and no detail on versioning/publishing workflow specifics beyond docs.

   • [claimed-docs] “Built — the Control Plane generates the server itself from a first-party source: an OpenAPI document or a TypeScript Functions project.”
   • [claimed-docs] “install toolsets as MCP servers in AI agents, and keep the CLI itself up to date”
   • [claimed-docs] “An org admin working in Claude Code, Cursor, Codex, or another MCP client can find and add MCP servers, finish their setup, put them on a pl…”
   • [claimed-docs] “MoonPay brought 200+ MCP servers under the MCP Gateway, going from proof of concept to a company-wide rollout in 30 days.”
   • [github] “Team, server, and tool level permissions enforced through RBAC and Oauth2.1. Synced to your enterprise IDP (Okta, Azure AD, Google Workspace…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/gram/): downloaded the official cli@0.16.0 release artifact (gram_dar…”
   • [probe] “official MCP server documented at https://www.speakeasy.com/docs/ai-control-plane/reference/platform-mcp”

   proof ↗⚑ flag

Triggers

1. developerSubscribe my agent to events from connected downstream apps (triggers/webhooks) instead of polling them

   weight 2 · round to Glama
   Glama~partialclaimed4/10

   Glama's pricing page mentions 'Automate workflows using schedules or webhooks' (glama-docs-10), suggesting some webhook-driven automation exists, but there is no documentation of subscribing an agent to events from downstream connected apps, no event/webhook API reference, and no example of triggers replacing polling. Missing for 10: documented webhook/event subscription API, examples of downstream app event triggers, confirmation this applies to agent-tool integrations rather than just internal automation.

   • [claimed-docs] “Automate workflows using schedules or webhooks.”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   Gram's documented capabilities center on generating/govern/observe MCP servers from OpenAPI specs and exposing tools for agents to call (pull-based); there is no mention anywhere in the evidence of webhook subscriptions, event triggers, or push notifications from downstream apps to agents. This is a plausible axis for an MCP gateway/control-plane product, but no evidence shows it delivers it.

   ⚑ flag

Analytics

1. platform-engineerSee usage analytics for the servers and tools my org consumes or publishes — call volumes, users, errors, and cost

   weight 2 · round to Gram (Speakeasy)
   Glama—none0/10

   Evidence shows Glama offers a gateway that routes MCP calls (glama-docs-4), hosting, per-tool access control, and a directory/quality scoring system, but there is no mention of usage analytics dashboards, call volume metrics, user-level breakdowns, error rates, or cost tracking for orgs. missing for 10: usage/call-volume dashboards, per-user analytics, error-rate reporting, cost/billing analytics tied to server or tool consumption.

   • [claimed-docs] “Every MCP call from your agents flows through Glama – so you know exactly what your AI is doing, and you decide what it's allowed to do.”
   • [claimed-docs] “Per-tool access control – enable or disable individual tools”
   • [claimed-docs] “Search Glama's curated catalog of open-source servers and remote connectors, inspect their capabilities, and keep your own directory synchro…”

   proof ↗⚑ flag

   Gram (Speakeasy)✓fullclaimed7/10

   Gram documents tool-call logs across hosted/tunneled/shadow servers and local tools, and the GitHub repo description explicitly claims usage tracking across teams by tokens/cost, budgets, and tool effectiveness measurement, directly matching call volumes/cost/usage. Errors are implied via raw execution logs but not explicitly broken out as an error-rate metric, and there's no independent/hands-on corroboration of the analytics dashboard itself. Missing for 10: explicit error-rate reporting UI evidence, independent third-party validation of the analytics dashboard beyond vendor docs/GitHub description.

   • [github] “Track AI usage across teams and measure impact with either tokens or cost. Deep dive expensive sessions, create budgets and measure tool eff…”
   • [claimed-docs] “the raw execution log for every tool call the platform observes across hosted MCP servers, tunneled and shadow MCP servers, skills, and loca…”
   • [claimed-docs] “unsanctioned shadow MCP servers are blocked by default”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Gram (Speakeasy)
   Glama~partialprobed5/10

   Glama exposes a real, documented API (OpenAPI spec at /api/mcp/openapi.json, RFC 9727 api-catalog, registry endpoint requiring API key) covering server search/registry data, but the evidence shows only 9 documented API paths versus a much richer UI feature set (hosting/build config, per-tool access control, gateway policy, scheduling/webhooks, inspector) with no confirmation these UI-only features are API-accessible. Community reports also show real friction (undocumented billing gate blocking rebuild triggers via API/manual resync) indicating parity gaps in practice. Missing for 10: evidence that hosting/build config, access control, gateway rules, and automation/webhooks are exposed via the documented API, and confirmation the community-reported API rebuild friction has been resolved.

   • [probe] “PROBE openapi (2026-09-05): GET https://glama.ai/api/mcp/openapi.json returned HTTP 200 with an OpenAPI 3.0.3 description (9 documented path…”
   • [probe] “PROBE api-catalog (2026-09-05): GET https://glama.ai/.well-known/api-catalog returned HTTP 200 with an RFC 9727 linkset naming the platform …”
   • [probe] “PROBE registry-api (2026-09-05): GET https://glama.ai/api/mcp/v1/servers?first=3 without credentials returned HTTP 401 with a JSON auth chal…”
   • [claimed-docs] “Ship a Dockerfile, an npm package, or a PyPI module. Configure Node or Python versions, build steps, and CMD arguments – or let Glama infer …”
   • [claimed-docs] “Per-tool access control – enable or disable individual tools”
   • [claimed-docs] “Automate workflows using schedules or webhooks.”
   • [community] “After uploading a new MCP version, the quality score test wouldn't rerun for 3 days despite manual resyncs and API attempts. Turned out a cr…”
   • [community] “Neither I nor my AI agent could figure out over 4 days of searching documentation why the quality score retest wasn't triggering on the late…”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialprobed6/10

   Gram exposes a Platform MCP server and CLI that let an org admin add/configure MCP servers, author skills, manage risk policies, and read observability data without opening the dashboard (gram-docs-4, gram-docs-7, gram-probe-5), and the CLI is confirmed to actually install and run (gram-probe-rt-1). However, no public REST/OpenAPI surface was found (gram-probe-3: openapi.json paths all 404), so full UI-parity via a general API is unconfirmed. Missing for 10: a documented general-purpose REST/OpenAPI API covering all dashboard actions, and independent confirmation that every UI feature (not just admin/config tasks) is reachable programmatically.

   • [claimed-docs] “install toolsets as MCP servers in AI agents, and keep the CLI itself up to date”
   • [claimed-docs] “An org admin working in Claude Code, Cursor, Codex, or another MCP client can find and add MCP servers, finish their setup, put them on a pl…”
   • [probe] “official CLI documented at https://www.speakeasy.com/docs/ai-control-plane/reference/command-line”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/gram/): downloaded the official cli@0.16.0 release artifact (gram_dar…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.speakeasy.com/openapi.json, https://www.speakeasy.com/swagger.json, https://www.speakeas…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Glama—none0/10

   No evidence of a data-export feature, open-format export tools, or account-portability mechanism for user-uploaded MCP configurations, server catalogs, or usage data; evidence covers hosting, API access, and catalog browsing but not exporting/leaving with one's own data.

   ⚑ flag

   Gram (Speakeasy)—none0/10

   The evidence describes Gram's inputs (OpenAPI specs, SKILL.md manifests) and platform features like RBAC, logging, and CLI, but there is no documented data-export feature letting a user pull out their configured toolsets, logs, policies, or org data in open formats to migrate away. Axis applies to a platform like this but no evidence supports it.

   ⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Glama—none0/10

   Glama is a hosted directory/gateway platform for MCP servers; there is no evidence of its own source code being published under an open license — the evidence pack only covers API access, hosting features, and a curated catalog of third-party open-source MCP servers, not Glama's own source availability.

   ⚑ flag

   Gram (Speakeasy)—none0/10

   The evidence shows a public GitHub repository (github.com/speakeasy-api/gram) exists, but nothing in the pack states or documents an open-source license or that the full source is freely readable/licensed for reuse; docs focus on hosted product features (CLI, MCP servers, RBAC, observability) rather than source availability or licensing terms.

   • [github] “Track AI usage across teams and measure impact with either tokens or cost. Deep dive expensive sessions, create budgets and measure tool eff…”
   • [github] “Team, server, and tool level permissions enforced through RBAC and Oauth2.1. Synced to your enterprise IDP (Okta, Azure AD, Google Workspace…”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Glama—none0/10

   Glama is presented as a hosted SaaS directory/gateway for MCP servers with no evidence of a self-hostable core product, open-source release, or on-prem deployment option; all evidence points to a cloud-hosted service with API access, not self-hosting. Missing for 10: any mention of open-source code, self-host installer/docker-compose for the core platform, or on-prem deployment instructions.

   • [claimed-docs] “Connect a GitHub repository and Glama builds the image straight from source.”
   • [claimed-docs] “Ship a Dockerfile, an npm package, or a PyPI module. Configure Node or Python versions, build steps, and CMD arguments – or let Glama infer …”
   • [probe] “PROBE llms.txt: HTTP 200 at https://glama.ai/llms.txt # Glama > A directory of 81,811 Model Context Protocol servers and 15,990 remote conn…”
   • [probe] “PROBE registry-api (2026-09-05): GET https://glama.ai/api/mcp/v1/servers?first=3 without credentials returned HTTP 401 with a JSON auth chal…”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   While Gram's code is hosted on GitHub (gram-gh-1, gram-gh-2), the evidence pack contains no documentation, guide, or deployment instructions describing a supported self-hosted deployment of the core Control Plane — all docs describe the hosted SaaS platform, dashboard, and CLI/skill features rather than self-hosting.

   • [github] “Track AI usage across teams and measure impact with either tokens or cost. Deep dive expensive sessions, create budgets and measure tool eff…”
   • [github] “Team, server, and tool level permissions enforced through RBAC and Oauth2.1. Synced to your enterprise IDP (Okta, Azure AD, Google Workspace…”

   proof ↗⚑ flag

Pricing

1. developerPrototype my agent's tool connections on a meaningful free tier before paying anything

   weight 1 · round to Glama
   Glama!disputedcontradicted4/10

   Glama's docs promote free-sounding capabilities like testing MCP servers and browsing the catalog (glama-docs-1, glama-docs-6), but no evidence pack item actually describes a free pricing tier or its limits, and a hands-on report shows a user's MCP rebuild/rescan silently failed for days until a credit card was added — an undocumented paywall blocking core functionality (glama-comm-2, glama-comm-3). This directly contradicts the idea of a functional free prototyping tier. Missing for 10: explicit free-tier plan details/limits, confirmation that tool-connection prototyping works fully without payment, and resolution of the undocumented credit-card requirement.

   • [claimed-docs] “Test any MCP server from your browser. Supports every Model Context Protocol feature”
   • [claimed-docs] “Search Glama's curated catalog of open-source servers and remote connectors, inspect their capabilities, and keep your own directory synchro…”
   • [community] “After uploading a new MCP version, the quality score test wouldn't rerun for 3 days despite manual resyncs and API attempts. Turned out a cr…”
   • [community] “Neither I nor my AI agent could figure out over 4 days of searching documentation why the quality score retest wasn't triggering on the late…”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   The evidence pack contains no mention of pricing tiers, a free tier, or cost thresholds for Gram — nothing describes what is available without payment. This is a fair pricing-plans axis for any commercial dev tool, but there's simply no documentation or citation about free-tier limits or trial terms.

   ⚑ flag

2. developerSee transparent pricing per tool call or connection plus documented rate limits before committing to the platform

   weight 2 · round drawn
   Glama—none0/10

   The evidence only shows a generic /pricing page reference (workflow automation) with no per-tool-call or per-connection pricing figures, and no documented rate limits anywhere in the docs or probes. Community reports (glama-comm-2, glama-comm-3) actually describe an undocumented billing requirement (a credit card needed for rebuilds) that surprised users, further indicating the platform lacks the transparent, documented pricing/rate-limit information the story asks for.

   • [claimed-docs] “Automate workflows using schedules or webhooks.”
   • [community] “After uploading a new MCP version, the quality score test wouldn't rerun for 3 days despite manual resyncs and API attempts. Turned out a cr…”
   • [community] “Neither I nor my AI agent could figure out over 4 days of searching documentation why the quality score retest wasn't triggering on the late…”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   No evidence pack item mentions pricing, cost per tool call/connection, or documented rate limits; all citations concern architecture, RBAC, skills, and CLI features. Absence of evidence for an applicable and standard pricing-transparency axis means this must be scored none.

   ⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Glama—none0/10

   No evidence anywhere in the pack mentions data residency, region selection, or storage location controls for hosted MCP servers or user data; the axis applies to a hosting platform but is unaddressed. Missing for 10: any mention of region/data-residency options, storage location controls, or compliance certifications (e.g., GDPR/data locality) that would let a user choose where data is stored.

   ⚑ flag

   Gram (Speakeasy)—none0/10

   No evidence in the pack mentions data residency, region selection, or geographic storage controls for Gram; the documentation focuses on governance, RBAC, tool logs, and MCP server hosting but never addresses where data is physically stored.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Glama—none0/10

   No evidence in the pack addresses data usage for AI training, opt-out settings, or any privacy policy regarding model training; the material only covers MCP hosting, gateway, and directory features. This is an applicable axis for an AI-native platform handling user data/tools, but nothing shows a mechanism to prevent training use, so it is 'none'. Missing for 10: any training-data opt-out policy, privacy documentation, or terms-of-service statement on data usage.

   ⚑ flag

   Gram (Speakeasy)—none0/10

   Gram's evidence pack covers MCP server governance, RBAC, observability, and tool logging, but nothing addresses whether user/tool-call data is used to train AI models or an opt-out policy for such training — missing for 10: any data-training policy statement, opt-out controls, or model-training disclosure.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Glama—none0/10

   No evidence describes data retention policies, deletion controls, or export/erasure mechanisms for user data or MCP call logs; the evidence covers hosting, gateway routing, and API access but nothing about retention/deletion settings. missing for 10: retention period disclosure, deletion/export controls, data lifecycle policy documentation.

   ⚑ flag

   Gram (Speakeasy)—none0/10

   The evidence pack covers governance, RBAC, audit logs, OAuth, and shadow-server blocking, but no citation addresses data retention policies, deletion controls, or user data lifecycle management for the AI-native platform.

   ⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Glama—none0/10

   No evidence in the pack addresses telemetry/usage-tracking settings or an opt-out mechanism for Glama; the docs cover MCP hosting, gateway, and inspector features only. missing for 10: any mention of telemetry collection, privacy policy, or a user-facing opt-out/disable-tracking setting.

   ⚑ flag

   Gram (Speakeasy)—none0/10

   No evidence in the pack addresses whether Gram's CLI, dashboard, or platform collects vendor-side telemetry/usage data or offers an opt-out; the only related items describe customer-facing usage analytics (tracking AI agent activity), not the product's own telemetry practices. Missing for 10: any mention of a telemetry setting, opt-out flag, or privacy policy statement about data collection from the CLI/platform itself.

   • [github] “Track AI usage across teams and measure impact with either tokens or cost. Deep dive expensive sessions, create budgets and measure tool eff…”

   proof ↗⚑ flag

Api

1. ai agentQuery the platform's registry or catalog through a documented API to discover servers and tools programmatically

   weight 3 · round to Glama
   Glama✓fullprobed8/10

   Glama exposes a live registry API (glama.ai/api/mcp/v1/servers) documented via an OpenAPI 3.0.3 spec with 9 paths and an RFC 9727 well-known API catalog for machine discovery, confirming programmatic, documented access to its server/tool catalog; docs also describe the curated catalog of servers and connectors. Missing for 10: independent third-party developer confirmation of successful client generation/integration and clearer public documentation of the API key auth flow beyond the probe's 401 challenge.

   • [probe] “PROBE registry-api (2026-09-05): GET https://glama.ai/api/mcp/v1/servers?first=3 without credentials returned HTTP 401 with a JSON auth chal…”
   • [probe] “PROBE openapi (2026-09-05): GET https://glama.ai/api/mcp/openapi.json returned HTTP 200 with an OpenAPI 3.0.3 description (9 documented path…”
   • [probe] “PROBE api-catalog (2026-09-05): GET https://glama.ai/.well-known/api-catalog returned HTTP 200 with an RFC 9727 linkset naming the platform …”
   • [claimed-docs] “Search Glama's curated catalog of open-source servers and remote connectors, inspect their capabilities, and keep your own directory synchro…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://glama.ai/llms.txt # Glama > A directory of 81,811 Model Context Protocol servers and 15,990 remote conn…”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialprobed6/10

   Gram documents an official 'platform-mcp' server that lets an agent working through an MCP client find and add MCP servers, manage toolsets, and read observability data programmatically (gram-docs-7, gram-probe-4), and the CLI can install toolsets as MCP servers (gram-docs-4/5). This covers the discovery story via the MCP protocol itself acting as the documented API, but there is no confirmed general-purpose REST/OpenAPI catalog endpoint (the openapi probe returned 404s) and no independent hands-on proof of the discovery flow itself. Missing for 10: a documented REST/OpenAPI registry endpoint, and third-party/hands-on verification that an agent can actually enumerate servers/tools via the platform MCP server.

   • [claimed-docs] “An org admin working in Claude Code, Cursor, Codex, or another MCP client can find and add MCP servers, finish their setup, put them on a pl…”
   • [claimed-docs] “install toolsets as MCP servers in AI agents, and keep the CLI itself up to date”
   • [probe] “official MCP server documented at https://www.speakeasy.com/docs/ai-control-plane/reference/platform-mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.speakeasy.com/openapi.json, https://www.speakeasy.com/swagger.json, https://www.speakeas…”

   proof ↗⚑ flag

Metadata

1. developerInspect a listed server's tools, input schemas, transport, and hosting attributes before connecting to it

   weight 2 · round to Glama
   Glama~partialprobed6/10

   Glama's inspector lets developers test/inspect any listed MCP server's tools and capabilities from the browser, and the directory/reference docs mention inspecting capabilities and searching the catalog with hosting attributes (Dockerfile/npm/PyPI, private/public status) documented per-server. However, there's no concrete evidence of a structured, per-server schema view showing input schemas or transport type explicitly, and the registry API requires an API key, limiting easy inspection before connecting. Missing for 10: explicit UI/API display of input schemas and transport protocol per listing, and independent hands-on confirmation of pre-connection inspection depth.

   • [claimed-docs] “Test any MCP server from your browser. Supports every Model Context Protocol feature”
   • [claimed-docs] “Search Glama's curated catalog of open-source servers and remote connectors, inspect their capabilities, and keep your own directory synchro…”
   • [claimed-docs] “Ship a Dockerfile, an npm package, or a PyPI module. Configure Node or Python versions, build steps, and CMD arguments – or let Glama infer …”
   • [claimed-docs] “Private by default – flip to public listing when ready.”
   • [probe] “PROBE registry-api (2026-09-05): GET https://glama.ai/api/mcp/v1/servers?first=3 without credentials returned HTTP 401 with a JSON auth chal…”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialclaimed5/10

   Gram's in-dashboard 'Connect' harness lets a developer pick a listed server, authenticate, and chat with a model that calls its tools while inspecting logs, which implies pre-connection tool inspection, and servers are generated from OpenAPI/TypeScript sources implying schema definitions exist. However, no evidence explicitly documents a UI or API for viewing input schemas, transport type, or hosting attributes for a listed server. Missing for 10: explicit documentation of schema viewer, transport metadata display, hosting attribute display, and independent/hands-on confirmation of this inspection workflow.

   • [claimed-docs] “An in-dashboard agent harness for testing MCP servers before connecting a real client: pick a server, authenticate, chat with a model that c…”
   • [claimed-docs] “Built — the Control Plane generates the server itself from a first-party source: an OpenAPI document or a TypeScript Functions project.”

   proof ↗⚑ flag

Playground

1. developerExercise an MCP server's tools from a browser-based inspector or playground before integrating it

   weight 2 · round drawn
   Glama✓fullclaimed8/10

   Glama documents a browser-based inspector that can test any MCP server (local via tunnel or remote) covering every MCP feature, directly matching the story's ask to try tools before integration. Missing for 10: independent hands-on confirmation of the inspector's UX/tool-invocation flow beyond vendor docs.

   • [claimed-docs] “Test any MCP server from your browser. Supports every Model Context Protocol feature”
   • [claimed-docs] “Test your local MCP servers with the inspector by exposing them via a public tunnel using mcp-proxy.”

   proof ↗⚑ flag

   Gram (Speakeasy)✓fullclaimed8/10

   Gram provides an in-dashboard agent harness (gram-docs-8) explicitly described as a way to pick a server, authenticate, chat with a model that invokes tools, and inspect logs before connecting a real client — directly matching the story of exercising tools from a browser-based playground pre-integration. This is first-party documentation with a clear feature name ('Connect') dedicated to this exact workflow. Missing for 10: independent/hands-on user reports confirming the playground works as described, and more detail on tool-level interaction granularity within the UI.

   • [claimed-docs] “An in-dashboard agent harness for testing MCP servers before connecting a real client: pick a server, authenticate, chat with a model that c…”

   proof ↗⚑ flag

Search

1. developerSearch and browse a large catalog of MCP servers and tools by capability before wiring anything into my agent

   weight 3 · round to Glama
   Glama✓fullprobed8/10

   Glama's core product is a directory/catalog of 81,811 MCP servers and 15,990 remote connectors, with search, inspection of capabilities, and syncing to a directory (glama-docs-6, glama-probe-1); the inspector lets developers test capabilities before wiring in (glama-docs-1). Community feedback confirms the catalog is large and used, though some find it hard to navigate. Missing for 10: no evidence of structured capability-based filtering/faceted search UI details, and independent hands-on browsing experience beyond a marketing/docs description.

   • [claimed-docs] “Search Glama's curated catalog of open-source servers and remote connectors, inspect their capabilities, and keep your own directory synchro…”
   • [claimed-docs] “Test any MCP server from your browser. Supports every Model Context Protocol feature”
   • [probe] “PROBE llms.txt: HTTP 200 at https://glama.ai/llms.txt # Glama > A directory of 81,811 Model Context Protocol servers and 15,990 remote conn…”
   • [community] “Its really easy to get lost in the sea of existing ones on the glama site or github in general - asking for recommendations on how to market…”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialclaimed3/10

   Gram documents that an admin can 'find and add MCP servers' via the platform MCP client integration, implying some discovery capability, but there is no evidence of a searchable/browsable catalog of MCP servers by capability, catalog size, or a discovery UI — Gram is primarily framed as a control plane for generating/governing your own servers rather than a registry of third-party servers. missing for 10: a documented catalog/search UI, evidence of catalog scale or third-party server listings, and any capability-based filtering/browsing mechanism.

   • [claimed-docs] “An org admin working in Claude Code, Cursor, Codex, or another MCP client can find and add MCP servers, finish their setup, put them on a pl…”
   • [claimed-docs] “Put a governed endpoint in front of an MCP server someone else runs, so access control, audit, and upstream credentials apply without changi…”

   proof ↗⚑ flag

Cli

1. developerDrive the publish-and-deploy workflow from an official CLI — authenticate, stage or build a server, push it, and install it into agents

   weight 2 · round to Gram (Speakeasy)
   Glama—none0/10

   Glama documents web-based hosting (connect GitHub repo, Dockerfile/npm/PyPI builds) and a REST/OpenAPI web API, but there is no evidence of an official CLI tool for authenticating, staging/building, pushing, or installing servers into agents — all workflows described are browser/dashboard driven. Missing for 10: any CLI binary or package, CLI-based auth flow, CLI build/push commands, CLI install-into-agent step.

   • [claimed-docs] “Connect a GitHub repository and Glama builds the image straight from source.”
   • [claimed-docs] “Ship a Dockerfile, an npm package, or a PyPI module. Configure Node or Python versions, build steps, and CMD arguments – or let Glama infer …”
   • [probe] “PROBE registry-api (2026-09-05): GET https://glama.ai/api/mcp/v1/servers?first=3 without credentials returned HTTP 401 with a JSON auth chal…”
   • [probe] “PROBE openapi (2026-09-05): GET https://glama.ai/api/mcp/openapi.json returned HTTP 200 with an OpenAPI 3.0.3 description (9 documented path…”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialprobed7/10

   There's a documented, runtime-verified official CLI (gram-docs-4, gram-probe-5, gram-probe-rt-1) that supports installing toolsets as MCP servers into agents, plus docs on building servers from OpenAPI/TS and platform-mcp integration for org admins to add/configure servers from within MCP clients. However, the evidence doesn't clearly walk through explicit CLI subcommands for authenticate/stage/build/push in one coherent flow — most detail is on install and general CLI existence rather than a full documented publish pipeline. Missing for 10: explicit CLI command reference showing login/auth, build/stage, and push subcommands with example output, and independent (non-vendor) confirmation of the full workflow beyond version-check.

   • [claimed-docs] “install toolsets as MCP servers in AI agents, and keep the CLI itself up to date”
   • [claimed-docs] “Built — the Control Plane generates the server itself from a first-party source: an OpenAPI document or a TypeScript Functions project.”
   • [probe] “official CLI documented at https://www.speakeasy.com/docs/ai-control-plane/reference/command-line”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/gram/): downloaded the official cli@0.16.0 release artifact (gram_dar…”
   • [claimed-docs] “An org admin working in Claude Code, Cursor, Codex, or another MCP client can find and add MCP servers, finish their setup, put them on a pl…”

   proof ↗⚑ flag

Frameworks

1. developerPlug the platform's tools into major agent frameworks and SDKs (Vercel AI SDK, LangChain, CrewAI, OpenAI or Anthropic SDKs) with documented adapters

   weight 2 · round drawn
   Glama—none0/10

   Glama is an MCP server directory/hosting/gateway platform; evidence covers MCP server hosting, inspection, and a generic 'MCP clients' page, but there is no documented adapter or integration guide for Vercel AI SDK, LangChain, CrewAI, or OpenAI/Anthropic SDKs. No SDK-specific code samples or adapter docs appear anywhere in the pack.

   • [claimed-docs] “MCP clients are the applications that connect to MCP servers.”
   • [claimed-docs] “Every MCP call from your agents flows through Glama – so you know exactly what your AI is doing, and you decide what it's allowed to do.”
   • [probe] “PROBE docs-md: HTTP 404 at https://glama.ai/mcp.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://glama.ai/openapi.json, https://glama.ai/swagger.json, https://glama.ai/api/openapi.json, htt…”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   Gram documents MCP server generation, its own CLI, and MCP-client compatibility (Claude Code, Cursor, Codex), but there is no evidence of documented adapters or integration guides for Vercel AI SDK, LangChain, CrewAI, or OpenAI/Anthropic SDKs specifically.

   ⚑ flag

Security

1. platform-engineerRely on the platform scanning or inspecting listed servers for malicious or vulnerable behavior before my agents use them

   weight 2 · round drawn
   Glama~partialprobed5/10

   Glama's llms.txt claims every listed server is 'scanned, scored' and it offers a TDQS quality-score system plus an inspector tool to test servers manually, which supports platform-engineers wanting some assurance before use. However, community evidence shows the quality-score rescan mechanism is opaque, gated behind an undocumented billing requirement, and can silently fail to update for days, undermining confidence in reliability of the scanning pipeline; no evidence describes what 'scanning' actually checks for (malware, vulnerabilities, supply-chain risk) beyond a marketing claim. Missing for 10: technical documentation of what the scan/score actually detects (security vs. quality), independent verification that malicious servers are caught or blocked, and confirmation the rescan pipeline works reliably without hidden gating.

   • [probe] “PROBE llms.txt: HTTP 200 at https://glama.ai/llms.txt # Glama > A directory of 81,811 Model Context Protocol servers and 15,990 remote conn…”
   • [claimed-docs] “Test any MCP server from your browser. Supports every Model Context Protocol feature”
   • [claimed-docs] “Search Glama's curated catalog of open-source servers and remote connectors, inspect their capabilities, and keep your own directory synchro…”
   • [community] “I love the TDQS system. I've personally revised my MCPs to improve the quality of the score... Really love the idea behind this and Glama in…”
   • [community] “After uploading a new MCP version, the quality score test wouldn't rerun for 3 days despite manual resyncs and API attempts. Turned out a cr…”
   • [community] “Neither I nor my AI agent could figure out over 4 days of searching documentation why the quality score retest wasn't triggering on the late…”

   proof ↗⚑ flag

   Gram (Speakeasy)~partialclaimed5/10

   Gram provides governance controls relevant to tool curation — RBAC/OAuth2.1 access control, full audit/tool-call logging across hosted, tunneled and shadow servers, 'risk policies' management via the platform MCP server, and blocking of unsanctioned shadow MCP servers by default — plus an in-dashboard harness to test a server's tool calls before connecting a real client. However none of this is documented as active scanning for malicious code or known vulnerabilities in listed servers; it's closer to access governance, logging and manual testing than automated security scanning. Missing for 10: explicit vulnerability/malware scanning of server code or behavior, third-party security audit integration, and independent evidence that risk policies actually catch malicious servers.

   • [claimed-docs] “unsanctioned shadow MCP servers are blocked by default”
   • [claimed-docs] “An org admin working in Claude Code, Cursor, Codex, or another MCP client can find and add MCP servers, finish their setup, put them on a pl…”
   • [claimed-docs] “the raw execution log for every tool call the platform observes across hosted MCP servers, tunneled and shadow MCP servers, skills, and loca…”
   • [claimed-docs] “An in-dashboard agent harness for testing MCP servers before connecting a real client: pick a server, authenticate, chat with a model that c…”
   • [github] “Team, server, and tool level permissions enforced through RBAC and Oauth2.1. Synced to your enterprise IDP (Okta, Azure AD, Google Workspace…”

   proof ↗⚑ flag

Signals

1. developerCompare servers using published quality signals — usage counts, health or liveness checks, scores, or verification badges

   weight 2 · round to Glama
   Glama!disputedcontradicted5/10

   Glama's directory scans and scores servers (TDQS) and the probe confirms a large catalog with scoring metadata (glama-probe-1), and a community member praises the quality-score system as a signal for comparison (glama-comm-1). However, hands-on reports show the score can silently fail to refresh for days due to an undocumented credit-card requirement, undermining trust that displayed scores are current (glama-comm-2, glama-comm-3). Missing for 10: documented usage-count metrics, uptime/liveness check indicators, verification badges, and independent confirmation that scores reliably update.

   • [probe] “PROBE llms.txt: HTTP 200 at https://glama.ai/llms.txt # Glama > A directory of 81,811 Model Context Protocol servers and 15,990 remote conn…”
   • [community] “I love the TDQS system. I've personally revised my MCPs to improve the quality of the score... Really love the idea behind this and Glama in…”
   • [community] “After uploading a new MCP version, the quality score test wouldn't rerun for 3 days despite manual resyncs and API attempts. Turned out a cr…”
   • [community] “Neither I nor my AI agent could figure out over 4 days of searching documentation why the quality score retest wasn't triggering on the late…”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   Gram provides usage/cost tracking (gram-gh-1) and tool-call logs (gram-docs-5), plus governance controls like blocking shadow servers (gram-docs-10), but there is no evidence of published quality signals such as health/liveness checks, verification badges, or comparative quality scores that a developer could use to compare servers side-by-side. Missing for 10: liveness/health-check indicators, explicit quality/verification badges, and any server-comparison or ranking UI.

   • [github] “Track AI usage across teams and measure impact with either tokens or cost. Deep dive expensive sessions, create budgets and measure tool eff…”
   • [claimed-docs] “the raw execution log for every tool call the platform observes across hosted MCP servers, tunneled and shadow MCP servers, skills, and loca…”
   • [claimed-docs] “unsanctioned shadow MCP servers are blocked by default”

   proof ↗⚑ flag

Tool search

1. ai agentSearch and load tools at runtime through meta-tools instead of having thousands of tool definitions stuffed into my context

   weight 2 · round drawn
   Glama—none0/10

   Glama is a directory/hosting/gateway for MCP servers with search and per-tool access control, but there is no evidence of runtime meta-tool search/load capability (e.g., a 'search_tools'/'load_tool' meta-tool that lets an agent dynamically discover and inject tool definitions instead of preloading them into context). The catalog search (glama-docs-6) is a human/dev-facing directory feature, not an agent-callable meta-tool for dynamic tool loading.

   • [claimed-docs] “Search Glama's curated catalog of open-source servers and remote connectors, inspect their capabilities, and keep your own directory synchro…”
   • [claimed-docs] “Every MCP call from your agents flows through Glama – so you know exactly what your AI is doing, and you decide what it's allowed to do.”
   • [claimed-docs] “Per-tool access control – enable or disable individual tools”

   proof ↗⚑ flag

   Gram (Speakeasy)—none0/10

   Gram's evidence covers MCP server hosting, toolset governance, OAuth, RBAC, and 'skills' loaded on demand, but none of it describes a runtime meta-tool (e.g., search_tools/load_tool) mechanism that lets an agent dynamically discover and load individual tool definitions instead of receiving a large static toolset. The closest analog (SKILL.md manifests loaded on demand) is a different mechanism from runtime tool search across a large tool catalog.

   ⚑ flag