Composio vs Manufact

Agent access

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

   weight 2 · round drawn
   Composio✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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

2. ai-native userOperate the product with natural-language commands

   weight 2 · round to Manufact
   Composio~partialclaimed5/10

   Composio's CLI plugin integrates with Claude Code/Codex so a coding agent (or its user) can invoke Composio's tools via natural-language prompts inside those agents, and meta-tools let an agent discover/execute tools autonomously. However, Composio itself is an integration/tool-serving layer rather than a natural-language interface — there's no first-party chat/NL command surface of its own, only its embedding inside other agentic tools. Missing for 10: a dedicated natural-language command interface owned by Composio itself, and independent evidence of end-users issuing free-form NL commands successfully.

   • [claimed-docs] “The Composio CLI gives coding agents and terminals a local tool surface. Codex, Claude Code, or a person at the terminal can connect apps, e…”
   • [claimed-docs] “Install the native plugin for Codex or Claude Code: composio setup --target auto”
   • [claimed-docs] “Composio exposes **7 meta-tools** that let the agent discover what's available, authorize apps on demand, and execute tools across apps in p…”

   proof ↗⚑ flag

   Manufact✓fullprobed8/10

   Manufact exposes its own platform (orgs, servers, deployments, logs, observability) as MCP tools so users can manage everything via natural language from clients like Cursor or Claude, and also supports copying fix prompts into a coding agent or running built-in autofix. This is a first-party, well-documented agentic control surface over the whole product. Missing for 10: independent hands-on verification of the MCP server actually working end-to-end, and broader third-party confirmation beyond docs/community chatter.

   • [claimed-docs] “exposes the platform, organizations, servers, deployments, logs, and observability, as MCP tools, so you can manage everything from Cursor, …”
   • [probe] “official MCP server documented at https://docs.manufact.com/mcp”
   • [claimed-docs] “copy a fix prompt into your own coding agent, or run the built-in autofix flow”
   • [claimed-docs] “You get one-click installs or copy-paste configuration for”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Composio—none0/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

   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