Glama vs Pipedream MCP

Agent access

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

   weight 2 · round drawn
   Glama✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Pipedream MCP✓fullprobed8/10

   A live probe confirms Pipedream serves markdown-formatted docs (mcp.md) that explicitly reference and point to a full llms.txt documentation index at pipedream.com/docs/llms.txt, directly matching the agent-oriented docs story. missing for 10: no independent confirmation that an agent actually consumed llms.txt successfully end-to-end (only that it is served/discoverable).

   • [probe] “PROBE docs-md: HTTP 200 at https://pipedream.com/docs/connect/mcp.md > ## Documentation Index > Fetch the complete documentation index at: h…”
   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”

   proof ↗⚑ flag

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

   weight 2 · round to Pipedream MCP
   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

   Pipedream MCP~partialprobed6/10

   Pipedream MCP exposes a remote HTTP/SSE server and an SDK (@pipedream/sdk) that can be scripted programmatically, which supports headless/CI use, and the API is designed for developers to embed in their own apps/agents rather than requiring a GUI. However, the server requires a per-end-user binding (external user id) and OAuth-based account connection flows, which complicate fully unattended CI automation, and there is no explicit CI/headless-mode documentation or example. missing for 10: explicit CI/headless automation guide, evidence of non-interactive auth/token provisioning for unattended runs, and confirmation of stable long-running headless operation.

   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/pipedream-mcp/): `npm install @pipedream/sdk` completed into a throwa…”
   • [claimed-docs] “To use Pipedream MCP in your own app or agent to make tool calls on behalf of your users, you can get started for free in development mode”

   proof ↗⚑ flag

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

   weight 3 · round to Glama
   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

   Pipedream MCP—none0/10

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

   ⚑ flag

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

   weight 3 · round to Pipedream MCP
   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

   Pipedream MCP✓fullprobed9/10

   Pipedream ships an official documented MCP server (remote.mcp.pipedream.net / mcp.pipedream.com) explicitly designed for agents/apps to connect and make tool calls across 3,000+ APIs, with SSE/streamable HTTP support, built-in auth, and an SDK — and a live probe confirms the endpoint is real and responds to JSON-RPC per the documented protocol. Missing for 10: an end-to-end probe showing a fully successful tool call (the live test only reached the 'external user id required' auth step, not actual tool invocation).

   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [claimed-docs] “This is handled automatically by Pipedream’s MCP server and there’s no additional implementation required”
   • [claimed-docs] “The Pipedream MCP server supports both SSE and streamable HTTP transport types dynamically, with no configuration required by the developer …”
   • [claimed-docs] “As an end user: Connect your accounts through Pipedream MCP at mcp.pipedream.com”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/pipedream-mcp/): `npm install @pipedream/sdk` completed into a throwa…”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round drawn
   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

   Pipedream MCP—none0/10

   Evidence covers Pipedream's MCP server, SDK (@pipedream/sdk), and chat app, but no mention of an official CLI tool for AI-native workflows. Missing for 10: any documentation or reference to a Pipedream CLI product.

   ⚑ flag

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

   weight 3 · round to Pipedream MCP
   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

   Pipedream MCP✓fullprobed8/10

   Pipedream publishes detailed developer docs, an SDK (@pipedream/sdk), and a live MCP JSON-RPC endpoint (remote.mcp.pipedream.net) confirmed reachable and behaving per spec, giving AI-native developers a documented public API/protocol to drive tool calls programmatically. Missing for 10: independent third-party developer testimonials or case studies beyond vendor docs/probes.

   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [claimed-docs] “To use Pipedream MCP in your own app or agent to make tool calls on behalf of your users, you can get started for free in development mode”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/pipedream-mcp/): `npm install @pipedream/sdk` completed into a throwa…”

   proof ↗⚑ flag

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

   weight 2 · round to Pipedream MCP
   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

   Pipedream MCP~partialprobed7/10

   Pipedream MCP issues per-end-user, revocable credentials via built-in OAuth-style account connections, and the live server enforces an external-user-id binding before serving tools, showing real per-user credential scoping rather than a single shared key. However, there is no explicit documentation of fine-grained scope selection (e.g., choosing specific read/write permissions per tool or API) that would constitute true least-privilege configuration. missing for 10: explicit least-privilege scope controls (choosing minimal permission sets per credential), independent/hands-on confirmation of revocation actually restricting access.

   • [claimed-docs] “Pipedream Connect includes built-in user authentication for more than APIs via MCP, which means you don’t need to build any authorization fl…”
   • [claimed-docs] “As an end user: Connect your accounts through Pipedream MCP at mcp.pipedream.com”
   • [claimed-docs] “Revocable access: Users can revoke access to their connected accounts at any time”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to Pipedream MCP
   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

   Pipedream MCP✓fullprobed8/10

   Pipedream documents and ships an official SDK (@pipedream/sdk) with a PipedreamClient class, integration guides for AI frameworks (mcpClient.tools()), and a runtime probe confirms the package installs and exports the client as documented. Missing for 10: coverage of SDKs in multiple languages beyond JS/TS and independent third-party corroboration of SDK usage in production apps.

   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [claimed-docs] “To use Pipedream MCP in your own app or agent to make tool calls on behalf of your users, you can get started for free in development mode”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/pipedream-mcp/): `npm install @pipedream/sdk` completed into a throwa…”
   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Glama
   Glama~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Pipedream MCP—none0/10

   The evidence pack describes Pipedream MCP purely as a tool-calling interface (auth, transport, tool listing) with no mention of webhook subscriptions or event-driven notifications delivered through MCP itself.

   ⚑ flag

Agentic features

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

   weight 2 · round to Glama
   Glama~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Pipedream MCP—none0/10

   The evidence describes Pipedream MCP as a tool-calling gateway that lets agents invoke APIs on behalf of users in real time, with no mention of scheduled, triggered, or persistently-running background automations. Missing for 10: any documentation of triggers, cron schedules, event-driven workflows, or autonomous execution outside an active agent session.

   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [claimed-docs] “This is handled automatically by Pipedream’s MCP server and there’s no additional implementation required”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Glama
   Glama~partialprobed5/10

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

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

   proof ↗⚑ flag

   Pipedream MCP~partialclaimed3/10

   Pipedream provides docs with code snippets (docs-4, docs-5) and a live chat app (chat.pipedream.com) where users can try MCP tool calls interactively (docs-9), but there is no evidence of a dedicated interactive API reference/playground with runnable examples for the 3,000+ APIs. missing for 10: an actual interactive API explorer or sandboxed runnable code examples beyond a chat demo, independent confirmation of such a reference existing.

   • [claimed-docs] “Try out Pipedream MCP in our chat app at chat.pipedream.com”
   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [claimed-docs] “The Pipedream MCP server supports both SSE and streamable HTTP transport types dynamically, with no configuration required by the developer …”

   proof ↗⚑ flag

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

   weight 2 · round to Glama
   Glama✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Pipedream MCP—none0/10

   The evidence describes Pipedream's MCP server, SDK, and docs (including an llms.txt index), but nowhere mentions a downloadable OpenAPI or equivalent machine-readable API spec for its endpoints/tools.

   ⚑ flag

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

   weight 1 · round to Glama
   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

   Pipedream MCP~partialclaimed3/10

   Docs mention getting started in a free 'development mode' for testing tool calls (docs-10), implying some separation from production usage, but there is no explicit documentation of a sandbox environment, test data isolation, or guarantees that dev-mode calls don't touch real production accounts/data. Missing for 10: explicit sandbox/test-vs-prod environment docs, confirmation that test accounts are isolated from real user data, and independent verification of this isolation.

   • [claimed-docs] “To use Pipedream MCP in your own app or agent to make tool calls on behalf of your users, you can get started for free in development mode”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Glama—none0/10

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

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

   proof ↗⚑ flag

   Pipedream MCP—none0/10

   The evidence pack covers MCP tool usage, authentication, and transport, but contains no mention of API versioning scheme, version numbers, or a documented deprecation policy for the MCP server or SDK. missing for 10: any documented API version scheme, changelog, deprecation notice process, or backward-compatibility guarantees.

   ⚑ 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 Pipedream MCP
   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

   Pipedream MCP✓fullprobed8/10

   Docs describe per-end-user connected accounts with built-in auth/token storage/refresh handled by Pipedream, external_user_id scoping so agents act only on that user's credentials, and user-facing revocation of connected accounts; the live probe confirms the MCP server enforces an external user id binding before serving tools, corroborating the scoping claim. missing for 10: independent multi-tenant audit or case study showing token isolation at scale, and detail on scoped token permission granularity beyond per-account connection.

   • [claimed-docs] “Pipedream Connect includes built-in user authentication for more than APIs via MCP, which means you don’t need to build any authorization fl…”
   • [claimed-docs] “This is handled automatically by Pipedream’s MCP server and there’s no additional implementation required”
   • [claimed-docs] “As an end user: Connect your accounts through Pipedream MCP at mcp.pipedream.com”
   • [claimed-docs] “Revocable access: Users can revoke access to their connected accounts at any time”
   • [claimed-docs] “To use Pipedream MCP in your own app or agent to make tool calls on behalf of your users, you can get started for free in development mode”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”

   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 Pipedream MCP
   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

   Pipedream MCP✓fullprobed8/10

   Docs explicitly state Pipedream Connect/MCP handles OAuth/user authentication, token storage, and refresh automatically with no additional implementation required, and this is corroborated by a live probe showing the remote MCP endpoint enforcing per-user auth binding. Revocable access confirms credential lifecycle management beyond just initial OAuth. Missing for 10: explicit documentation of encryption-at-rest/vaulting mechanics for stored credentials and independent third-party verification of refresh behavior over time.

   • [claimed-docs] “Pipedream Connect includes built-in user authentication for more than APIs via MCP, which means you don’t need to build any authorization fl…”
   • [claimed-docs] “This is handled automatically by Pipedream’s MCP server and there’s no additional implementation required”
   • [claimed-docs] “Revocable access: Users can revoke access to their connected accounts at any time”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”

   proof ↗⚑ flag

White label

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

   weight 1 · round drawn
   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

   Pipedream MCP—none0/10

   The evidence describes Pipedream's built-in authentication handling and revocable user connections, but nothing in the pack mentions white-labeling the OAuth flow with custom branding or letting platform engineers substitute their own OAuth app credentials. This is a fair axis for a connect/auth platform, so absence of evidence yields 'none' rather than 'na'.

   • [claimed-docs] “Pipedream Connect includes built-in user authentication for more than APIs via MCP, which means you don’t need to build any authorization fl…”
   • [claimed-docs] “As an end user: Connect your accounts through Pipedream MCP at mcp.pipedream.com”
   • [claimed-docs] “Revocable access: Users can revoke access to their connected accounts at any time”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Glama—none0/10

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

   ⚑ flag

   Pipedream MCP—none0/10

   The evidence describes Pipedream MCP exposing thousands of individual API tools and handling auth/transport automatically, but nothing in the pack documents a bulk/batch operation capability (e.g., applying one action across many items or records in a single call). Missing for 10: any documentation of batch/bulk tool calls, looping over item sets, or multi-item transaction support.

   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [claimed-docs] “Slack: Send messages, manage channels, create reminders, and more”

   proof ↗⚑ flag

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

   weight 3 · round to Glama
   Glama~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Pipedream MCP—none0/10

   The evidence pack describes Pipedream MCP purely as a tool-calling/connector layer (auth, transport, tool listing) for agents to invoke APIs on demand — it contains no mention of defining rules, event triggers, or automatic actions firing on events. Missing for 10: any documentation of trigger/rule definitions, event-based workflow automation, or scheduled/conditional execution within the MCP server itself.

   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Glama
   Glama~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Pipedream MCP—none0/10

   The evidence pack describes Pipedream MCP purely as a tool-calling gateway (auth, tool discovery, transport) for invoking 3,000+ APIs on demand, with no mention of scheduling, cron triggers, or recurring workflow execution via MCP.

   ⚑ flag

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

   weight 1 · round drawn
   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

   Pipedream MCP—none0/10

   Evidence covers tool access, auth, and transport for Pipedream MCP, but nothing addresses versioning of automations, review workflows, or rollback capability. No mention of change history, diffing, approval flows, or reverting to prior configurations.

   ⚑ 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
   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

   Pipedream MCP—none0/10

   All evidence describes Pipedream operating its own hosted remote MCP server (exposing 3,000+ APIs/tools) that clients connect to — not a mechanism for a developer to take a locally-running custom MCP server and have Pipedream bridge/host it remotely without deployment. No evidence pack item mentions importing, registering, or proxying an external/local MCP server through Pipedream's platform.

   ⚑ 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 Glama
   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

   Pipedream MCP—none0/10

   The evidence describes authentication, revocable account access, and automatic tool loading, but nowhere documents allowlisting of specific MCP servers or granular per-tool access control for platform engineers. The docs even state tools are 'automatically loaded' rather than filtered, and no admin/allowlist configuration is described. missing for 10: allowlist configuration UI/API, per-tool enable/disable controls, evidence of restricting which servers an agent may reach.

   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [claimed-docs] “Revocable access: Users can revoke access to their connected accounts at any time”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”

   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
   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

   Pipedream MCP—none0/10

   No evidence describes any logging, audit trail, or replay capability for tool calls made through Pipedream MCP; documentation covers auth, transport, and connectivity but is silent on observability/audit logs. Missing for 10: any mention of a tool-call log, audit trail UI/API, replay mechanism, or retention/detail guarantees for platform engineers.

   ⚑ 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 Pipedream MCP
   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

   Pipedream MCP✓fullprobed9/10

   Docs and live probe confirm Pipedream MCP exposes 3,000+ APIs and 10,000+ tools with built-in auth, and the remote MCP endpoint is live and functioning (requiring per-user binding as documented). Missing for 10: independent third-party verification of the full catalog size beyond vendor docs.

   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [claimed-docs] “Pipedream Connect includes built-in user authentication for more than APIs via MCP, which means you don’t need to build any authorization fl…”
   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/pipedream-mcp/): `npm install @pipedream/sdk` completed into a throwa…”

   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 Pipedream MCP
   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

   Pipedream MCP✓fullprobed9/10

   Pipedream documents a hosted remote MCP endpoint (mcp.pipedream.com / remote.mcp.pipedream.net) that clients can point at without deploying infrastructure, with SSE/streamable HTTP transport auto-negotiated and tool loading handled server-side. A live probe confirms the endpoint is reachable and responds per the JSON-RPC protocol (requiring only a per-end-user binding parameter, not extra infra). Missing for 10: independent third-party (non-vendor) confirmation of a full end-to-end tool call succeeding beyond the initialize handshake.

   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [claimed-docs] “The Pipedream MCP server supports both SSE and streamable HTTP transport types dynamically, with no configuration required by the developer …”
   • [claimed-docs] “As an end user: Connect your accounts through Pipedream MCP at mcp.pipedream.com”
   • [claimed-docs] “Try out Pipedream MCP in our chat app at chat.pipedream.com”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”
   • [probe] “official MCP server documented at https://pipedream.com/docs/connect/mcp”

   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
   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

   Pipedream MCP—none0/10

   All evidence describes consuming Pipedream's existing hosted MCP server (mcp.pipedream.com / remote.mcp.pipedream.net) to call Pipedream's pre-built 3,000+ API integrations on behalf of end users — none of it shows a developer importing their own OpenAPI spec or custom code to generate a new hosted MCP server without protocol plumbing. Missing for 10: any documentation of OpenAPI import, custom-code-to-MCP conversion, or a 'create your own MCP server' workflow.

   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [claimed-docs] “Pipedream Connect includes built-in user authentication for more than APIs via MCP, which means you don’t need to build any authorization fl…”
   • [claimed-docs] “This is handled automatically by Pipedream’s MCP server and there’s no additional implementation required”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”

   proof ↗⚑ flag

Publish

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

   weight 2 · round to Glama
   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

   Pipedream MCP—none0/10

   All evidence describes Pipedream's own hosted MCP server (remote.mcp.pipedream.net) that exposes Pipedream's 3,000+ pre-built API integrations to developers' apps/agents — it does not show any mechanism for a third-party developer to publish their own custom MCP server on the platform for other users to discover and install. Missing for 10: any publishing/registry workflow, discovery/marketplace listing feature, or installation flow for user-authored MCP servers.

   ⚑ flag

Triggers

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

   weight 2 · round to Glama
   Glama~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Pipedream MCP—none0/10

   The evidence pack only describes Pipedream MCP as a tool-calling interface (action/tool invocation via JSON-RPC, authentication, transport details) — nothing shows agents subscribing to webhook/trigger events pushed from downstream apps via MCP; this is a request/response tool model, not an event-subscription model.

   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”

   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
   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

   Pipedream MCP—none0/10

   Evidence covers MCP connectivity, auth, transport, and tool loading, but nothing addresses usage analytics dashboards for call volumes, user counts, error rates, or cost tracking across servers/tools an org consumes or publishes.

   ⚑ flag

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

   weight 2 · round drawn
   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

   Pipedream MCP~partialprobed5/10

   Pipedream MCP exposes tool-calling and account-connection via API/MCP server (remote.mcp.pipedream.net, SDK), and end users can connect/revoke accounts via mcp.pipedream.com, but the evidence pack does not show that all UI-driven configuration (e.g., building/publishing custom workflows, managing app settings, full admin/dashboard functionality) is exposed through the API/MCP interface. missing for 10: evidence that non-tool-calling UI features (workflow building, org/team admin, billing, dashboard analytics) are also accessible via API/MCP, and independent confirmation beyond vendor docs.

   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [claimed-docs] “As an end user: Connect your accounts through Pipedream MCP at mcp.pipedream.com”
   • [claimed-docs] “Revocable access: Users can revoke access to their connected accounts at any time”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/pipedream-mcp/): `npm install @pipedream/sdk` completed into a throwa…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Glama—none0/10

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

   ⚑ flag

   Pipedream MCP—none0/10

   Pipedream MCP is a connectivity/integration layer for tool calls to third-party APIs; the evidence covers authentication, tool loading, and revocable access, but nothing addresses exporting a user's own data from Pipedream in open formats or account/data portability for leaving the platform.

   ⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round drawn
   Glama—none0/10

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

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

   proof ↗⚑ flag

   Pipedream MCP—none0/10

   All evidence describes Pipedream MCP as a hosted service (mcp.pipedream.com, remote.mcp.pipedream.net) with no mention of a self-hosted or open-source deployment option for the core MCP server; the SDK/npm package is a client library, not a self-hostable server.

   • [claimed-docs] “As an end user: Connect your accounts through Pipedream MCP at mcp.pipedream.com”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”
   • [claimed-docs] “To use Pipedream MCP in your own app or agent to make tool calls on behalf of your users, you can get started for free in development mode”

   proof ↗⚑ flag

Pricing

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

   weight 1 · round to Pipedream MCP
   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

   Pipedream MCP~partialprobed5/10

   Docs explicitly state developers can 'get started for free in development mode' and try the hosted chat app, and the SDK/server are confirmed live and installable without payment friction. However, there's no detail on what limits/quotas define the free tier (rate limits, tool-call caps, upgrade triggers), so it's unclear how 'meaningful' the free tier is for real prototyping at scale. Missing for 10: specific free-tier quotas/limits, comparison to paid tiers, and independent developer accounts confirming the free tier suffices for non-trivial prototyping.

   • [claimed-docs] “To use Pipedream MCP in your own app or agent to make tool calls on behalf of your users, you can get started for free in development mode”
   • [claimed-docs] “Try out Pipedream MCP in our chat app at chat.pipedream.com”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/pipedream-mcp/): `npm install @pipedream/sdk` completed into a throwa…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Glama—none0/10

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

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

   proof ↗⚑ flag

   Pipedream MCP—none0/10

   Evidence only covers MCP setup, auth, and transport mechanics; no citation discloses per-tool-call pricing, connection pricing tiers, or documented rate limits. A passing mention of 'free in development mode' does not constitute transparent pricing or rate-limit documentation.

   ⚑ flag

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

   weight 2 · round drawn
   Glama—none0/10

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

   ⚑ flag

   Pipedream MCP—none0/10

   No evidence anywhere in the pack mentions data residency, regional storage options, or compliance controls for where data is stored; the docs focus on tool access, authentication, and transport mechanics.

   ⚑ flag

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

   weight 3 · round drawn
   Glama—none0/10

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

   ⚑ flag

   Pipedream MCP—none0/10

   The evidence pack covers MCP connectivity, authentication, and revocable account access, but contains no mention of AI-training data usage policies or opt-out controls for Pipedream MCP.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Pipedream MCP
   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

   Pipedream MCP~partialclaimed4/10

   Docs confirm users can revoke connected-account access at any time, which covers a piece of deletion control, but there is no documented policy on data retention periods, deletion of stored request/response logs, or export/erasure guarantees. missing for 10: explicit data retention timelines, log/data deletion mechanisms beyond account revocation, compliance/GDPR-style deletion guarantees.

   • [claimed-docs] “Revocable access: Users can revoke access to their connected accounts at any time”
   • [claimed-docs] “As an end user: Connect your accounts through Pipedream MCP at mcp.pipedream.com”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Glama—none0/10

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

   ⚑ flag

   Pipedream MCP—none0/10

   No evidence anywhere in the pack addresses telemetry, analytics, or usage-tracking opt-out settings for Pipedream MCP; docs cover authentication, transport, and account revocation but not telemetry controls.

   ⚑ flag

Api

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

   weight 3 · round to Glama
   Glama✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Pipedream MCP~partialprobed5/10

   Pipedream documents a programmatic `mcpClient.tools()` call that 'automatically loads all available tools' for a connected app, and the live endpoint probe confirms the MCP server responds to JSON-RPC requests, showing some machine-readable tool discovery. However, there is no documented registry/catalog API for browsing the full list of 3,000+ integrated apps/servers before connecting — discovery is scoped per-user/per-app rather than a global catalog query. Missing for 10: a documented catalog/registry-listing endpoint (not just per-connection tools()), independent confirmation of full catalog enumeration.

   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”

   proof ↗⚑ flag

Metadata

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

   weight 2 · round to Glama
   Glama~partialprobed6/10

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

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

   proof ↗⚑ flag

   Pipedream MCP~partialclaimed4/10

   Docs show that tools can be listed/loaded via mcpClient.tools() and that transport (SSE/streamable HTTP) is documented, giving partial visibility into a server's capabilities before use, but there is no evidence of a registry listing with explicit input schemas or hosting attributes for inspection prior to connecting. missing for 10: schema inspection UI/API, hosting attribute metadata, and a registry-style browsing view for listed servers before connection.

   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [claimed-docs] “The Pipedream MCP server supports both SSE and streamable HTTP transport types dynamically, with no configuration required by the developer …”
   • [claimed-docs] “Slack: Send messages, manage channels, create reminders, and more”

   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
   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

   Pipedream MCP~partialprobed6/10

   Pipedream explicitly offers a browser-based 'chat app' at chat.pipedream.com for trying out its MCP tools before integrating, and mcp.pipedream.com lets users connect/authorize accounts, which functions as a lightweight playground. However, there's no dedicated 'MCP inspector' UI shown, no independent hands-on report confirming the chat app's tool-exercising experience, and the live endpoint requires per-user binding before serving tools. Missing for 10: independent/hands-on verification of the chat playground's tool-calling UX, and a dedicated inspector-style tool browser beyond the chat interface.

   • [claimed-docs] “Try out Pipedream MCP in our chat app at chat.pipedream.com”
   • [claimed-docs] “As an end user: Connect your accounts through Pipedream MCP at mcp.pipedream.com”
   • [probe] “PROBE mcp-endpoint (2026-09-05): POST initialize to https://remote.mcp.pipedream.net answered a JSON-RPC error over HTTP 400 ({"jsonrpc":"2.…”

   proof ↗⚑ flag

Search

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

   weight 3 · round to Glama
   Glama✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Pipedream MCP~partialclaimed4/10

   Pipedream advertises a large catalog (3,000+ APIs, 10,000+ tools) and lists example apps like Slack with their supported actions, implying some browsable catalog exists, but there is no direct evidence of a search/browse UI or capability-based filtering mechanism for developers to explore before integration. missing for 10: explicit search/filter interface, capability-tagging or query API, independent confirmation of browsing experience.

   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [claimed-docs] “Slack: Send messages, manage channels, create reminders, and more”
   • [claimed-docs] “Try out Pipedream MCP in our chat app at chat.pipedream.com”

   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 drawn
   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

   Pipedream MCP—none0/10

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

   ⚑ flag

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 Pipedream MCP
   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

   Pipedream MCP~partialprobed5/10

   Pipedream documents a generic MCP client integration page (docs/connect/mcp/ai-frameworks) showing a code snippet (mcpClient.tools()) for loading tools automatically, implying framework-agnostic SDK integration, and ships an official @pipedream/sdk package confirmed via runtime probe. However, the evidence pack never names or shows adapters for specific major frameworks like Vercel AI SDK, LangChain, CrewAI, or OpenAI/Anthropic SDKs explicitly — only a generic MCP client pattern is shown. Missing for 10: explicit documented code samples/adapters per named framework (LangChain, CrewAI, Vercel AI SDK, OpenAI/Anthropic SDKs), independent hands-on confirmation of each integration working.

   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/mcp-infrastructure/proofs/pipedream-mcp/): `npm install @pipedream/sdk` completed into a throwa…”

   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
   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

   Pipedream MCP—none0/10

   Evidence covers authentication, transport, tool loading, and revocable access, but nothing in the pack describes any scanning, vetting, or security review process for listed servers/tools before agents use them.

   ⚑ flag

Signals

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

   weight 2 · round to Glama
   Glama!disputedcontradicted5/10

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

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

   proof ↗⚑ flag

   Pipedream MCP—none0/10

   Evidence only covers Pipedream MCP's functionality (auth, transport, tool listing) but contains no usage counts, health/liveness checks, quality scores, or verification badges for comparing servers.

   ⚑ flag

Tool search

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

   weight 2 · round drawn
   Glama—none0/10

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

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

   proof ↗⚑ flag

   Pipedream MCP—none0/10

   Pipedream MCP's own docs describe `mcpClient.tools()` as automatically loading *all* available tools rather than exposing meta-tools (e.g., search_tools/load_tool) for on-demand discovery, and no evidence pack item mentions a meta-tool/dynamic-search pattern for reducing context load.

   • [claimed-docs] “tools: await mcpClient.tools(), // Automatically loads all available tools”
   • [claimed-docs] “Add Pipedream MCP to your app or agent to make tool calls on behalf of your users to 3,000+ APIs and 10,000+ tools.”

   proof ↗⚑ flag