Surely someone has thought of this… if so please let me know .. otherwise here goes:
Working names: /help, Clive (CLI Virtual Endpoints), Recline (Remote CLI)
Remote capabilities that feel like bash, use progressive disclosure like Skills, and work over HTTP. Any agent that can curl a URL can discover and use a /help endpoint.
Skills are folders with markdown files. An agent reads what it needs.
/help is the same thing, but remote. A URL with endpoints. An agent fetches what it needs.
/help is for both services: do things, and for knowledge: informs things. A /help endpoint can be:
My thought is having the simplest starting point: paste a URL into any agent or chatbot that can run an HTTP GET or curl command, which I think is the biggest simplification.. no connectors… let the agent web scrapers discover your information and services ahead of time or on the fly as the user pasted a simple url..
MCP launched as an open standard for connecting AI to tools. Problem: tool definitions consume excessive tokens when you connect many servers.
Anthropic introduced Skills as folders of markdown + scripts. Progressive disclosure: load metadata first, full instructions when triggered, supporting files when referenced.
OpenAI introduced AGENTS.md as “a README for agents.” Project-specific guidance in a predictable place.
Tools like Claude Code, OpenCode, and Vercel’s just-bash showed that bash is becoming the universal agent interface. Models understand --help. They navigate filesystems naturally.
All of these work locally. What about easy remote knowledge and capabilities without the need for MCP connector setup?
Every /help endpoint works like a CLI tool:
GET /help → what is this, what's available GET /topic/help → tell me more about this topic GET /topic/subtopic → go deeper
Responses are markdown. Human-readable. Agent-parseable.
A /help endpoint as a knowledge base:
GET /help
# Product Documentation Everything about our platform. ## Topics - `/api/help` - API reference - `/guides/help` - How-to guides - `/policies/help` - Terms, privacy, compliance - `/changelog/help` - What's new ## Search POST /search {"q": "authentication"}
An agent exploring this doesn’t need the full docs upfront. It fetches /help, sees the topics, fetches what’s relevant to the task.
A /help endpoint as a service:
GET /help
# PDF Tools Work with PDF documents. ## Available - `/extract/help` - Pull text from PDFs - `/fill/help` - Fill form fields - `/merge/help` - Combine documents ## Quick Example POST /extract {"url": "https://..."}
Same pattern. Discover first, use second.
For knowledge: Instead of dumping a whole knowledge base into context, agents can navigate it. Fetch the table of contents, drill into relevant sections, search when needed.
For capabilities: Instead of loading all tool schemas upfront, agents discover what’s available and how to use it on demand.
For both: Progressive disclosure. The agent only loads what it needs for the current task.
| Skills (Local) | /help (Remote) |
|---|---|
| A folder | A URL |
| [object Object] at root | [object Object] at root |
| Reference files | Sub-endpoints |
| Scripts that run | Endpoints that act |
| Agent reads files | Agent fetches endpoints |
Minimal:
from fastapi import FastAPI from fastapi.responses import PlainTextResponse app = FastAPI() @app.get("/help", response_class=PlainTextResponse) def help(): return """ # My Knowledge Base Information about X. ## Topics - `/overview/help` - What is X - `/setup/help` - Getting started - `/reference/help` - Full reference ## Search POST /search {"q": "your query"} """ @app.get("/{topic}/help", response_class=PlainTextResponse) def topic_help(topic: str): return load_markdown(f"{topic}.md") @app.post("/search") def search(body: dict): results = search_knowledge(body["q"]) return {"results": results}
That’s it. Serve markdown at /help. Add depth as needed.
On structure: There’s no required structure beyond /help at the root. Organize however makes sense for your knowledge or capabilities.
On search: Optional but useful for larger knowledge bases. A simple POST /search that returns relevant topic paths.
On versioning: Not really a thing. The /help describes what’s current. If it changes, the /help changes.
On registries: The /help endpoint is the registry. It lists what’s available.
On composition: One /help can link to others. It’s just URLs.
Documentation as /help: Your docs site, but agent-navigable. Agents fetch sections as needed instead of getting the whole thing.
Internal knowledge bases: Company policies, product specs, procedures. Agents can look things up.
API references: Instead of OpenAPI schemas, markdown descriptions agents can read and understand.
Service wrappers: Put /help in front of any capability. Describe it in markdown. Let agents discover how to use it.
Multi-agent retrieval: Complex RAG setups where agents navigate structured knowledge rather than vector-searching everything.
| Aspect | MCP | Skills | /help |
|---|---|---|---|
| Transport | JSON-RPC | Filesystem | HTTP |
| Discovery | Upfront schema | Metadata in prompt | [object Object] endpoint |
| Context cost | High | Low | Minimal |
| Knowledge or capabilities | Capabilities | Both | Both |
| Human readable | No | Yes | Yes |
-help patternsSkills showed that folders + markdown is enough for local agent capabilities.
/help shows that URLs + markdown is enough for remote knowledge and capabilities.
Any agent that can fetch a URL can use a /help endpoint. No SDKs. No schemas. No protocols. Just HTTP and markdown.
Draft v0.2 - January 2026