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.
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.
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. 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.
- You want machine access to workspace data
- That is a session or an integration-key question, not an MCP question. Start at Integration keys and Account and access.
- You are writing an agent that must not overstate
- Call
get_product_statusfirst. 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.