Glama vs Manufact

Agent access

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

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

   Manufact✓fullprobed9/10

   A direct probe confirms llms.txt is live at https://docs.manufact.com/llms.txt (HTTP 200) with a structured index of docs, giving agents a machine-readable entry point, and this is corroborated by the docs site itself supporting agent-oriented navigation (mcp.md, cli.md, dashboard docs) that an agent could traverse. Missing for 10: no explicit vendor statement promoting llms.txt as a supported agent workflow, and no independent community confirmation of an agent successfully consuming it.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.manufact.com/llms.txt # Docs - Manufact Cloud: Deploy, monitor, and manage MCP servers on Manufact…”
   • [claimed-docs] “exposes the platform, organizations, servers, deployments, logs, and observability, as MCP tools, so you can manage everything from Cursor, …”

   proof ↗⚑ flag

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

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

   Manufact✓fullprobed7/10

   Manufact ships a CLI for local runs/deploys and API keys explicitly designed for 'REST API, CI pipelines, and scripts,' supporting headless automation of deployments and management outside the dashboard UI (manufact-docs-15, manufact-docs-16, manufact-docs-17, manufact-docs-5). Missing for 10: a concrete CI pipeline example/integration guide (e.g. GitHub Actions snippet), an OpenAPI spec (probe found 404s), and independent/hands-on corroboration of CI usage.

   • [claimed-docs] “Run your MCP server locally with hot reload + inspector”
   • [claimed-docs] “Deploys the current project to Manufact Cloud.”
   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”
   • [claimed-docs] “Trigger deployment: deploy a branch on demand.”
   • [probe] “official CLI documented at https://docs.manufact.com/cli”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.manufact.com/openapi.json, https://docs.manufact.com/swagger.json, https://docs.manufac…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Glama✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   Manufact✓fullclaimed7/10

   Manufact lets users paste an MCP server URL and Manufact 'connects directly for Chat, testing, and the publish workflow,' meaning the platform itself invokes the pasted server's tools; testing docs also describe executing across different MCP clients/models. missing for 10: no independent/hands-on confirmation of actual tool invocation behavior, and no detail on tool-call mechanics or error handling.

   • [claimed-docs] “paste your MCP URL. No deploy required: Manufact connects directly for Chat, testing, and the publish workflow.”
   • [claimed-docs] “Manufact executes them across different MCP clients and LLM models”
   • [claimed-docs] “You get one-click installs or copy-paste configuration for”

   proof ↗⚑ flag

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

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

   Manufact✓fullprobed8/10

   Manufact ships an official MCP server that exposes the platform (orgs, servers, deployments, logs, observability) as MCP tools so agents like Cursor and Claude can connect and manage everything, with one-click installs/copy-paste config for clients and a dedicated docs page confirmed by probe (manufact-docs-14, manufact-docs-18, manufact-probe-3). Missing for 10: independent/hands-on confirmation that the MCP server connection works smoothly in practice (community evidence is thin/confused, e.g. manufact-comm-3) and clearer detail on auth/session robustness (manufact-comm-2 notes reauth issues in the broader MCP ecosystem).

   • [claimed-docs] “exposes the platform, organizations, servers, deployments, logs, and observability, as MCP tools, so you can manage everything from Cursor, …”
   • [claimed-docs] “You get one-click installs or copy-paste configuration for”
   • [probe] “official MCP server documented at https://docs.manufact.com/mcp”
   • [community] “Noted an issue with the offline_access OAuth scope causing frequent reauthentication requests from clients (citing a related Codex bug); man…”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

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

   Manufact✓fullprobed8/10

   Manufact documents an official CLI with concrete commands (local dev with hot reload/inspector, deploy to Manufact Cloud) and a dedicated cli.md/cli docs page confirmed by probe, fitting the agentic/AI-native workflow of managing MCP servers from the terminal. Missing for 10: independent/hands-on community validation of the CLI itself and a fuller command reference beyond run/deploy.

   • [claimed-docs] “Run your MCP server locally with hot reload + inspector”
   • [claimed-docs] “Deploys the current project to Manufact Cloud.”
   • [probe] “official CLI documented at https://docs.manufact.com/cli”

   proof ↗⚑ flag

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

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

   Manufact~partialprobed5/10

   Manufact documents API-key based programmatic access to a REST API for CI/scripts and also exposes platform functionality as MCP tools usable from AI clients like Cursor/Claude, which supports AI-native driving of the product. However, a probe for actual API documentation (OpenAPI/swagger spec) returned 404s across all candidate paths, so there's no verifiable public API reference beyond a passing mention. Missing for 10: a discoverable OpenAPI/swagger spec or full REST API reference docs, and independent confirmation the REST API works as described.

   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”
   • [claimed-docs] “exposes the platform, organizations, servers, deployments, logs, and observability, as MCP tools, so you can manage everything from Cursor, …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.manufact.com/openapi.json, https://docs.manufact.com/swagger.json, https://docs.manufac…”
   • [probe] “official MCP server documented at https://docs.manufact.com/mcp”

   proof ↗⚑ flag

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

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

   Manufact—none0/10

   Docs confirm API keys exist for programmatic/CI access (manufact-docs-17), but there is no evidence of scoping, permission levels, or least-privilege configuration for these keys or for agent-specific credentials. Missing for 10: any mention of scoped/role-based API key permissions, per-agent credential restriction, or least-privilege access controls.

   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to Glama
   Glama~partialprobed3/10

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

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

   proof ↗⚑ flag

   Manufact—none0/10

   Evidence shows an official CLI, REST API with API keys, and an MCP server for managing the platform, but no documented client SDKs (e.g., language libraries) for building against Manufact programmatically; the openapi spec probe also returned 404s, suggesting no formal API/SDK artifact is published.

   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.manufact.com/openapi.json, https://docs.manufact.com/swagger.json, https://docs.manufac…”
   • [probe] “official CLI documented at https://docs.manufact.com/cli”

   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

   Manufact—none0/10

   No evidence in the pack mentions webhooks or event subscription mechanisms; Manufact's docs cover deployment, observability, MCP tool exposure, and CLI, but nothing about outbound webhook subscriptions for events.

   ⚑ flag

Agentic features

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

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

   Manufact~partialclaimed4/10

   Manufact offers some automated background actions tied to deployment events—auto-running a publish checklist after each successful deployment and automated protocol-compliance audits—but these are CI/CD-style triggers, not general-purpose autonomous agent automations that a user configures to run independently in the background. Missing for 10: evidence of user-defined scheduled/triggered autonomous workflows beyond deployment-linked checks, no mention of persistent background agents or cron-like automation configuration, and no independent confirmation that these automations run reliably unattended.

   • [claimed-docs] “you can start a checklist automatically after each successful deployment”
   • [claimed-docs] “runs an automated audit of your server for protocol compliance and platform readiness”
   • [claimed-docs] “end-to-end checks that exercise your server live in ChatGPT and Claude”
   • [claimed-docs] “Trigger deployment: deploy a branch on demand.”

   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

   Manufact—none0/10

   Manufact documents a REST API (via API keys) and a testing dashboard that runs test suites across MCP clients/models, but there is no evidence of an interactive API reference with runnable examples (e.g., a Swagger/OpenAPI explorer) — a direct probe for openapi.json/swagger.json returned 404s. Missing for 10: any interactive API reference UI, runnable code examples for the REST API, or OpenAPI spec exposure.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.manufact.com/openapi.json, https://docs.manufact.com/swagger.json, https://docs.manufac…”
   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”
   • [claimed-docs] “Manufact executes them across different MCP clients and LLM models”

   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

   Manufact—none0/10

   Manufact provides a REST API and API keys (manufact-docs-17) but the probe explicitly found no OpenAPI/swagger spec at any standard location (manufact-probe-2), and no docs mention a downloadable machine-readable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.manufact.com/openapi.json, https://docs.manufact.com/swagger.json, https://docs.manufac…”
   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”

   proof ↗⚑ flag

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

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

   Manufact~partialclaimed6/10

   Docs show per-branch preview environments with distinct MCP URLs, on-demand deployment triggers, local hot-reload/inspector runs, and an explicit separate production-branch setting — all consistent with testing in isolation from production. However, there's no explicit statement about data isolation or guarantees that sandbox testing cannot touch production data/state. Missing for 10: explicit data-isolation guarantees between preview/local and production environments, and independent confirmation that preview deployments don't share production data stores.

   • [claimed-docs] “Preview environments are created per branch. Each gets its own MCP URL”
   • [claimed-docs] “Trigger deployment: deploy a branch on demand.”
   • [claimed-docs] “Run your MCP server locally with hot reload + inspector”
   • [claimed-docs] “Set which Git branch serves your canonical production URL from the Deployment paths & triggers section”
   • [claimed-docs] “Manufact executes them across different MCP clients and LLM models”

   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

   Manufact—none0/10

   Manufact documents a REST API and API keys for programmatic access, but there is no evidence of API versioning or a documented deprecation policy; an openapi spec probe returned 404s across all candidate paths. Missing for 10: versioned API scheme, changelog/deprecation policy documentation, any mention of backward-compatibility guarantees.

   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.manufact.com/openapi.json, https://docs.manufact.com/swagger.json, https://docs.manufac…”

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

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

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

   proof ↗⚑ flag

   Manufact—none0/10

   Manufact's evidence covers deployment, observability, publish checks, API keys, and MCP client connections for the platform-engineer's own organization, but there is no mention of per-end-user account isolation, scoped tokens per end user, or mechanisms for agents to act only on individual end-user credentials. Missing for 10: any documentation of end-user-scoped OAuth/token issuance, multi-tenant credential isolation, or per-user connected account management.

   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”
   • [claimed-docs] “exposes the platform, organizations, servers, deployments, logs, and observability, as MCP tools, so you can manage everything from Cursor, …”
   • [claimed-docs] “URL-connected servers that use the Manufact proxy can now be downgraded back to a direct external connection from Settings.”

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

   Manufact—none0/10

   Manufact is an MCP server deployment/observability platform; there is no evidence it runs OAuth flows for downstream tools or vaults credentials with automatic token refresh. The community note about offline_access OAuth scope refers to reauthentication bugs, not a credential-vaulting feature. This is an applicable axis for a platform managing MCP servers/tools, but no supporting evidence exists.

   • [community] “Noted an issue with the offline_access OAuth scope causing frequent reauthentication requests from clients (citing a related Codex bug); man…”

   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

   Manufact—none0/10

   No evidence in the pack addresses white-labeling the OAuth/authorization flow, custom branding, or bringing your own OAuth app credentials; the docs cover deployment, testing, observability, API keys for programmatic access, but nothing about customizable authorization UI or client credentials. Missing for 10: any mention of white-label branding, custom OAuth client ID/secret configuration, or customizable consent screens.

   ⚑ 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

   Manufact—none0/10

   Manufact's docs describe per-server actions (deploy, test, publish-check) and an MCP tool surface for managing servers/deployments/logs, but nothing describes performing an operation across many items/servers simultaneously (e.g., bulk deploy, bulk test, bulk delete). The axis is plausible for a management platform like this, but no evidence supports it.

   • [claimed-docs] “Trigger deployment: deploy a branch on demand.”
   • [claimed-docs] “Manufact executes them across different MCP clients and LLM models”
   • [claimed-docs] “exposes the platform, organizations, servers, deployments, logs, and observability, as MCP tools, so you can manage everything from Cursor, …”
   • [claimed-docs] “The history table shows every deployment with its MCP URL, source branch and commit, duration, creation time, and the latest completed publi…”

   proof ↗⚑ flag

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

   Manufact—none0/10

   Manufact is an MCP server deployment/observability platform; nothing in the evidence describes scheduling recurring jobs, cron-like triggers, or recurring workflow automation—deployments are triggered on push/on-demand, not on a schedule. missing for 10: any cron/scheduler feature, recurring job configuration, or workflow automation trigger based on time intervals.

   • [claimed-docs] “Trigger deployment: deploy a branch on demand.”
   • [claimed-docs] “you can start a checklist automatically after each successful deployment”
   • [claimed-docs] “Set which Git branch serves your canonical production URL from the Deployment paths & triggers section”

   proof ↗⚑ flag

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

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

   Manufact~partialclaimed5/10

   Manufact deploys from GitHub with branch-based preview environments, deployment history showing commit/branch and publish checklist scores, and on-demand trigger deployment—giving a form of version tracking and deployment history, but there is no explicit rollback mechanism (e.g., 'revert to previous deployment') or automation-specific review/approval workflow described. missing for 10: explicit rollback/revert capability for deployments, versioned diff/review UI for automations themselves (not just deployments), and independent confirmation that history table supports reverting to prior versions.

   • [claimed-docs] “Preview environments are created per branch. Each gets its own MCP URL”
   • [claimed-docs] “Trigger deployment: deploy a branch on demand.”
   • [claimed-docs] “The history table shows every deployment with its MCP URL, source branch and commit, duration, creation time, and the latest completed publi…”
   • [claimed-docs] “Set which Git branch serves your canonical production URL from the Deployment paths & triggers section”

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

   Manufact✓fullclaimed8/10

   Docs explicitly state you can 'paste your MCP URL. No deploy required: Manufact connects directly for Chat, testing, and the publish workflow,' and a changelog entry confirms URL-connected servers via proxy can be downgraded to direct external connection, showing this is a real managed remote-connection mode distinct from GitHub deploys. Missing for 10: independent/hands-on confirmation beyond vendor docs and more detail on how 'local' servers specifically get bridged (vs. any external URL).

   • [claimed-docs] “paste your MCP URL. No deploy required: Manufact connects directly for Chat, testing, and the publish workflow.”
   • [claimed-docs] “URL-connected servers that use the Manufact proxy can now be downgraded back to a direct external connection from Settings.”
   • [claimed-docs] “Preview environments are created per branch. Each gets its own MCP URL”

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

   Manufact—none0/10

   Manufact's docs cover deployment, testing, observability, and MCP server management, but there is no mention of allowlisting servers/tools or per-tool access control for agents. Missing for 10: any documentation of tool/server allowlists, per-tool permission scoping, or gateway-level access control policies.

   • [claimed-docs] “shows individual events: every request flowing through the gateway, refreshed every few seconds”
   • [claimed-docs] “exposes the platform, organizations, servers, deployments, logs, and observability, as MCP tools, so you can manage everything from Cursor, …”

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

   Manufact~partialclaimed6/10

   Manufact's observability dashboard shows individual gateway events refreshed every few seconds, with optional full request/response payload capture, giving platform-engineers a log of tool calls suitable for auditing; the deployment history table also links MCP URLs, commits, and checklist scores. However, there's no explicit mention of replay functionality, retention/export controls, or fine-grained per-tool-call audit trail structure beyond the event list. Missing for 10: explicit replay capability, log retention/export details, and independent/hands-on confirmation of audit completeness.

   • [claimed-docs] “shows individual events: every request flowing through the gateway, refreshed every few seconds”
   • [claimed-docs] “Toggle Capture payloads to also store full request and response bodies for each event”
   • [claimed-docs] “The history table shows every deployment with its MCP URL, source branch and commit, duration, creation time, and the latest completed publi…”

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

   Manufact✓fullclaimed8/10

   Manufact's docs describe hosted MCP servers reachable via a per-deployment MCP URL (docs-4, docs-6), with dashboard flows to paste an existing MCP URL with 'No deploy required' for connecting clients (docs-2), and one-click/copy-paste client configuration (docs-18) so any MCP-compatible client can point at the hosted URL without managing infrastructure. Manufact Cloud handles the deployment/hosting infra itself (docs-1, docs-3, docs-16), fulfilling the 'no infrastructure to deploy' promise for the client side. Missing for 10: independent/hands-on confirmation that a client actually connects and reaches downstream tools end-to-end, and more detail on latency/reliability of the hosted proxy path.

   • [claimed-docs] “paste your MCP URL. No deploy required: Manufact connects directly for Chat, testing, and the publish workflow.”
   • [claimed-docs] “Preview environments are created per branch. Each gets its own MCP URL”
   • [claimed-docs] “The history table shows every deployment with its MCP URL, source branch and commit, duration, creation time, and the latest completed publi…”
   • [claimed-docs] “You get one-click installs or copy-paste configuration for”
   • [claimed-docs] “deploy from GitHub in minutes”

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

   Manufact~partialprobed5/10

   Manufact clearly lets developers deploy existing code (via GitHub templates or CLI) into a hosted MCP server without handling protocol plumbing, with deployment history, publish checks, and observability handled by the platform (manufact-docs-3, manufact-docs-16, manufact-docs-7). However, there is no evidence of an OpenAPI-to-MCP conversion feature — the openapi.json probe returned 404s and no docs mention importing an OpenAPI spec to generate an MCP server. missing for 10: OpenAPI spec ingestion/conversion workflow, independent confirmation of code-to-MCP transformation beyond GitHub template deploy.

   • [claimed-docs] “Selecting a template creates a new repository from the template in your connected GitHub account or organization and deploys it”
   • [claimed-docs] “Deploys the current project to Manufact Cloud.”
   • [claimed-docs] “runs an automated audit of your server for protocol compliance and platform readiness”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.manufact.com/openapi.json, https://docs.manufact.com/swagger.json, https://docs.manufac…”

   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

   Manufact~partialclaimed6/10

   Manufact provides a full publish workflow (deploy, publish checklist audit, end-to-end checks in ChatGPT/Claude) and one-click install/copy-paste configs for connecting clients, which covers distribution and installation by others. However there is no explicit evidence of a public marketplace, registry, or discovery mechanism where other developers browse and find published servers. Missing for 10: public server marketplace/registry for discovery, evidence of third-party users finding/installing another developer's server organically, independent confirmation of the publish-to-discovery pipeline.

   • [claimed-docs] “paste your MCP URL. No deploy required: Manufact connects directly for Chat, testing, and the publish workflow.”
   • [claimed-docs] “runs an automated audit of your server for protocol compliance and platform readiness”
   • [claimed-docs] “end-to-end checks that exercise your server live in ChatGPT and Claude”
   • [claimed-docs] “You get one-click installs or copy-paste configuration for”
   • [claimed-docs] “copy a fix prompt into your own coding agent, or run the built-in autofix flow”

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

   Manufact~partialcommunity5/10

   Manufact's observability dashboard shows per-event traffic through the gateway with optional payload capture, giving call volume and request-level visibility, and community feedback (manufact-comm-1) praises 'analytics, logs' as impressive. However there's no documented breakdown by user, explicit error-rate reporting, or per-server/tool cost analytics — billing shows only org-wide spend limits, not tool-level cost. Missing for 10: per-user attribution, explicit error/failure metrics, and per-server/tool cost breakdowns in the observability view.

   • [claimed-docs] “shows individual events: every request flowing through the gateway, refreshed every few seconds”
   • [claimed-docs] “Toggle Capture payloads to also store full request and response bodies for each event”
   • [claimed-docs] “Owners and admins can set a monthly spend limit for metered usage beyond included credits from the Billing page.”
   • [community] “Impressed with the demo video, particularly the analytics, logs, and test suite features, but pricing page credit system unclear and no visi…”

   proof ↗⚑ flag

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

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

   Manufact~partialprobed6/10

   Manufact ships an official MCP server exposing platform, orgs, servers, deployments, logs, and observability as tools, plus a CLI and REST API keys for programmatic access (manufact-docs-14,15,16,17), giving broad UI-parity for AI-native users. However, the probe found no discoverable OpenAPI/swagger spec (404s), so full REST API coverage (e.g. billing, connect-clients config, publish checklist) is unverified and some UI actions may lack documented programmatic equivalents. missing for 10: a published OpenAPI/REST API reference confirming full parity, and independent/hands-on confirmation that every UI action is API-reachable.

   • [claimed-docs] “exposes the platform, organizations, servers, deployments, logs, and observability, as MCP tools, so you can manage everything from Cursor, …”
   • [claimed-docs] “Run your MCP server locally with hot reload + inspector”
   • [claimed-docs] “Deploys the current project to Manufact Cloud.”
   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.manufact.com/openapi.json, https://docs.manufact.com/swagger.json, https://docs.manufac…”
   • [probe] “official MCP server documented at https://docs.manufact.com/mcp”
   • [probe] “official CLI documented at https://docs.manufact.com/cli”

   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

   Manufact—none0/10

   Evidence shows Manufact deploys MCP servers from user-owned GitHub repos and offers an API/CLI for programmatic access (manufact-docs-16, manufact-docs-17, manufact-probe-4), but there is no documentation of an explicit 'export all your data' feature covering logs, observability payloads, deployment history, or test results in open/portable formats, nor any account-closure data-export workflow.

   • [claimed-docs] “Selecting a template creates a new repository from the template in your connected GitHub account or organization and deploys it”
   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”
   • [claimed-docs] “shows individual events: every request flowing through the gateway, refreshed every few seconds”
   • [probe] “official CLI documented at https://docs.manufact.com/cli”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Glama—none0/10

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

   ⚑ flag

   Manufact—none0/10

   No evidence anywhere in the pack indicates Manufact's own source code is open-licensed or publicly available; all references are to deploying/managing user MCP servers, not Manufact's own codebase. This is a fair question (SaaS platforms can be open-source) but no evidence supports it.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Glama—none0/10

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

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

   proof ↗⚑ flag

   Manufact—none0/10

   All evidence describes deploying MCP servers to 'Manufact Cloud' (docs-1, docs-3, docs-16) and a CLI for local dev/testing (docs-15) plus REST/API keys for programmatic access (docs-17), but nothing indicates the Manufact platform itself (dashboard, gateway, observability, publish-checks) can be self-hosted outside their cloud.

   • [claimed-docs] “deploy from GitHub in minutes”
   • [claimed-docs] “Deploys the current project to Manufact Cloud.”
   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.manufact.com/llms.txt # Docs - Manufact Cloud: Deploy, monitor, and manage MCP servers on Manufact…”

   proof ↗⚑ flag

Pricing

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

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

   Manufact~partialcommunity3/10

   Docs mention 'included credits' and a spend-limit control for usage beyond them, implying some free/starter allotment, but there is no explicit description of a free tier's scope or limits for connecting tools, and community feedback explicitly calls the credit/pricing system unclear ahead of deployment. missing for 10: explicit free-tier definition, limits on tool connections/servers, and confirmation that the free tier is 'meaningful' for prototyping.

   • [claimed-docs] “Owners and admins can set a monthly spend limit for metered usage beyond included credits from the Billing page.”
   • [community] “Impressed with the demo video, particularly the analytics, logs, and test suite features, but pricing page credit system unclear and no visi…”

   proof ↗⚑ flag

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

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

   Manufact!disputedcontradicted3/10

   Manufact documents a spend-limit/billing feature (monthly cap for metered usage beyond included credits) but no per-tool-call pricing or rate-limit documentation exists, and a community reviewer explicitly reports the credit/pricing system is unclear with no visibility into pay-as-you-go costs after plan limits, contradicting any claim of transparent pricing. missing for 10: per-tool-call/connection pricing breakdown, documented rate limits, resolution of the community-reported cost opacity.

   • [claimed-docs] “Owners and admins can set a monthly spend limit for metered usage beyond included credits from the Billing page.”
   • [community] “Impressed with the demo video, particularly the analytics, logs, and test suite features, but pricing page credit system unclear and no visi…”

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

   Manufact—none0/10

   No evidence anywhere in the pack mentions data region selection, residency options, or geographic deployment controls; Manufact Cloud deployment docs discuss branches, environments, and MCP URLs but never data locality. Missing for 10: any mention of region/residency selection, data center location options, or compliance certifications tied to geography.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Glama—none0/10

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

   ⚑ flag

   Manufact—none0/10

   Manufact is an MCP server deployment/observability platform; no evidence in the pack addresses data retention policies, deletion controls, or data lifecycle management for stored logs, payloads, or deployment data. Observability docs mention capturing payloads (manufact-docs-13) but nothing about retention periods or user-initiated deletion.

   ⚑ flag

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

   Manufact—none0/10

   No evidence pack item mentions telemetry, usage tracking, or an opt-out/privacy setting for such data collection; the docs cover deployment, observability of user's own MCP traffic, and billing, but nothing about Manufact's own telemetry practices.

   ⚑ 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

   Manufact~partialprobed5/10

   Manufact exposes an official MCP server (manufact-docs-14) that surfaces platform data—organizations, servers, deployments, logs—as MCP tools, letting an AI agent programmatically query the servers it has deployed from clients like Cursor or Claude. However, there is no documented public REST/OpenAPI catalog for external discovery (the openapi probe returned 404s), and the emphasis is on managing one's own deployed servers rather than browsing a broader tool/server catalog. Missing for 10: a documented REST/OpenAPI registry endpoint, evidence of cross-tenant or public catalog discovery, and independent confirmation of programmatic catalog querying beyond the MCP management tools.

   • [claimed-docs] “exposes the platform, organizations, servers, deployments, logs, and observability, as MCP tools, so you can manage everything from Cursor, …”
   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.manufact.com/openapi.json, https://docs.manufact.com/swagger.json, https://docs.manufac…”
   • [probe] “official MCP server documented at https://docs.manufact.com/mcp”

   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

   Manufact~partialclaimed4/10

   Manufact's dashboard exposes hosting/deployment attributes (MCP URL, branch, commit, publish-checklist score) and a testing flow that runs across MCP clients/models, which implies some pre-connection inspection, but there's no explicit documentation of viewing a server's tool list or input schemas before connecting. Missing for 10: explicit tool/input-schema inspection UI, transport-type display, and any independent/hands-on confirmation of this inspection workflow.

   • [claimed-docs] “paste your MCP URL. No deploy required: Manufact connects directly for Chat, testing, and the publish workflow.”
   • [claimed-docs] “The history table shows every deployment with its MCP URL, source branch and commit, duration, creation time, and the latest completed publi…”
   • [claimed-docs] “runs an automated audit of your server for protocol compliance and platform readiness”
   • [claimed-docs] “Manufact executes them across different MCP clients and LLM models”

   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

   Manufact~partialclaimed6/10

   Manufact's dashboard lets developers paste an MCP URL for direct connection and 'Chat, testing' before publishing (manufact-docs-2), and testing runs across different MCP clients/models (manufact-docs-11), which supports exercising tools pre-integration; the CLI also offers a local inspector (manufact-docs-15). However, this is presented as an integrated dashboard/testing workflow rather than a dedicated browser-based 'inspector/playground' UI, and no screenshots, hands-on walkthrough, or independent corroboration of the playground UX are provided. Missing for 10: concrete UI evidence/screenshots of a dedicated tool-invocation playground, independent hands-on confirmation, and detail on how individual tool calls are exercised interactively.

   • [claimed-docs] “paste your MCP URL. No deploy required: Manufact connects directly for Chat, testing, and the publish workflow.”
   • [claimed-docs] “Manufact executes them across different MCP clients and LLM models”
   • [claimed-docs] “Run your MCP server locally with hot reload + inspector”

   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

   Manufact—none0/10

   Manufact is a deploy/manage/observe platform for MCP servers you build and own — there is no evidence of a searchable public catalog/registry of third-party MCP servers or tools that a developer can browse by capability before wiring into an agent. All docs relate to deploying, testing, and monitoring your own server, not discovering existing ones.

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

   Manufact~partialprobed6/10

   Manufact has an official CLI documented with local run/hot-reload and a deploy command that pushes the project to Manufact Cloud (manufact-docs-15, manufact-docs-16, manufact-probe-4), plus API keys for programmatic/CI authentication (manufact-docs-17) and one-click/copy-paste install into agent clients (manufact-docs-18). However, the docs emphasize a GitHub/dashboard-driven deploy flow rather than a fully CLI-driven auth→build→push→install pipeline, and there's no explicit CLI login/auth command or CLI-based install-into-agent step shown. missing for 10: explicit CLI authenticate command, CLI-triggered install-into-agent step, and independent/hands-on confirmation that the full workflow (auth, build, push, install) works end-to-end via CLI alone.

   • [claimed-docs] “Run your MCP server locally with hot reload + inspector”
   • [claimed-docs] “Deploys the current project to Manufact Cloud.”
   • [claimed-docs] “API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts.”
   • [claimed-docs] “You get one-click installs or copy-paste configuration for”
   • [probe] “official CLI documented at https://docs.manufact.com/cli”

   proof ↗⚑ flag

Frameworks

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

   weight 2 · round drawn
   Glama—none0/10

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

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

   proof ↗⚑ flag

   Manufact—none0/10

   Manufact's docs describe connecting hosted MCP servers to MCP clients like Cursor, Claude, and ChatGPT (manufact-docs-14, manufact-docs-18), but there is no evidence of documented adapters or integration guides for agent frameworks/SDKs such as Vercel AI SDK, LangChain, CrewAI, or OpenAI/Anthropic SDKs. Missing for 10: any mention of LangChain, CrewAI, Vercel AI SDK, or OpenAI/Anthropic SDK integration guides or adapters.

   • [claimed-docs] “exposes the platform, organizations, servers, deployments, logs, and observability, as MCP tools, so you can manage everything from Cursor, …”
   • [claimed-docs] “You get one-click installs or copy-paste configuration for”

   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

   Manufact—none0/10

   Manufact's publish-checklist audits cover protocol compliance, platform readiness, and end-to-end functional tests (manufact-docs-7, manufact-docs-8), but there is no evidence these checks screen for malicious behavior or security vulnerabilities in listed servers before agent use. Missing for 10: any documented security/malware scanning step, vulnerability detection, or a curated registry vetting process distinct from functional/protocol compliance testing.

   • [claimed-docs] “runs an automated audit of your server for protocol compliance and platform readiness”
   • [claimed-docs] “end-to-end checks that exercise your server live in ChatGPT and Claude”
   • [claimed-docs] “copy a fix prompt into your own coding agent, or run the built-in autofix flow”
   • [claimed-docs] “you can start a checklist automatically after each successful deployment”

   proof ↗⚑ flag

Signals

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

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

   Manufact~partialclaimed3/10

   Manufact provides a 'publish checklist score' and automated audits for protocol compliance/readiness on servers you deploy (manufact-docs-6, manufact-docs-7), which is a quality signal, but this is scoped to your own deployed servers rather than a public catalog for comparing third-party MCP servers by usage counts, health/liveness, or verification badges. Missing for 10: cross-server marketplace/directory view, usage/popularity counts, verification badges, and independent evidence that these scores are used to compare multiple distinct servers rather than track one's own deployment quality.

   • [claimed-docs] “The history table shows every deployment with its MCP URL, source branch and commit, duration, creation time, and the latest completed publi…”
   • [claimed-docs] “runs an automated audit of your server for protocol compliance and platform readiness”
   • [claimed-docs] “you can start a checklist automatically after each successful deployment”

   proof ↗⚑ flag

Tool search

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

   weight 2 · round drawn
   Glama—none0/10

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

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

   proof ↗⚑ flag

   Manufact—none0/10

   Manufact is a platform for deploying, monitoring, and managing MCP servers (deployments, observability, publish checks), not a runtime tool-search/meta-tool mechanism for agents to dynamically discover and load tools instead of loading full definitions. No evidence describes dynamic tool search/loading or meta-tool patterns to reduce context bloat.

   ⚑ flag