---
slug: what-is-url-is-api
title: What Is "The URL Is the API"
canonical: https://miscsubjects.com/a/what-is-url-is-api
---

<!-- hierarchy:nav -->
> **Path:** [OIP](https://miscsubjects.com/a/oip) › [Thinker Reference](https://miscsubjects.com/a/oip-thinker-reference) › [Protocol Concepts](https://miscsubjects.com/a/oip-protocol-concepts) › **What Is "The URL Is the API"**
>
> **Shelf:** Protocol Concepts · **Traversal:** self-explaining · hierarchical · voxel-ready
> **Machine root:** [OIP tree](https://miscsubjects.com/api/dispatch?map=1&format=markdown) · [Registry](https://miscsubjects.com/api/dispatch?registry=1)

# 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

- [OIP root](https://miscsubjects.com/a/oip) — protocol root, zero-context entry
- [Thinker Reference hub](https://miscsubjects.com/a/oip-thinker-reference) — full hierarchy map
- [Protocol Concepts shelf](https://miscsubjects.com/a/oip-protocol-concepts) — siblings on this shelf
- [Voxel graph article](https://miscsubjects.com/a/what-is-voxel-graph) — how pages link as voxels
- [Self-describing protocol](https://miscsubjects.com/a/what-is-self-describing-protocol)

## Related on this shelf

- [What Is Autopoiesis](https://miscsubjects.com/a/what-is-autopoiesis)
- [What Is Capability-Based Security](https://miscsubjects.com/a/what-is-capability-security)
- [What Is a Capability Token](https://miscsubjects.com/a/what-is-capability-token)
- [What Is a Confused Deputy](https://miscsubjects.com/a/what-is-confused-deputy)
- [What Is Context as Cursor](https://miscsubjects.com/a/what-is-context-as-cursor)
- [What Is a Convergence Catalogue](https://miscsubjects.com/a/what-is-convergence-catalogue)
- [What Is a Falsification Surface](https://miscsubjects.com/a/what-is-falsification-surface)
- [What Is HATEOAS](https://miscsubjects.com/a/what-is-hateoas)

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


---

## Where OIP does this differently (required edge)

OIP difference: GET invoke with share token is first-class; safety is scope+ledger+dedup, not verb purity.

