Use Everything with your AI agent
A visitor's guide to connecting an AI assistant for reading and exploring Everything.
Everything is a public collection of articles and connected ideas. You can browse it on the website or give your AI assistant a direct way to read, search, and follow links in it.
No Everything account is needed to read published pages. The visitor connection is read-only. Everything does not charge for public reading, though your AI client may have its own subscription or usage restrictions.
Why connect an agent?
You can ask your assistant to:
- Explore: "What topics are in Everything? Find somewhere interesting to start."
- Explain: "Read Beyond the Application and explain the argument about software disaggregation."
- Compare: "Read Hybrid Human–Agent Software and From Static to Generated Interfaces. Where do they overlap?"
- Follow references: "Find related articles and explain how they support or challenge the original claim."
- Use it in other work: Ask a coding or research agent to use public Everything articles as context for its work.
Choose your AI client
| Client | Guide |
|---|---|
| ChatGPT | ChatGPT |
| Claude | Claude |
| Cursor | Cursor |
| Claude Code | Claude Code |
| Codex | Codex |
| VS Code / Copilot | VS Code |
Not every AI client or subscription supports adding custom MCP servers. Each guide explains the requirements and gives copyable instructions.
The connection address
https://everything.emlynoregan.com/mcp/
This is a remote MCP (Model Context Protocol) endpoint. You connect to it from your AI client; you don't install an Everything server or generate a key.
Try your first question
After connecting, ask:
Use the Everything MCP tool
get_pageto read/topics/software-and-agents. Tell me the title and link to one collection on the page.
You should get Software & Agents, which links to Beyond the Application. Ask your agent to show the source URL and make an actual tool call, rather than guessing.
See Check your connection for a short walkthrough and more example questions.
More capable reading and search
The familiar search_pages, list_pages, and get_page tools still work. Agents can also call retrieval_capabilities to discover five-mode passage search, Boolean tag filters, metadata selection, and bounded context reads. search_chunks preserves multiple useful passages per article; select_pages explores metadata without a text query; get_page_chunks inspects a selected public passage.
See Search and browse for examples, cursor rules, incomplete-result handling, and the current limit on paging filtered Exact searches. These remain public read operations. Your client may need to refresh its tool catalogue or reconnect to discover newly added tools.
What the connection does—and doesn't—do
Your agent can read and search publicly published pages. It cannot edit the wiki or access private drafts. Connecting Everything does not give the site access to your files or other services. Your AI client will send page paths or search text to Everything when invoking the tools; avoid putting private information in those requests.
Read Access and privacy for details. For missing tools, unavailable features or unexpected results, see Troubleshooting.
You can always browse Everything directly, without connecting an AI assistant.
Lexical matching and search coverage
Explicit Lexical passage search requires all distinct normalized query terms in the same chunk, with BM25 ranking. Common terms are not silently discarded. Use concise terms that should appear together; use Semantic when you deliberately want paraphrases instead.
Check families.lexical.traversal.complete separately from index lag. If traversal is incomplete, useful matches may be omitted and zero hits do not prove absence. A supplied cursor pages the same fixed searched subset; it does not broaden the search. Narrow with more specific terms for better coverage. Other service or semantic-tail degradations may still prevent continuation. See Search and browse for the full guidance.
Upload and place images
Owner-connected agents can use owner_upload_media with content_type, strict data_base64, optional descriptive filename, and a stable request_id. PNG and JPEG inputs must be single-frame, at most 1 MiB and four million pixels. Everything strips metadata and stores a new immutable PNG, also at most 1 MiB. The response reports its actual asset ID, PNG content type and stored byte count; a small JPEG can exceed the output limit after conversion. Base64 must have no data-URL prefix or line breaks. The bounded MCP request envelope accommodates it.
Put the returned canonical UUID in the page content's media list, for example "media": [{"asset_id": "<asset-id>", "alt": "Diagram description"}]. New page writes accept up to eight unique references, with text alt values of at most 256 characters. In a template-rendered Markdown body, write  to place that listed image within the prose. Replace <asset-id> with the returned UUID. Inline images are not appended a second time; listed images without an inline placement still appear after the article. Markdown alt text takes precedence over the list alt.
Revise and publish through the existing owner page tools. Uploading alone does not expose a raw public asset URL: image serving requires an eligible published page that references the asset and the appropriate media tags. Unlisted and remote images do not load. Replacing an image means uploading a new asset and revising the page, preserving history.
Keep the request ID and any partial asset ID after an uncertain write. Inspect tags/progress and repair through ordinary tools instead of blindly uploading again or deleting partial work. A repeated committed request is not permission to overwrite its bytes. No OCR or image generation is required. If your client still shows the old tool list, refresh its MCP tool catalogue or reconnect to discover owner_upload_media.