Composio vs Glama

Agent access

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

   weight 2 · round to Composio
   Composio✓fullprobed9/10

   Composio hosts a live llms.txt at docs.composio.dev/llms.txt (verified 200 with agent-oriented summary content), directly satisfying the story of pointing an agent at agent-oriented docs; this is corroborated by a probe rather than just vendor claim. Missing for 10: no independent/community report of an agent actually consuming llms.txt successfully in the wild.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.composio.dev/llms.txt # Composio Documentation > Composio powers 1,400+ toolkits, tool search, con…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Composio
   Composio✓fullprobed7/10

   Composio ships an SDK (Python/TS packages verified to install and import), a REST API (openapi.json), and a CLI, all of which can be scripted/invoked headlessly without a UI — sessions are created programmatically (composio.sessions.create) and tools executed via API/CLI, which is exactly the pattern used in CI automation. Missing for 10: explicit CI/CD pipeline docs or examples (e.g., GitHub Actions integration) and independent confirmation of a fully non-interactive auth flow for headless CI runs.

   • [claimed-docs] “session = composio.sessions.create(user_id="user_123")”
   • [claimed-docs] “The Composio CLI gives coding agents and terminals a local tool surface. Codex, Claude Code, or a person at the terminal can connect apps, e…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.composio.dev/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.composio.dev/docs/cli”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/composio/): `npm install @composio/core` and `uv pip install composio…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Glama
   Composio—none0/10

   All evidence describes Composio exposing its own hosted MCP server/toolkits for agents to consume (composio-docs-4, composio-probe-3, composio-probe-rt-1) — the reverse of this story, which asks whether a user can plug external MCP servers INTO Composio so it can use their tools. No evidence shows Composio importing or connecting to third-party MCP servers as a client.

   • [claimed-docs] “Opt into MCP by passing `mcp: true` when you create the session. The session then exposes its hosted MCP server.”
   • [probe] “official MCP server documented at https://docs.composio.dev/docs/composio-connect”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://connect.composio.dev/mcp returned HTTP 401 with an OAuth challenge — the hosted …”
   • [claimed-docs] “Use Composio Connect when you already have an MCP-compatible client and want the shared Composio MCP URL, without creating an SDK session.”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Composio
   Composio✓fullprobed8/10

   Composio documents and exposes an official hosted MCP server (session `mcp: true`, and the shared 'Composio Connect' MCP URL) that any MCP-compatible agent/client can point at, and a live runtime probe confirms the endpoint (connect.composio.dev/mcp) is real and gated by managed OAuth as documented. This is a fair and clearly-applicable capability for an integration platform, backed by first-party docs plus independent endpoint verification. Missing for 10: an independent third-party report of a successful end-to-end agent session over this MCP endpoint (only auth-challenge probe, not a full tool-call transcript).

   • [claimed-docs] “Opt into MCP by passing `mcp: true` when you create the session. The session then exposes its hosted MCP server.”
   • [claimed-docs] “Combine `mcp: true` with the direct-tools preset to get one MCP URL that serves exactly the tools you list”
   • [claimed-docs] “Use Composio Connect when you already have an MCP-compatible client and want the shared Composio MCP URL, without creating an SDK session.”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”
   • [probe] “official MCP server documented at https://docs.composio.dev/docs/composio-connect”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://connect.composio.dev/mcp returned HTTP 401 with an OAuth challenge — the hosted …”

   proof ↗⚑ flag

   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

5. ai-native userUse an official CLI

   weight 2 · round to Composio
   Composio✓fullprobed9/10

   Composio ships an official CLI with documented install/setup for Codex, Claude Code, and terminal use, enabling agents or developers to connect apps, execute tools, inspect schemas, and debug projects locally (composio-docs-10, composio-docs-11, composio-probe-4). missing for 10: no independent/hands-on user report specifically validating the CLI (community evidence relates to unrelated connection issues, not the CLI itself).

   • [claimed-docs] “The Composio CLI gives coding agents and terminals a local tool surface. Codex, Claude Code, or a person at the terminal can connect apps, e…”
   • [claimed-docs] “Install the native plugin for Codex or Claude Code: composio setup --target auto”
   • [probe] “official CLI documented at https://docs.composio.dev/docs/cli”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Composio
   Composio✓fullprobed9/10

   Composio publishes a documented, structured API surface: an OpenAPI spec (verified live via probe), SDK session creation calls, meta-tools, CLI, and MCP endpoints, all documented on docs.composio.dev and confirmed reachable/installable via runtime probes (openapi.json 200, SDK installs succeed, MCP endpoint live behind auth). This gives AI-native users multiple concrete, documented ways (REST API, Python/TS SDK, CLI, MCP) to drive the product programmatically. Missing for 10: independent third-party review validating API completeness/stability beyond vendor docs and probes.

   • [claimed-docs] “session = composio.sessions.create(user_id="user_123")”
   • [claimed-docs] “A session gives your agent meta tools, a small fixed set that discover, authenticate, and execute tools at runtime”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.composio.dev/openapi.json — contains "openapi" key”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/composio/): `npm install @composio/core` and `uv pip install composio…”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://connect.composio.dev/mcp returned HTTP 401 with an OAuth challenge — the hosted …”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Composio
   Composio!disputedcontradicted5/10

   Composio's docs show real scoping controls—restricting a session to specific toolkits, generating an MCP URL for an exact tool subset, and meta-tools that authorize apps on demand ([composio-docs-3],[composio-docs-5],[composio-docs-14])—but independent security research found a leaked Composio key returned live Gmail, GitHub, and CircleCI tokens, indicating credentials are not tightly least-privilege in practice ([composio-comm-2]). This is a concrete hands-on/security counter-example directly on the scoped-credential axis, so the claim is disputed rather than cleanly fulfilled. Missing for 10: no documentation of granular per-scope/permission-level credential issuance (only toolkit/tool-list restriction), and no rebuttal or fix evidence for the leaked-key finding.

   • [claimed-docs] “To restrict the set, pass `toolkits` when you create the session.”
   • [claimed-docs] “Combine `mcp: true` with the direct-tools preset to get one MCP URL that serves exactly the tools you list”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”
   • [community] “A leaked Composio key returned live Gmail, GitHub and CircleCI tokens (security research on exposed credentials in Composio's agent integrat…”

   proof ↗⚑ flag

   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

8. ai-native userBuild against official SDKs

   weight 2 · round to Composio
   Composio✓fullprobed8/10

   Composio ships official SDKs for both TypeScript (@composio/core) and Python (composio), verified via real installs that imported cleanly, alongside provider adapters that map tools into native framework formats and OpenAPI-documented endpoints. missing for 10: independent third-party tutorials/showcases building production apps with the SDKs, and no evidence of SDKs beyond Python/TypeScript (e.g. Go, Java).

   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/composio/): `npm install @composio/core` and `uv pip install composio…”
   • [claimed-docs] “A provider is the adapter that turns Composio tools into the native tool format your framework expects, so you don't write glue code.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.composio.dev/openapi.json — contains "openapi" key”
   • [claimed-docs] “session = composio.sessions.create(user_id="user_123")”

   proof ↗⚑ flag

   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

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Composio
   Composio✓fullclaimed7/10

   Composio documents a triggers/webhooks system where users register a webhook URL per project and Composio POSTs signed event payloads for every trigger, directly matching the subscribe-to-events story. missing for 10: independent/hands-on confirmation of webhook delivery reliability, event catalog/filtering details, and retry/latency behavior are not evidenced beyond first-party docs.

   • [claimed-docs] “Composio delivers every event to one destination you control: your webhook URL. You register it once per project, and Composio `POST`s every…”

   proof ↗⚑ flag

   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

Agentic features

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

   weight 2 · round to Composio
   Composio~partialcommunity5/10

   Composio's triggers feature lets developers register a webhook so Composio pushes event notifications (e.g., new email, PR) that can kick off agent logic without polling, which is a building block for background automation [composio-docs-9]. However, Composio itself doesn't host or run the autonomous agent loop — execution still happens in the developer's own agent/runtime that reacts to the webhook, and there's no evidence of a built-in scheduler or persistent background-running agent. Community evidence also shows integration reliability issues (Instagram connect failing) that would undercut unattended automation [composio-comm-1]. Missing for 10: evidence of Composio actually orchestrating/running an agent autonomously (not just delivering trigger events), a scheduling/cron-like automation primitive, and independent confirmation that background-triggered automations run reliably end-to-end.

   • [claimed-docs] “Composio delivers every event to one destination you control: your webhook URL. You register it once per project, and Composio `POST`s every…”
   • [community] “I tried using your cloud solution to test this and I couldnt pass the connect to Instagram through Composio. I got a 400 error. I checked Re…”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”

   proof ↗⚑ flag

   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

Api quality

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

   weight 2 · round to Glama
   Composio—none0/10

   The pack shows an OpenAPI spec exists (composio-probe-2) and standard docs pages, but there is no evidence of an interactive API reference (e.g., Swagger/Redoc-style try-it console) with runnable, in-browser examples — missing for 10: dedicated interactive API explorer, runnable code snippets, evidence of a try-it-now console.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.composio.dev/openapi.json — contains "openapi" key”
   • [claimed-docs] “session = composio.sessions.create(user_id="user_123")”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Composio
   Composio✓fullprobed9/10

   A live probe confirms Composio serves a valid machine-readable OpenAPI spec at https://docs.composio.dev/openapi.json (HTTP 200, contains 'openapi' key), directly satisfying the story. Missing for 10: no independent third-party confirmation of spec completeness/versioning beyond the probe check.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.composio.dev/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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

   weight 1 · round to Glama
   Composio—none0/10

   Evidence shows a 'remote sandbox' feature (COMPOSIO_REMOTE_WORKBENCH) for running Python code on bulk/large tool responses, and a docs teaser mentioning 'sand[box]', but nothing describes an isolated test environment that lets a user exercise Composio's actual toolkits/connected accounts without touching live production data or APIs — connections like Instagram/Gmail appear to hit real production endpoints (per composio-comm-1/2).

   • [claimed-docs] “COMPOSIO_REMOTE_WORKBENCH** — Run Python in a remote sandbox for bulk operations or processing large tool responses.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.composio.dev/llms.txt # Composio Documentation > Composio powers 1,400+ toolkits, tool search, con…”
   • [community] “I tried using your cloud solution to test this and I couldnt pass the connect to Instagram through Composio. I got a 400 error. I checked Re…”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Composio—none0/10

   The evidence pack shows API/SDK docs, CLI, MCP endpoints, and an OpenAPI spec, but nowhere mentions API versioning conventions or a documented deprecation policy for breaking changes. Missing for 10: any changelog, version-numbering scheme (e.g. v1/v2 endpoints), or explicit deprecation/sunset policy documentation.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.composio.dev/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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 to Composio
   Composio✓fullclaimed7/10

   Composio's session model is built around per-user identity (`user_id`) and each user must complete their own Connect Link OAuth flow, so an agent only executes tools using the connected end-user's own credentials, with callback_url and white-labeling to fit into a platform's UX. Missing for 10: independent/hands-on verification that token scoping is enforced per user in production, and explicit detail on scope-limiting (vs. just per-user connection) mechanics.

   • [claimed-docs] “session = composio.sessions.create(user_id="user_123")”
   • [claimed-docs] “The agent posts the Connect Link straight into the conversation. The user clicks it, signs in, and the agent retries the tool and continues.…”
   • [claimed-docs] “To send users back to your app after they connect, pass a `callback_url`”
   • [claimed-docs] “You can swap in your logo and name, then restyle the whole page to match your product.”
   • [claimed-docs] “To restrict the set, pass `toolkits` when you create the session.”

   proof ↗⚑ flag

   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

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 Composio
   Composio!disputedcontradicted4/10

   Composio's docs describe hosted OAuth via Connect Link with no auth UI to build, callback_url redirects, and white-labeled auth pages (composio-docs-6,7,8), implying it manages and stores credentials for downstream tool auth. However, independent security research found a leaked Composio API key exposed live Gmail, GitHub, and CircleCI tokens, undermining the 'encrypted vault' claim in practice, and a user reported OAuth connect flows failing outright (400 errors) for at least one integration. Missing for 10: explicit documentation of encryption-at-rest mechanics, automatic token-refresh behavior, and any vendor response/fix to the leaked-token incident.

   • [claimed-docs] “The agent posts the Connect Link straight into the conversation. The user clicks it, signs in, and the agent retries the tool and continues.…”
   • [claimed-docs] “To send users back to your app after they connect, pass a `callback_url`”
   • [claimed-docs] “You can swap in your logo and name, then restyle the whole page to match your product.”
   • [community] “A leaked Composio key returned live Gmail, GitHub and CircleCI tokens (security research on exposed credentials in Composio's agent integrat…”
   • [community] “I tried using your cloud solution to test this and I couldnt pass the connect to Instagram through Composio. I got a 400 error. I checked Re…”

   proof ↗⚑ flag

   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

White label

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

   weight 1 · round to Composio
   Composio~partialclaimed6/10

   Composio's docs explicitly describe white-labeling the auth flow (swap logo/name, restyle the page) and building custom callback flows, directly matching the branding half of the story. However, there is no evidence in the pack that platform-engineers can supply their own OAuth app client ID/secret (bring-your-own OAuth credentials) rather than using Composio-managed auth apps. Missing for 10: documentation of custom/BYO OAuth app credential support, independent confirmation that white-labeling works end-to-end in production.

   • [claimed-docs] “You can swap in your logo and name, then restyle the whole page to match your product.”
   • [claimed-docs] “The agent posts the Connect Link straight into the conversation. The user clicks it, signs in, and the agent retries the tool and continues.…”
   • [claimed-docs] “To send users back to your app after they connect, pass a `callback_url`”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Composio
   Composio~partialcommunity5/10

   Composio documents parallel tool execution via meta-tools and a remote sandbox workbench explicitly for 'bulk operations or processing large tool responses,' supporting some bulk automation across many items. However, there's no dedicated bulk-operation API, batch endpoint, or hands-on evidence demonstrating bulk operations at scale, and one community report shows a basic connection failure (Instagram 400 error), raising reliability doubts. missing for 10: a documented batch/bulk API or endpoint, concrete examples of bulk operations across many items, independent hands-on verification of bulk workflows succeeding at scale.

   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”
   • [claimed-docs] “COMPOSIO_REMOTE_WORKBENCH** — Run Python in a remote sandbox for bulk operations or processing large tool responses.”
   • [community] “I tried using your cloud solution to test this and I couldnt pass the connect to Instagram through Composio. I got a 400 error. I checked Re…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Composio
   Composio~partialclaimed5/10

   Composio's Triggers system delivers event notifications to a registered webhook (signed, verifiable), which lets a user's own system react to events — but Composio itself doesn't appear to expose a first-party rule-definition or condition/action automation builder; the 'trigger action automatically' logic must be implemented by the user's external service consuming the webhook. missing for 10: a documented rules/automation engine (conditions, filters, chained actions) inside Composio itself, and independent evidence of end-to-end automatic action execution rather than just event delivery.

   • [claimed-docs] “Composio delivers every event to one destination you control: your webhook URL. You register it once per project, and Composio `POST`s every…”

   proof ↗⚑ flag

   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

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Glama
   Composio—none0/10

   Composio documents event-driven triggers delivered via webhooks (composio-docs-9), but there is no evidence of a scheduling primitive for recurring jobs/workflows (e.g., cron-style automation) — triggers fire on external events, not on a time-based recurring schedule. Missing for 10: any documented scheduler, cron syntax, or recurring-job API, and independent confirmation that scheduled workflows actually run.

   • [claimed-docs] “Composio delivers every event to one destination you control: your webhook URL. You register it once per project, and Composio `POST`s every…”

   proof ↗⚑ flag

   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

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

   weight 1 · round drawn
   Composio—none0/10

   The evidence pack covers Composio's tool/session/MCP/auth infrastructure but contains no mention of versioning automations, review workflows, or rollback of workflows/agent configurations. No changelog, version history, diff/review, or revert capability is documented anywhere in the pack.

   ⚑ flag

   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

Bridge

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

   weight 1 · round to Glama
   Composio—none0/10

   Composio's docs describe the platform hosting its own MCP server (sessions with mcp:true, Composio Connect shared URL) so agents can consume Composio's tools via MCP, but there is no evidence of the reverse flow — registering or tunneling a developer's own locally-running MCP server into Composio to be exposed as a managed remote connection.

   • [claimed-docs] “Opt into MCP by passing `mcp: true` when you create the session. The session then exposes its hosted MCP server.”
   • [claimed-docs] “Use Composio Connect when you already have an MCP-compatible client and want the shared Composio MCP URL, without creating an SDK session.”
   • [probe] “official MCP server documented at https://docs.composio.dev/docs/composio-connect”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://connect.composio.dev/mcp returned HTTP 401 with an OAuth challenge — the hosted …”

   proof ↗⚑ flag

   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

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 Composio
   Composio✓fullclaimed7/10

   Composio's docs describe restricting a session to specific toolkits (composio-docs-3) and combining `mcp:true` with a direct-tools preset to serve an MCP URL with exactly the listed tools (composio-docs-5), directly enabling allowlist-style, per-tool/server access control for an agent. Missing for 10: independent/hands-on verification of enforcement, granular per-user or role-based policy controls, and audit/logging of denied calls.

   • [claimed-docs] “To restrict the set, pass `toolkits` when you create the session.”
   • [claimed-docs] “Opt into MCP by passing `mcp: true` when you create the session. The session then exposes its hosted MCP server.”
   • [claimed-docs] “Combine `mcp: true` with the direct-tools preset to get one MCP URL that serves exactly the tools you list”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”

   proof ↗⚑ flag

   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

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 Glama
   Composio—none0/10

   The evidence pack describes sessions, meta-tools, MCP hosting, auth flows, and a webhook mechanism for triggers, but nowhere documents a queryable audit log of tool calls with replay detail for platform engineers. Webhook triggers (composio-docs-9) cover external events, not a comprehensive tool-call audit trail.

   • [claimed-docs] “Composio delivers every event to one destination you control: your webhook URL. You register it once per project, and Composio `POST`s every…”

   proof ↗⚑ flag

   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

Catalog

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

   weight 3 · round to Composio
   Composio✓fullprobed9/10

   Composio's own docs and llms.txt claim 1,400+ toolkits reachable via meta-tools, sessions, MCP, and CLI, and probes confirm the docs/OpenAPI/MCP endpoint are live and functioning (though gated by auth), plus SDK packages install cleanly. One community report shows an isolated integration failure (Instagram OAuth) which doesn't contradict the breadth of the catalog itself. Missing for 10: independent third-party verification of the actual '1,400+' count beyond vendor claims.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.composio.dev/llms.txt # Composio Documentation > Composio powers 1,400+ toolkits, tool search, con…”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”
   • [claimed-docs] “A session gives your agent meta tools, a small fixed set that discover, authenticate, and execute tools at runtime”
   • [probe] “official MCP server documented at https://docs.composio.dev/docs/composio-connect”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://connect.composio.dev/mcp returned HTTP 401 with an OAuth challenge — the hosted …”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/composio/): `npm install @composio/core` and `uv pip install composio…”
   • [community] “I tried using your cloud solution to test this and I couldnt pass the connect to Instagram through Composio. I got a 400 error. I checked Re…”

   proof ↗⚑ flag

   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

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 Composio
   Composio✓fullprobed8/10

   Composio documents a hosted MCP server reachable via a shared URL (Composio Connect) or per-session mcp:true flag, requiring no self-hosted infrastructure, and a live probe confirms the endpoint at connect.composio.dev/mcp is active and auth-gated as documented. Missing for 10: independent hands-on confirmation of a successful authenticated tool call through the hosted endpoint beyond the 401 challenge probe.

   • [claimed-docs] “Opt into MCP by passing `mcp: true` when you create the session. The session then exposes its hosted MCP server.”
   • [claimed-docs] “Combine `mcp: true` with the direct-tools preset to get one MCP URL that serves exactly the tools you list”
   • [claimed-docs] “Use Composio Connect when you already have an MCP-compatible client and want the shared Composio MCP URL, without creating an SDK session.”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”
   • [probe] “official MCP server documented at https://docs.composio.dev/docs/composio-connect”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://connect.composio.dev/mcp returned HTTP 401 with an OAuth challenge — the hosted …”

   proof ↗⚑ flag

   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

Generate

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

   weight 2 · round to Glama
   Composio—none0/10

   Evidence shows Composio can expose its own pre-built toolkits as hosted MCP servers (via `mcp:true` sessions or Composio Connect) and ships an OpenAPI spec for its own API, but there is no evidence of a feature letting developers upload a custom OpenAPI definition or their own code and have Composio auto-generate a hosted MCP server from it — the toolkits appear to be Composio-curated integrations, not user-supplied API/code onboarding.

   • [claimed-docs] “Opt into MCP by passing `mcp: true` when you create the session. The session then exposes its hosted MCP server.”
   • [claimed-docs] “Use Composio Connect when you already have an MCP-compatible client and want the shared Composio MCP URL, without creating an SDK session.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.composio.dev/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.composio.dev/docs/composio-connect”

   proof ↗⚑ flag

   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

Publish

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

   weight 2 · round to Glama
   Composio—none0/10

   Composio's docs describe hosting MCP servers built from its own toolkits/sessions and exposing a shared Composio Connect MCP endpoint for consuming tools, plus a CLI for local tool use — all about consuming Composio-provided tools, not about a developer publishing a custom MCP server for others to discover and install. No evidence of a publish/marketplace/registry flow for third-party-authored MCP servers.

   • [claimed-docs] “Opt into MCP by passing `mcp: true` when you create the session. The session then exposes its hosted MCP server.”
   • [claimed-docs] “Use Composio Connect when you already have an MCP-compatible client and want the shared Composio MCP URL, without creating an SDK session.”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”
   • [probe] “official MCP server documented at https://docs.composio.dev/docs/composio-connect”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://connect.composio.dev/mcp returned HTTP 401 with an OAuth challenge — the hosted …”

   proof ↗⚑ flag

   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

Triggers

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

   weight 2 · round to Composio
   Composio✓fullclaimed7/10

   Composio documents a triggers/webhooks system where developers register one webhook URL per project and Composio POSTs signed trigger events from connected apps, directly enabling event subscription instead of polling. However, missing for 10: independent/hands-on confirmation of trigger reliability, details on per-app trigger configuration granularity, and evidence of delivery guarantees or retry semantics.

   • [claimed-docs] “Composio delivers every event to one destination you control: your webhook URL. You register it once per project, and Composio `POST`s every…”

   proof ↗⚑ flag

   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

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 drawn
   Composio—none0/10

   Evidence covers sessions, MCP hosting, auth, triggers, CLI, and SDK installation, but nothing in the pack describes any analytics/usage dashboard, call volume metrics, per-user breakdowns, error rates, or cost reporting for consumed or published tools/servers.

   ⚑ flag

   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

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

   weight 2 · round to Composio
   Composio~partialprobed6/10

   Composio ships a full OpenAPI-documented API, SDK, CLI, and hosted MCP server covering sessions, auth, triggers, and tool execution (composio-docs-1,9,10; composio-probe-2,3,4), suggesting an API-first architecture where most UI-configurable actions (auth, webhooks, toolkits, white-labeling) have API/CLI equivalents. However there's no explicit documentation asserting full 1:1 parity between the dashboard UI and the API, and a community report shows at least one integration (Instagram connect) failing via the API path with a 400 error, suggesting some workflows may not work as smoothly as advertised. Missing for 10: an explicit parity statement or audit showing every UI feature (e.g. dashboard analytics, project settings) is API-accessible, and independent confirmation that failures like the Instagram case are edge cases rather than systemic gaps.

   • [claimed-docs] “session = composio.sessions.create(user_id="user_123")”
   • [claimed-docs] “Composio delivers every event to one destination you control: your webhook URL. You register it once per project, and Composio `POST`s every…”
   • [claimed-docs] “The Composio CLI gives coding agents and terminals a local tool surface. Codex, Claude Code, or a person at the terminal can connect apps, e…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.composio.dev/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.composio.dev/docs/composio-connect”
   • [probe] “official CLI documented at https://docs.composio.dev/docs/cli”
   • [community] “I tried using your cloud solution to test this and I couldnt pass the connect to Instagram through Composio. I got a 400 error. I checked Re…”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Composio—none0/10

   No evidence anywhere in the pack of a data export feature, open-format export, or account portability tooling; documentation covers sessions, MCP, auth, CLI, and triggers but nothing about exporting user data or configurations. The axis is fair for a SaaS integration platform holding connection/auth/trigger data, but no evidence supports it.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Composio—none0/10

   No evidence of an open-license public source repository; evidence only covers docs, CLI, SDK packages (which are published but not shown to be open-licensed source), and hosted MCP/cloud infrastructure. Composio appears to be primarily a closed hosted SaaS platform, with no mention of a license or public repo for its core source.

   ⚑ flag

   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

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Composio—none0/10

   All evidence describes Composio as a hosted/cloud SaaS (sessions, hosted MCP endpoint, cloud webhook delivery) with no documentation or mention of a self-hosted deployment option; community evidence even references 'your cloud solution.' Self-hosting is a fair axis for this type of platform product, but no evidence shows it is supported.

   • [claimed-docs] “session = composio.sessions.create(user_id="user_123")”
   • [claimed-docs] “Opt into MCP by passing `mcp: true` when you create the session. The session then exposes its hosted MCP server.”
   • [claimed-docs] “Composio delivers every event to one destination you control: your webhook URL. You register it once per project, and Composio `POST`s every…”
   • [community] “I tried using your cloud solution to test this and I couldnt pass the connect to Instagram through Composio. I got a 400 error. I checked Re…”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://connect.composio.dev/mcp returned HTTP 401 with an OAuth challenge — the hosted …”

   proof ↗⚑ flag

   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

Pricing

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

   weight 1 · round to Glama
   Composio—none0/10

   The evidence pack contains no mention of pricing tiers, free tier limits, or cost structure for Composio; it only covers technical docs (sessions, MCP, CLI, auth) and unrelated community/security notes. Pricing-plans is a fair axis for a SaaS developer platform, but there is no evidence it delivers a meaningful free tier.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Composio—none0/10

   The evidence pack contains no pricing pages, per-tool-call cost tables, or documented rate limits anywhere in the docs, probes, or community items — only technical usage docs and unrelated auth/security anecdotes. Missing for 10: any pricing page or per-call cost breakdown, any documented rate-limit thresholds, any plan comparison before commitment.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Composio—none0/10

   No evidence in the pack addresses data residency, region selection, or storage location controls for Composio's hosted services; nothing mentions where data is stored or any regional configuration options.

   ⚑ flag

   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

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

   weight 3 · round drawn
   Composio—none0/10

   No evidence in the pack addresses data usage for AI model training, opt-out settings, or privacy controls related to training data; documentation covers sessions, MCP, auth, and CLI but nothing about training-data exclusion policies.

   ⚑ flag

   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

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Composio—none0/10

   The evidence pack contains no documentation or mention of data retention policies, data deletion APIs, or user-controlled data lifecycle management for Composio — only session/auth/tool-execution mechanics are covered.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Composio—none0/10

   No evidence pack item addresses a telemetry/usage-tracking opt-out mechanism, privacy settings, or data collection policy for Composio; the docs cover sessions, MCP, auth, CLI, and triggers but nothing about telemetry controls.

   ⚑ flag

   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

Api

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

   weight 3 · round drawn
   Composio✓fullprobed8/10

   Composio exposes a documented OpenAPI spec (probe confirms HTTP 200 with openapi key), meta-tools for programmatic discovery of toolkits/apps, and a hosted MCP endpoint that agents can query to discover servers/tools, plus an llms.txt describing 1,400+ toolkits. This gives agents multiple documented, programmatic paths (REST/OpenAPI, meta-tools, MCP) to discover the catalog. missing for 10: a dedicated 'registry search/list' endpoint example with request/response schema, and independent third-party confirmation of catalog completeness beyond vendor docs.

   • [claimed-docs] “A session gives your agent meta tools, a small fixed set that discover, authenticate, and execute tools at runtime”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.composio.dev/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.composio.dev/docs/composio-connect”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.composio.dev/llms.txt # Composio Documentation > Composio powers 1,400+ toolkits, tool search, con…”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://connect.composio.dev/mcp returned HTTP 401 with an OAuth challenge — the hosted …”

   proof ↗⚑ flag

   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

Metadata

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

   weight 2 · round to Glama
   Composio~partialprobed5/10

   Composio's meta-tools and CLI let an agent/developer discover available toolkits and 'inspect schemas' at runtime (composio-docs-2, composio-docs-10, composio-docs-14), and the exposed openapi.json shows schema-level detail is available. However, there's no evidence of a browsable registry entry per listed server that surfaces transport type or hosting attributes before connecting — discovery is described as a runtime/meta-tool action rather than a pre-connection catalog view. Missing for 10: a documented registry/catalog page showing transport (SSE/stdio/hosted) and hosting attributes per toolkit, and independent confirmation that schema inspection works pre-connection as described.

   • [claimed-docs] “A session gives your agent meta tools, a small fixed set that discover, authenticate, and execute tools at runtime”
   • [claimed-docs] “The Composio CLI gives coding agents and terminals a local tool surface. Codex, Claude Code, or a person at the terminal can connect apps, e…”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.composio.dev/openapi.json — contains "openapi" key”
   • [claimed-docs] “Use Composio Connect when you already have an MCP-compatible client and want the shared Composio MCP URL, without creating an SDK session.”

   proof ↗⚑ flag

   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

Playground

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

   weight 2 · round to Glama
   Composio—none0/10

   No evidence pack item describes a browser-based inspector or playground for exercising MCP tools; documentation covers SDK sessions, CLI, meta-tools, and hosted MCP endpoints but never a web UI for pre-integration testing.

   ⚑ flag

   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

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
   Composio~partialprobed6/10

   Composio documents a large catalog (1,400+ toolkits) and built-in 'tool search' plus meta-tools that let an agent discover available tools/capabilities at runtime before execution, and toolkits can be filtered when creating a session. However, the evidence never shows a dedicated developer-facing browse/search UI or registry page for pre-wiring exploration — discovery is framed as an agent-runtime capability (meta-tools) rather than a human catalog browser. Missing for 10: a documented searchable catalog UI/dashboard for developers, independent hands-on confirmation of browsing by capability, and filtering/faceting details beyond toolkit name.

   • [claimed-docs] “A session gives your agent meta tools, a small fixed set that discover, authenticate, and execute tools at runtime”
   • [claimed-docs] “To restrict the set, pass `toolkits` when you create the session.”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.composio.dev/llms.txt # Composio Documentation > Composio powers 1,400+ toolkits, tool search, con…”

   proof ↗⚑ flag

   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

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 Composio
   Composio~partialprobed4/10

   Composio's CLI supports authentication (composio setup) and installing a native plugin into agents like Codex/Claude Code, and sessions can expose a hosted MCP server, but there is no documented workflow for staging/building a custom server artifact and pushing it through the CLI — Composio's MCP server is a pre-built hosted endpoint, not something a developer builds and deploys via CLI. missing for 10: CLI subcommands for building/staging a server, a 'push' or deploy step, and evidence of a full publish pipeline rather than just connect/execute/install.

   • [claimed-docs] “The Composio CLI gives coding agents and terminals a local tool surface. Codex, Claude Code, or a person at the terminal can connect apps, e…”
   • [claimed-docs] “Install the native plugin for Codex or Claude Code: composio setup --target auto”
   • [claimed-docs] “Opt into MCP by passing `mcp: true` when you create the session. The session then exposes its hosted MCP server.”
   • [claimed-docs] “Use Composio Connect when you already have an MCP-compatible client and want the shared Composio MCP URL, without creating an SDK session.”
   • [probe] “official CLI documented at https://docs.composio.dev/docs/cli”

   proof ↗⚑ flag

   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

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 to Composio
   Composio~partialprobed6/10

   Composio documents a 'provider' concept explicitly designed as adapters that convert Composio tools into the native tool format for a given framework 'so you don't write glue code,' and runtime probes confirm working npm/pip SDK packages, supporting a multi-framework client model. However, the evidence pack never explicitly names or documents adapters for Vercel AI SDK, LangChain, CrewAI, OpenAI, or Anthropic SDKs specifically. Missing for 10: named documentation pages or examples for each specific framework (Vercel AI SDK, LangChain, CrewAI, OpenAI/Anthropic SDKs), and independent hands-on confirmation that these specific adapters work as advertised.

   • [claimed-docs] “A provider is the adapter that turns Composio tools into the native tool format your framework expects, so you don't write glue code.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/composio/): `npm install @composio/core` and `uv pip install composio…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.composio.dev/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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 to Glama
   Composio—none0/10

   No evidence that Composio scans, audits, or vets listed toolkits/servers for malicious or vulnerable behavior before agents use them; docs cover sessions, auth, CLI, and MCP connectivity but nothing about security scanning of tool listings. The one security-related item (composio-comm-2) concerns a leaked API key exposing tokens, not proactive vetting of toolkit safety, so it does not support this axis.

   ⚑ flag

   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

Signals

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

   weight 2 · round to Glama
   Composio—none0/10

   No evidence that Composio publishes usage counts, health/liveness checks, quality scores, or verification badges for toolkits/servers to help developers compare them; documentation covers sessions, meta-tools, auth, and CLI but not curation/quality signals.

   ⚑ flag

   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

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 to Composio
   Composio✓fullprobed9/10

   Composio's core architecture is exactly meta-tools: a fixed small set (7 meta-tools) that discover, authorize, and execute tools on demand rather than dumping thousands of tool definitions into context, documented in detail with sessions, toolkit-scoping, and MCP delivery, and corroborated by a live probe confirming the hosted meta-tool/MCP endpoint is real. Missing for 10: independent third-party benchmarking of context-size savings or hands-on agent trace showing runtime tool search in action.

   • [claimed-docs] “A session gives your agent meta tools, a small fixed set that discover, authenticate, and execute tools at runtime”
   • [claimed-docs] “To restrict the set, pass `toolkits` when you create the session.”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”
   • [claimed-docs] “Opt into MCP by passing `mcp: true` when you create the session. The session then exposes its hosted MCP server.”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://connect.composio.dev/mcp returned HTTP 401 with an OAuth challenge — the hosted …”
   • [probe] “official MCP server documented at https://docs.composio.dev/docs/composio-connect”

   proof ↗⚑ flag

   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