> For the complete documentation index, see [llms.txt](https://docs.allmcp.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.allmcp.co/documentation/why-allmcp.md). # Why AllMCP AllMCP gives AI agents one endpoint to every SaaS integration — and lets your end users connect their own accounts in plain conversation. Here's why we built it instead of reaching for an existing tool-hub. *** ## Three ways to connect an agent to real apps **1. Build each integration yourself.** OAuth flows, token refresh, error handling, pagination, per-user credential storage — three to four weeks per provider, repeated for every team, forever. **2. Use a general-purpose hub** (like Composio). Much faster than building from scratch. But you integrate an SDK or configure each provider's auth, and the model is built around individual users — not a platform serving many organizations, each with its own branding and policies. **3. Use AllMCP.** Point your MCP client at one URL with one API key. Your end users connect their own accounts in-conversation — the agent runs the flow. Multi-org tenancy, OAuth, and token refresh are handled for you, and the connector library keeps growing. *** ## How AllMCP compares Composio is a solid, broad toolkit. Here's where AllMCP is built differently: | | A general-purpose hub (e.g. Composio) | AllMCP | | ----------------------- | ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Setup** | Integrate an SDK or configure each provider in a dashboard | One API key — point your MCP client at one URL | | **Connecting accounts** | Wired up by the developer | Your end user connects in the chat — agent-driven, one click | | **Multi-tenancy** | Per-user credentials | Native **Client → Organization → User**, with per-org OAuth-app branding | | **Provider coverage** | Broad Western SaaS | Western SaaS **plus first-class CIS / Eastern Europe** — Bitrix24, amoCRM, Kommo, Binotel, YouGile, SalesDrive, Altegio | | **Agent context** | Tools loaded up front | **Progressive disclosure** — only the tools and skill the task needs | | **Your data** | Tokens held in their cloud | You never handle a token; we never see the conversation | *** ## Built for platforms, not just scripts AllMCP's tenancy is a real hierarchy — **Client → Organization → User** — that maps to how software is actually sold and used: * **You** connect once with a single API key. * **Your customer organizations** can bring their own OAuth app, so the consent screen carries *their* brand and their security policies. * **Each end user** connects their own accounts and only ever touches their own data. Identity travels on the connection (the URL and header), so every MCP client works with zero code changes — and you never see your users' tokens. *** ## First-class for CIS & Eastern Europe Most hubs are built for the Western SaaS stack. AllMCP covers that **and** the tools that run real businesses across Russia, Ukraine, and the CIS — **Bitrix24, amoCRM, Kommo, Binotel, YouGile, SalesDrive, Altegio** — as first-class connectors, not afterthoughts. *** ## Built to keep your agent's context lean Most hubs hand your agent the entire tool catalog up front — hundreds or thousands of tool definitions that fill the context window before the agent has done anything. AllMCP works the other way around, with **progressive disclosure**: * Your agent starts with a handful of always-available system tools — browse providers, connect one, inspect a category. That's the whole starting surface. * A provider's tools appear **only after you connect it**. You never spend context on integrations you aren't using. * Within a provider, tools are grouped into **categories**, and the agent pulls a category's tools in **on demand** — when the task actually calls for them. * Each category ships a short **skill**: a focused, plain-language guide to using those tools well. The agent loads it only when it works in that category — never usage docs for everything at once. So at any moment the model holds just the small set of tools and the one skill the current task needs — not the whole library. Less context spent describing tools means more room for the actual work, faster responses, and lower token cost — and the agent picks the right tool because it isn't sifting through hundreds of irrelevant ones. {% hint style="success" icon="bolt" %} **Net effect:** a lean, relevant tool surface that scales to a huge connector library without bloating the model's context. And you only pay for real work — see [Pricing](/documentation/pricing.md) for how only actual provider tool calls are metered. {% endhint %} *** ## Keep going

:rocket-launch:

QuickstartConnect AllMCP to your agent in under 2 minutes./pages/416edc1381c20849bc41111b02e482a722a49b94

:table-cells:

ProvidersBrowse every connected app and its tools./pages/QJVxDLqxIz5KMCH5afbE

:tag:

Pricing20,000 free provider tool calls every month./pages/aWxfjtWaeiHHZZQySTpC
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.allmcp.co/documentation/why-allmcp.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.