An AI client searching the public documentation
Ten documentation tools are open to any MCP client with no credential at all. They search and fetch the published corpus — pages, capabilities, workflows, glossary, protocols, product status and the changelog — and they touch no workspace, so there is nothing to scope and nothing to meter. What a client gets back is the same text a reader sees.
What is open, and why that is safe#
The public tools read generated files. They are the same artefacts the website serves, produced by one build from one source, which is why the Markdown a machine fetches cannot disagree with the HTML a person reads. No workspace data is reachable from any of them.
| Tool | What it answers |
|---|---|
search_public_docs | Free-text search, filterable by page kind, capability status and channel |
fetch_public_doc | One page in full as Markdown, by URL or page id |
list_capabilities | Documented capabilities, filterable by status, channel or audience |
get_capability | One capability page |
get_workflow | One end-to-end flow, or the list of them |
search_glossary | The canonical definition of a term, or every defined term |
get_technology | A technology page, each stating whether Connect uses the technology |
get_protocol | A protocol page with the version Connect implements |
get_product_status | The machine-readable status of every capability |
get_changelog | The published changelog of user-visible changes |
Every one is annotated to its client as read-only, non-destructive, idempotent and closed-world. A client is right to treat annotations from any server as untrusted hints; these happen to be accurate, because the handlers genuinely only read files.
The path a public search takes#
- Trigger — somebody asks an AI client what Connect does, or whether it can do a particular thing.
- External event — the client posts one JSON-RPC request. No credential is presented and none is asked for.
- Authentication and workspace resolution — nothing to resolve. This is the one flow in this manual with a genuinely empty workspace stage, because no workspace is involved.
- Request — the tool name and arguments are validated against the tool's input schema.
- Canonical record — none is written. A public read leaves no row anywhere.
- Reasoning — none on the server. Ranking is search over generated text, not a model deciding what the question meant.
- Knowledge, memory and rules — the knowledge here is the published corpus and the capability registry, which is the only source of status words.
- Autonomy and approval — not applicable: nothing can be sent, changed or spent by any public tool.
- Action — the generated Markdown, manifest entry or status document is read from disk.
- Result — page titles, URLs, summaries and capability status, or one full page as Markdown.
- Relationship, timeline and memory — none. A public reader is not a contact and is not recorded as one.
- Audit, usage and Needs You — operational logging only. No workspace ledger is touched and no person is queued.
What a client should do with the answers#
Search before answering, rather than from memory of the product.
Result Statuses change between releases; the corpus carries the date each claim was verified.
Read the capability status word, not just the prose.
Result Available, foundation and not-yet are different claims, and telling a user that a foundation capability is usable is the failure this vocabulary exists to prevent.
Fetch the full page before quoting anything specific.
Result A summary is a summary; limits and failure modes live in the body.
Cite the page URL you used.
Result The reader can check it, and a wrong answer becomes traceable to a page rather than to a guess.
The limits worth stating plainly#
- There is no write of any kind on this path, and no tool that takes free-form code or a query language.
- There is no personalisation: two clients asking the same question get the same corpus, because there is no identity to vary it by.
- Results are only as current as the last publication. The date each page was verified is on the page.
- A term the corpus does not define comes back as undefined rather than as an inferred answer — silence is a truthful result here.
- The same content is reachable without MCP at all, through the published documentation, the manifests and the Markdown alternates, for clients that do not speak the protocol.
Questions#
Why publish documentation tools rather than let clients crawl the site?
Both work, and both are supported. A tool call returns structured fields — status, kind, channel, canonical URL — that a client would otherwise have to infer from prose, and it removes the guesswork about which page answers a question. Crawling remains open for clients that prefer it.
Does calling a public tool tell Connect anything about my users?
No workspace record is created and no contact is resolved. Requests are logged operationally, as any HTTP service logs requests; they do not become customer data, because there is no customer involved in the call.
Can a public tool tell me whether Connect supports something?
Yes — that is what the capability status tools are for. Ask for the status rather than reading a marketing sentence: the registry distinguishes a running capability from one whose model and tests exist but whose usable surface is deliberately narrower.