# Workspace MCP tools Connect publishes no workspace MCP tools. The tool registry contains ten read-only documentation tools and nothing else, there is no authenticated tool, and no credential grants one. Nothing on this page describes something you can call today; it exists so that a client author stops looking, and so the boundary is written down rather than assumed. - **Status:** Not yet - **Audience:** developer - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/developers/mcp-workspace-tools/ ## What is actually there Call `tools/list` against `https://connectbyjbrh.com/mcp` and you get ten names, all of them documentation readers, each annotated `readOnlyHint: true`. Call `GET /.well-known/mcp.json` and the same ten names appear beside an `authentication` field whose value is the sentence *none for the public documentation tools*. There is no second endpoint, no scope parameter, no authorisation-server metadata document to discover, and no challenge to answer. So a tool that sends a message, books a follow-up, moves an opportunity or reads a mailbox does not exist over MCP. If a model offers you one, it invented the name. The honest test is cheap: list the tools and read the ten you get. > **Careful** Do not build a client that waits for a `401` and an OAuth challenge from this endpoint. It will not arrive. An unauthenticated request succeeds, and a request carrying a bearer token succeeds in exactly the same way, because the token is not consulted by anything. ## The gates a workspace tool would have to pass This is a design boundary recorded in the server module, not behaviour you can exercise. It is written down because the interesting part of exposing a business system to an agent is the list of things the tool must *not* be allowed to skip, and that list is easier to hold to before anything is built than after. - A tool would be reachable only with an integration key, and scoped to that key's single workspace — never to more than one. - It would call the existing domain service that owns the record, so that autonomy, approval, suppression, safe-sales limits, metering and audit all still apply. A tool that wrote directly to a table would bypass every one of them. - There would be no tool that runs SQL and no tool that proxies an arbitrary internal route: both are the same defect wearing different clothes, because either one makes the tool list a lie about what the tool can reach. - A held action would stay held. An agent's approval is not a person's approval, and an action that needs a human yes would still queue in Needs You rather than resolve itself because a machine asked. None of that is a promise about a future release, and none of it is running. Read it as the shape of the problem, not as a roadmap. ## What to do instead **You want to answer questions about Connect** — Use [the public tools](/developers/mcp-public-tools/). They answer from the same documentation the website serves, with a capability status attached to every page. **You want to act inside a workspace** — Use the product. Connect Assistant works inside a signed-in session with the full set of product tools, under the workspace's own autonomy rules — see [Connect Assistant](/docs/assistant/). **You want machine access to workspace data** — That is a session or an integration-key question, not an MCP question. Start at [Integration keys](/developers/integration-keys/) and [Account and access](/docs/account/). **You are writing an agent that must not overstate** — Call `get_product_status` first. It is the manifest the whole corpus is generated from, and it names every capability that exists only as groundwork. ## Why the absence is stated rather than left blank A missing page is read as an oversight; a page that says *this does not exist* is read as a decision. Publishing an authenticated tool surface is a real decision about exposing a business's mail, calls and relationships to software the business did not write, and it is not made by leaving a gap in the documentation for a model to fill in with something plausible. The same choice was made on the A2A side: the agent card declares `supportsAuthenticatedExtendedCard: false`, and asking for an extended card returns the A2A error code `-32004` with a sentence saying the public card is the whole advertised surface. Two protocols, one answer. ## Questions ### Is there a private or beta MCP endpoint? No. `https://connectbyjbrh.com/mcp` is the only MCP endpoint, and its discovery document lists its whole tool set. There is no second host, no hidden path and no allowlist of early clients. ### Can I get an integration key that unlocks MCP tools? No key changes what this server offers, because the server never looks at one. Integration keys are a separate mechanism inside Connect and grant nothing here. ### What should my client do if a user asks it to send an email through Connect? Say that the published interfaces are read-only and point at the product. An agent that reports it sent something it did not send is a worse failure than an agent that declines — see [Building an agent on Connect safely](/developers/agent-safety/). ## Related - [Public MCP tools](https://connectbyjbrh.com/developers/mcp-public-tools/) - [Authenticating to the MCP server](https://connectbyjbrh.com/developers/mcp-authentication/) - [Building an agent on Connect safely](https://connectbyjbrh.com/developers/agent-safety/) - [Integration keys](https://connectbyjbrh.com/developers/integration-keys/) - [Connect Assistant](https://connectbyjbrh.com/docs/assistant/) - [What Connect may do](https://connectbyjbrh.com/docs/autonomy/) - [A tenant facade that fails closed](https://connectbyjbrh.com/research/closed-by-default-facade/) ## What this page is based on - `backend/app/mcp_server.py` — PUBLIC_TOOLS and the module docstring - `backend/app/a2a_server.py` — the extended-card refusal - Connect capability registry (docs-source/facts.py)