# 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.

- **Status:** Available
- **Audience:** developer
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/mcp-public-search/

## 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

1. Trigger — somebody asks an AI client what Connect does, or whether it can do a particular thing.
2. External event — the client posts one JSON-RPC request. No credential is presented and none is asked for.
3. 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.
4. Request — the tool name and arguments are validated against the tool's input schema.
5. Canonical record — none is written. A public read leaves no row anywhere.
6. Reasoning — none on the server. Ranking is search over generated text, not a model deciding what the question meant.
7. Knowledge, memory and rules — the knowledge here is the published corpus and the capability registry, which is the only source of status words.
8. Autonomy and approval — not applicable: nothing can be sent, changed or spent by any public tool.
9. Action — the generated Markdown, manifest entry or status document is read from disk.
10. Result — page titles, URLs, summaries and capability status, or one full page as Markdown.
11. Relationship, timeline and memory — none. A public reader is not a contact and is not recorded as one.
12. 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

1. Search before answering, rather than from memory of the product.
   - Result: Statuses change between releases; the corpus carries the date each claim was verified.
2. 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.
3. Fetch the full page before quoting anything specific.
   - Result: A summary is a summary; limits and failure modes live in the body.
4. 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.

> **Careful** Nothing in the public corpus describes a particular business. If a client needs a workspace's own conversations, follow-ups or relationships, that is the authenticated path and needs a key.

## 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.

## Related

- [Public MCP tools](https://connectbyjbrh.com/developers/mcp-public-tools/)
- [The Connect MCP server](https://connectbyjbrh.com/developers/mcp-server/)
- [Searching the documentation programmatically](https://connectbyjbrh.com/developers/docs-search-api/)
- [The machine-readable documentation](https://connectbyjbrh.com/developers/machine-manifests/)
- [An AI client calling a Connect MCP tool](https://connectbyjbrh.com/docs/workflows/mcp-tool-call/)
- [Markdown alternates](https://connectbyjbrh.com/developers/markdown-mirrors/)

## What this page is based on

- `backend/app/mcp_server.py` — `PUBLIC_TOOLS`, the resources and the annotations
- `tools/docs_build.py` — one source, many generated outputs
- Connect capability registry (`docs-source/facts.py`) — `public_docs`, `mcp_server`, `docs_manifests`