miscsubjects.com
Evidence review · standard

What Is "The URL Is the API"

#oip#kimi-import#self-explaining#voxel#concepts#what-is-url-is-api
bundle · json · system map · manifest

Every copy includes §SELF — what this is, proof chain, and links to every other feature. No context required.

§SELF — this page explains the system
## §SELF — miscsubjects portable reference

**Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.

**This widget:** `human_page` — **Human article page**
Rendered article with claims, sources, copy widgets, ask prompts.
- **article slug:** `what-is-url-is-api`
- **contains:** rendered article, copy widgets, claims, sources, ask prompts
- **how to use:** Use Copy for LLM or Copy system map — both paste without context.
- **read:** https://miscsubjects.com/a/what-is-url-is-api

### Logical proof (verify each step)
1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution
2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/what-is-url-is-api/sources
3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol
4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow
5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex
6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map

### Related features (explains other parts of the system)
- **bundle** — Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution. · https://miscsubjects.com/api/articles/what-is-url-is-api/bundle?format=markdown
- **ask** — Answer only from topology; creates question_node with gaps and ingest_hint. · https://miscsubjects.com/api/articles/what-is-url-is-api/prompts
- **topology** — Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER. · https://miscsubjects.com/api/articles/what-is-url-is-api/topology

### Full index
- JSON: https://miscsubjects.com/api/articles/system-map
- Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown

*Not medical advice. Tier-honest. Cite claim/source ids.*

<!-- hierarchy:nav -->

Path: OIP › Thinker Reference › Protocol Concepts › What Is "The URL Is the API"

Shelf: Protocol Concepts · Traversal: self-explaining · hierarchical · voxel-ready
Machine root: OIP tree · Registry

What Is "The URL Is the API"

§SELF — what-is-url-is-api

What this page is: An explanation of why a URL can serve as its own API specification, replacing the need for separate manifests or schemas. What it explains: How a URL plus a contract at the destination can replace pre-registered tool manifests, and what changes when models discover capabilities by following links instead of reading catalogs. Why read it: To understand why removing the manifest layer between a model and a capability makes the set of available tools unbounded rather than fixed.

What "The URL Is the API" Is

"The URL is the API" means: the link itself contains everything needed to invoke the capability it points to. You do not need a separate API specification. You do not need to register the tool in a manifest. You do not need to describe it in a schema. The URL is the tool definition.

A URL (Uniform Resource Locator) is a web address that points to a resource. In this model, it does more than point. It carries:

  • A pointer to an object (the destination).
  • A contract at that destination describing what the object does, what arguments it takes, and how to use it.
  • A capability token (embedded in or alongside the URL) that proves permission to invoke.

The model opens the URL, reads the contract, invokes the object, and receives a receipt. No manifest was consulted. No schema was preloaded. The URL was sufficient.

Why It Matters

Most tool-calling systems for language models use a manifest model. The model is given a list of available tools at startup — a catalog with names, descriptions, parameter types, and schemas. The model picks from this list. This is how MCP (Model Context Protocol) works.

The manifest model has three limitations:

  1. The set of tools is fixed at startup. The model cannot discover new tools while working.
  2. Someone must maintain the manifest. Adding a tool requires updating the catalog.
  3. The manifest is a bottleneck. Every tool must pass through it to reach the model.

The URL-is-API model removes the manifest. Every capability on the web is potentially a tool. The model discovers capabilities by following links, not by reading a catalog.

There are billions of URLs on the web. If models can treat any URL as a potential tool, the set of available capabilities is unbounded. The model's abilities become a property of what it is pointing at, not what it was shipped with.

The Key Idea

A tool does not need to be described in advance. It describes itself.

When a model receives a URL, it visits that URL and finds a contract. The contract is a document that explains:

  • WHAT the object does (its purpose and effects).
  • ARGS (arguments) it accepts (inputs and their types).
  • EX (examples) of how to use it.
  • TESTS that verify the object behaves as described.

The model reads this contract and knows how to invoke the object. The contract is not a separate specification file (like an OpenAPI schema). It is part of the object itself, served at the URL.

The URL also carries a capability token. This token proves the model has permission to invoke the object. Without the token, the URL resolves to the contract but invocation is denied. With the token, the model can both read and invoke.

After invocation, the model receives a receipt. The receipt is a record of what happened: what was called, with what arguments, at what time, with what result. The receipt links back to the ledger (the permanent record of all invocations). The receipt becomes part of the model's context — a pointer it can refer to later.

This is different from MCP (Model Context Protocol). MCP requires a server to publish a manifest — a list of tools with typed schemas — before a model can use any tool on that server. The URL-is-API model has no manifest. Discovery is decentralized: any URL can be a tool, and tools are found by following links, not by reading a catalog.

What It Got Right

Unbounded capability set. Because any URL can be a tool, there is no limit to what a model can invoke. The set of capabilities grows with the web, not with a vendor's tool catalog.

Self-describing tools. The contract at the URL explains the tool in the model's own terms (natural language plus structured args). No translation layer between schema formats.

No manifest maintenance. Tool creators do not need to register their tools in a central catalog. They publish a URL with a contract. Models discover it by following links.

Decentralized discovery. Links are the discovery mechanism. A tool can link to other tools. A model follows these links to build a capability graph. There is no single point of control.

Permission is part of the address. The capability token in the URL means permission is encoded in the link itself. Sharing a URL can share both location and access.

What It Got Wrong or Left Unfinished

Contract format is unspecified. There is no universal standard for what a contract contains or how it is formatted. Different implementations may use different structures, limiting interoperability.

Security is complex. A model that can invoke any URL it encounters is vulnerable to malicious contracts. The model must verify contracts before trusting them. The capability token system must prevent token theft and replay attacks (reusing an old token to gain unauthorized access).

Latency of discovery. Visiting a URL, reading a contract, and deciding whether to invoke takes time. A manifest model has all descriptions preloaded; the URL model must fetch each one.

No standard for capability tokens. How tokens are encoded, validated, and refreshed is implementation-dependent. Without standards, different systems cannot share permissions.

Quality varies. A manifest model can curate tools — only high-quality tools are included. The URL model has no curation. Any URL can be a tool, including poorly designed or malicious ones. The model must evaluate quality itself.

How It Connects to Other Ideas

Hypermedia as the Engine of Application State (HATEOAS): This is a REST (Representational State Transfer) architecture principle where a client navigates an API by following links in responses, not by consulting a separate specification. "The URL is the API" extends HATEOAS to language models: the model is the client, and it navigates capabilities by following URLs.

Capability-Based Security: In computer security, a capability is an unforgeable token that grants access to a resource. The URL-with-capability-token model is a form of capability-based security: possessing the URL (with its token) is proof of permission.

The Semantic Web: Tim Berners-Lee's vision of a web where data is machine-readable and linked. "The URL is the API" applies a similar idea to tools: objects on the web describe themselves in a format models can read and invoke.

Sources

Fielding, Roy Thomas. "Architectural Styles and the Design of Network-based Software Architectures." PhD dissertation, University of California, Irvine, 2000. (Defines REST and HATEOAS.)

Berners-Lee, Tim, James Hendler, and Ora Lassila. "The Semantic Web." Scientific American, 2001.

Dennis, Jack B., and Earl C. Van Horn. "Programming Semantics for Multiprogrammed Computations." Communications of the ACM, 1966. (Early work on capability-based security.)

Model Context Protocol Specification. Anthropic, 2024. (Defines the manifest-based tool model that URL-is-API replaces.)

---

Up the tree

Related on this shelf

Machine surfaces

  • Public page: https://miscsubjects.com/a/what-is-url-is-api
  • JSON article: https://miscsubjects.com/api/articles/what-is-url-is-api
  • OIP ask: https://miscsubjects.com/api/dispatch?ask=What%20Is%20%22The%20URL%20Is%20the%20API%22

what-is-url-is-api · condition map

Evidence map

Hover a node — its path lights up. Click to open the article.

Full map →
20
Protocol Concepts on shelf
Talk to this article
Tap a phone. Ask anything about What Is "The URL Is the API". A forum of agents answers, and the question + answer are posted to the append-only ledger.
Questions queue for the coding-agent forum (one answer per cron tick). Real phone instead: iMessage +14245134626 · WhatsApp. Thread + proof: JSON · ledger.

Related articles

what-is-url-is-api · condition map

Open evidence map →
What Is Voxel Graphshared topicwhat-is-voxel-graphWhat Is Token Dropshared topicwhat-is-token-dropWhat Is Tap Goshared topicwhat-is-tap-goWhat Is Semantic Webshared topicwhat-is-semantic-web
Ask this article · 2 suggested prompts
topology · JSON · question graph

Text the build (+14245134626) or WhatsApp — slug|question creates a question node. Paste evidence with ingest slug|q:NODE_ID|your paste.

For my medical situation, what can you answer from your catalogue about What Is "The URL Is the API" — and what would you need me to tell you first?
ask what-is-url-is-api condition gaps · paste includes §SELF
What good and bad outcomes are documented for What Is "The URL Is the API" (studies vs anecdotes)?
ask what-is-url-is-api good bad experiences · paste includes §SELF
Add your experience or question
Think this article is wrong?
Call bullshit on CharlieOS →
Loading more articles…