> ## Documentation Index > Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt > Use this file to discover all available pages before exploring further. # What's coming > The MCP Manager Admin API capabilities that are planned but not yet in the beta: reporting and a richer whoami, gateway rules and custom rule engines, per-assignment feature provisioning, an admin audit log, entitlement queries, multi-workspace targeting, a downloadable CLI, and proxying the docs MCP server through the admin gateway. The beta covers configuration, identities, gateways, people, hosts, and log and alert queries. Several capabilities that round out full parity with the app are planned but **not in the beta yet**. This page describes what's on the way so you can plan for it. We don't commit to dates here; if one of these is important to you, tell your MCP Manager contact — real demand shapes what ships first. **Closed beta.** The MCP Manager Admin API and MCP server are available now to a limited set of workspaces through the **MCP Manager Admin API** entitlement (`ff-mcpm-admin`), ahead of general availability. If you don't see **Settings → MCP & API** in your workspace, it isn't enabled for you yet — ask your MCP Manager contact to join the beta. ## Reporting and a richer identity call **Available soon.** Read-only reporting tools and an enriched `whoami` are planned. Today `whoami` returns your user, organization, team, role, and capabilities. A richer version will add more context about your workspace in a single call. Alongside it, reporting operations will expose the same usage summaries you see in the app's reports — a read-only, low-risk addition on top of the [log queries](/admin-api/reference/logging) that already ship. ## Gateway rules and custom rule engines **Available soon.** Creating, editing, reordering, and configuring gateway rules — and registering custom rule engines — over the Admin API is planned. Gateway rules govern what traffic a gateway allows and how it's transformed. Managing them programmatically is security-sensitive, so it's being designed carefully before it opens up. One deliberate design point to plan around: **MCP Manager rules are allow-lists.** There is no "deny list" of blocked items — you express a restriction as "allow everything except X." When these tools arrive, a request to "block tool Y" will be shaped into an allow-rule that excludes Y, not a separate deny primitive. See [Gateway Rules](/features/gateway-rules/overview) for how rules work in the app today. ## Per-assignment feature provisioning **Available soon.** Configuring which features (tools, resources, prompts) a server assignment exposes on a gateway is planned. A server can be assigned to a gateway more than once, each assignment exposing a different subset of the server's features. Provisioning that subset — choosing exactly which tools an assignment offers, and previewing the result before it goes live — is planned for the Admin API. Like rules, exposure is **allow-list only**: you select what to expose. See [Feature Provisioning](/features/feature-provisioning) for the concept. ## Admin audit log **Available soon.** A dedicated log of administrative changes made through the Admin API and the app is planned. The Admin API's design is to **enable every action your role permits and make it accountable**, rather than to block sensitive writes. The accountability half of that is a dedicated **admin audit log** — a record of who changed what configuration, when — kept separate from the AI-usage call log. Two different logs, two different tools. The [`query_logs`](/admin-api/reference/logging) operation that ships today returns the **AI-usage call log** (the MCP tool calls flowing through your gateways). The forthcoming **admin audit log** records **configuration changes** made through the Admin API. When the audit tools arrive they will be named distinctly so an agent never confuses the two. ## Multi-workspace targeting **Available soon.** Targeting a specific workspace on each call — for partners and others who manage more than one — is planned. Every operation currently acts on the workspace your token belongs to. Planned multi-workspace support will let `whoami` report every workspace you belong to and let each operation take an optional workspace target, defaulting to your token's workspace when omitted. This is aimed at partners administering sub-workspaces on behalf of their customers. ## Entitlement queries **Available soon.** Reading your workspace's plan entitlements through the Admin API is planned. Tools to query which features and entitlements your workspace holds are planned, so an agent can check what's available before attempting to use it. ## A downloadable CLI **Available soon.** A standalone command-line client for the same operations is planned. Every operation is already defined with a command-line form. A downloadable CLI will let you script the same operations and wire them into pipelines and infrastructure-as-code workflows, without writing an MCP or HTTP client yourself. ## Docs lookups through the admin server **Available soon.** Reaching the documentation MCP server through your admin connection is planned. The admin server already points agents at the [docs MCP server and `llms.txt`](/get-started/use-docs-with-ai). A planned enhancement will let an agent look up documentation **through** the admin connection, so a single connected server covers both operating your workspace and answering questions about how it works. ## Further reading Everything that is in the beta today, grouped by domain. What the control-plane surface is and how it's built. How the Admin API relates to the agent connection that ships today. How allow-list rules work in the app while the rule tools are in development.