Capability Resolution 0.2: Ask Who Can Do the Job, Get a Signed Answer

An AI agent that needs a tool it does not have is on its own. It cannot ask anyone which servers can do the job, and it cannot tell before connecting whether a given server is answering today. So it guesses. Capability Resolution is an open specification for that missing question, and as of today it has a live resolver behind it: 7Maps by 7IT Solutions. An agent, a client or a gateway asks "which servers can send a transactional email?" and gets back up to ten candidates. Each one is signed, says when the server was last seen answering, and expires within 48 hours. The client checks every signature and keeps the final say on whether to connect to anything at all.

We wrote the specification, published it under CC BY 4.0 with MIT reference code, and built the first resolver for it. The specification is at 7it.co.il/standard/capability-resolution. The source, the reference client, the conformance checker, test vectors and timestamp proofs are at github.com/XLSV777/capability-resolution.

Try it in one minute

You do not need an account, a key or a package. Ask the live resolver a question:

curl "https://7it.co.il/7maps/resolve?need=send%20a%20transactional%20email"

Then check that resolver against the specification yourself, with the open checker from the repository:

git clone https://github.com/XLSV777/capability-resolution
cd capability-resolution
node packages/resolver-js/bin/capability-resolution-check.js https://7it.co.il

The checker sends only GET requests with a fixed sample job, tests every rule that can be checked over HTTP, and prints a pass or fail for each one with its section number. When we ran it, 7Maps reached the resolver-1 level with 38 checks passed and none failed. You do not have to take that from us. Run it and see what it says today.

The short version

• The gap. An agent that needs a tool usually does not know which server has one, and cannot tell before connecting whether that server works now. Directories say what publishers declared. Nobody says, in a form a machine can verify, what was observed.
• The protocol. A resolver answers "who can do this job" with at most ten candidates. Every candidate carries a token signed with Ed25519 that states the status the resolver observed and when.
• The client decides. A candidate is advice. The specification forbids connecting to a server only because a resolver named it, and requires clients to keep working when every resolver is down.
• Many resolvers. There is no default resolver and no central list. Anyone can run one, and a client can ask several.
• Server owners get a say. One text file at /.well-known/capabilities.txt declares what a site's servers do and which resolvers may list them, including a deny that resolvers must respect.
• It runs today. 7Maps answers over HTTP and as a resolve tool on its server for the Model Context Protocol, drawing on observations of more than 45,000 hosts.

The problem: the agent cannot tell who can do the job, or whether it works right now

Picture an agent halfway through a task for someone. It has to send a transactional email, or check a shipping status, or create an invoice, and none of the tools it already has can do that. What happens next is mostly improvised. It might search the web and land on a README from two years ago. It might pull the full tool list from three servers it was configured with, spend a slice of its context reading descriptions, and pick one. It might connect to a server that went quiet last week, wait, fail, and try the next.

Every one of those paths costs something the person running the agent cares about. Time, first: a failed connection in the middle of a task is a stall the user sits and watches. Money, second: tool lists read into context are tokens, and tokens are billed. And a quieter cost that adds up over months: each time an agent picks the wrong server, or one that does not answer, the person relying on it trusts it a little less with the next job. For a company putting agents in front of customers, that slow loss of confidence is the expensive part.

The people building these systems are not short on directories. Registries record what publishers say about their servers. Server description documents say what lives at a known address. Both are useful, and both answer a different question. A registry entry tells you that someone published a server. It does not tell you whether that server answered yesterday. A description document helps once you already know where to look. Nothing in common use answers the combined question an agent has at that moment: given this job, which servers fit, and which of them were working the last time anyone checked?

And nothing gives that answer in a form the agent can verify instead of simply believing. That was the part we kept coming back to. An unsigned list from an unknown service is just another web page. If an agent is going to act on a list of servers, it should be able to check who made the list, when, and whether the statement has gone stale.

What the specification defines

The core is deliberately small: a discovery document, two endpoints, a token format, and rules for clients and resolvers. A binding then applies the core to one tool protocol.

Discovery. A resolver publishes a JSON document at /.well-known/capability-resolver on its own origin. It lists the endpoints, the current public keys as JWKs, and a link to a policy page. The endpoints must live on the same origin as the resolver's issuer name, so a client can tie every answer back to one place.

Resolve. The client sends a need in plain words, three to two hundred characters. It can add constraints: only servers that answered without sign-in, only servers with a read-only tool for the job, only servers whose handshake was fast enough, or only servers that declare no payment. The resolver returns up to ten candidates in its own order of preference. Each carries a server URL, a status (ok, sign_in, down or unknown), the time that status was observed, an expiry, a pointer to evidence, and a signed token. An empty list is a valid answer. Unsigned candidates are never valid.

Record. A client that wants more about one server can ask for its signed record: the same claims plus a name, a first-seen date, and optionally a reference to the resolver's signed daily history.

Tokens. Every answer is a compact JWS signed with Ed25519, and no token may live longer than 48 hours. Clients must reject a token that claims a longer life, one that expired more than five minutes ago, or one issued more than five minutes in the future. Tokens never contain the need text, the constraints, or anything about the caller, so a token can be logged or passed along without revealing what someone was working on.

Client rules. The client holds an ordered list of resolvers, and the specification ships none: the list stays empty until the client's maker or its user adds one. The client verifies every token and uses only the signed claims. It fails open, which means a slow, broken or unreachable resolver is skipped and the client carries on exactly as it would without the protocol. And it never connects to a server only because a resolver named it. Connecting follows the client's own policy, whether that is a user approval, an allowlist or a company rule.

Resolver obligations. A conforming resolver may not accept payment for including or ordering a candidate, may not favor servers it runs or is paid by, and has to disclose any such relationship. It keeps a dated changelog of material changes to how it selects candidates, though it does not have to publish the method itself. It never hosts, proxies or impersonates the servers it lists. It does not store the need text together with anything that identifies the caller, and it does not sell or share query logs. It may not report a status it did not observe.

The binding. The core says "server" for any network service an AI client can call. Section 15 says what that means for one protocol: Capability Resolution, with a binding for the Model Context Protocol. There, a server is a remote endpoint that speaks the protocol over HTTP, ok means it completed initialization and listed its tools without authorization, and sign_in means it answered with an authorization challenge. Local servers that run over stdio are out of scope. The core leaves room for other bindings later.

7Maps: the first live resolver

A specification nobody runs is a document. We wanted the first version to arrive with something working behind it, so 7Maps answers Capability Resolution requests from today.

7Maps watches remote tool servers and records how they behave when called. As a resolver, it turns that record into the answer the specification describes. Its discovery document is at 7it.co.il/.well-known/capability-resolver. It names the resolver as "7Maps by 7IT Solutions", gives the issuer https://7it.co.il, and publishes one Ed25519 key. Every resolve answer carries the same name next to the candidates, so an agent reading it knows who made the statement before it checks the signature.

A trimmed answer looks like this (the live one has real servers in it, and the token is shortened here):

{
  "v": "0.2",
  "iss": "https://7it.co.il",
  "resolver": "7Maps by 7IT Solutions",
  "candidates": [
    {
      "url": "https://mail.example.com/mcp",
      "status": "ok",
      "checked_at": "2026-10-29T10:00:00Z",
      "expires": "2026-10-31T10:00:00Z",
      "evidence": { "record": "https://7it.co.il/7maps/record?id=..." },
      "jws": "eyJhbGciOiJFZERTQSIs..."
    }
  ]
}

The same question works from inside an agent. The 7Maps server for the Model Context Protocol has a resolve tool, so an agent that already uses 7Maps can ask for candidates mid-task and get the same signed answers it would get over HTTP.

Behind it sit observations of more than 45,000 hosts. How 7Maps chooses and orders candidates is ours, the same way any other resolver's method will be its own. What we owe the people who use it is spelled out in the resolver policy: no paid placement, no favoring our own servers, a dated changelog of material changes, no selling query logs, and no status we did not observe.

7Maps is one resolver. It has no special place in the specification, and the reference client does not ship with it preset. If you build a client, you choose which resolvers to ask, and in what order.

What it leaves out on purpose

It is not a registry. Registries record what publishers declare; a resolver adds what it observed, and it may use registries as a source.

It is not a server description format. Server Cards and agent cards already describe a server well. A resolver can point to them, and the declaration file links to them instead of repeating them.

And it is not a ranking method. How a resolver chooses and orders candidates is its own business, and the specification does not ask anyone to disclose it. That choice is what lets resolvers differ. One may weigh recent uptime heavily, another may focus on a narrow field, a company may run a private one over its own approved servers. The protocol fixes only what the answer looks like and what a client must check before trusting it. If the method were part of the specification, there would be room for exactly one resolver, and the design depends on there being many.

For server owners: one text file

The first thing a server owner asks is fair: how do I tell resolvers what my servers do, and how do I keep a resolver I do not want from listing them?

The answer borrows from robots.txt and security.txt. You write one plain text file by hand and serve it at https://<host>/.well-known/capabilities.txt. No account, no registration, no form:

Conformance: Capability Resolution 0.2
Contact: mailto:tools@example.com
Expires: 2027-04-30T00:00:00Z
Resolvers: *

Endpoint: https://mail.example.com/mcp
Protocol: mcp
Jobs: send a transactional email
Sign-in: none
Payment: none

The Resolvers line is where you keep control. * allows every resolver. A list of origins allows only those. A minus sign in front of an origin denies that resolver, and none denies all of them. A deny always wins, and resolvers must honor it within 24 hours, even when the rest of the file has expired or is invalid.

The file speaks only for endpoints on its own host or its subdomains, so nobody can deny or claim someone else's server. And it is treated as a claim, never as proof. A resolver still checks each declared server itself before listing it, and when its observation disagrees with the file, the observation wins. Claiming a job your server cannot do gains you nothing beyond asking a resolver to take a look.

The checker reads your file the way a resolver would and tells you what passes:

node packages/resolver-js/bin/capability-resolution-check.js --server https://<your host>

It does not connect to your servers. There is an example file to start from in examples/capabilities.txt.

For people building clients and resolvers

The reference client is plain JavaScript with no dependencies. It keeps an ordered list of resolvers, verifies every signature, caches answers until they expire, and fails open. packages/test-vectors holds valid and invalid signed tokens with the verdict a conforming client must reach, so you can test your own verification against them. There are two small adapters for existing agent code: resolveTool() for the Vercel AI SDK and a CapabilityResolverTool for LangChain JS. To run the whole suite from a clone, npm test in packages/resolver-js. Nothing leaves your machine.

The packages, starting with capability-resolver-client, will be on npm soon. Until then everything runs from the repository.

If you are building a resolver, point the checker at your origin. It reports resolver-1 or tells you exactly which rule failed and where it lives in the specification. A second resolver that passes it would tell everyone more about this protocol than anything we could write.

How to check what each version said

Each published version is fixed. Corrections go into the next version, never into an old one. To make that checkable, the exact bytes of each version are timestamped by two independent services, and the proofs sit in the proof/ folder of the repository. Only the hash was ever sent out.

For 0.2:

Check the hash. In proof/0.2/, run sha256sum on the file (on Windows, certutil -hashfile with SHA256). It should print:

2169d03f74709ccacc9e1d082f7312ab85b83eba6a8cdc641fe5d25c5f1f4c76

Verify the RFC 3161 timestamp. Download FreeTSA's cacert.pem and tsa.crt from freetsa.org, then run:

openssl ts -verify -data capability-resolution-0.2.md -in spec.tsr \
  -CAfile cacert.pem -untrusted tsa.crt

It should say Verification: OK, with a time of 07:21:55 UTC on October 29, 2026.

Verify the OpenTimestamps proof. Run ots verify on the .ots file with the OpenTimestamps client, or drop both files into the verifier at opentimestamps.org. Version 0.1 is already anchored in Bitcoin block 973549; the folder's README notes when 0.2 is confirmed.

A specification that anyone can fork should have a clear record of what each version said and when. If someone later asks which text a resolver claimed to follow, the answer is a hash anyone can recompute.

What we know is missing

Being plain about where this stands is part of asking for review.

There is one editor, 7IT Solutions, and we would rather have co-editors from other resolver, gateway and client projects. There is one resolver, ours. The evidence field is meant to line up with the evidenceRef shape being discussed in the protocol's trust annotations work (SEP-1913), which has not settled. The two well-known URIs are not registered with IANA yet; that waits until someone outside 7IT has reviewed the text. The status vocabulary may be too coarse or too fine. The constraint list is short on purpose and may be missing something obvious to people who run servers in production.

Capability Resolution is an independent specification. It is not part of the Model Context Protocol specification, and it is not endorsed by Anthropic, the MCP maintainers, the Linux Foundation or any vendor.

Tell us where it is wrong

The most useful feedback quotes a section number. Open an issue at github.com/XLSV777/capability-resolution/issues for questions, corrections or objections, or send a pull request against spec/ if you have wording in mind. If you run a resolver, a gateway or a client and would like to co-edit, say so in an issue. Security problems in the reference code go through the repository's private "Report a vulnerability" button, not a public issue.

If you build agents, point one at the live resolver this week and tell us what it got right and what it missed.

FAQ

What is Capability Resolution?

Capability Resolution 0.2 is an open specification for asking a resolver which servers can do a given job and whether they answered when last checked. The resolver returns up to ten candidates, each with a token it signed that expires within 48 hours. The client verifies every token and keeps the final decision about connecting.

Is there a resolver I can use today?

Yes. 7Maps by 7IT Solutions runs a live resolver at https://7it.co.il. Its discovery document is at /.well-known/capability-resolver, it answers at /7maps/resolve, and the same answers are available through the resolve tool on the 7Maps server for the Model Context Protocol. The open checker in the repository rates it resolver-1, and anyone can rerun that check.

Is Capability Resolution part of the Model Context Protocol?

No. It is an independent specification with a binding for the Model Context Protocol, and its core is written so other tool protocols can get bindings later. It is not part of the Model Context Protocol specification and is not endorsed by Anthropic, the MCP maintainers, the Linux Foundation or any vendor.

Does a resolver decide which server my agent uses?

No. A candidate is advice. A client must not connect to, authorize or call a server only because a resolver named it. Connecting follows the client's own policy, such as user approval or an allowlist, and if every resolver is unreachable the client works exactly as it did without the protocol.

How do I stop a resolver from listing my servers?

Publish a plain text file at /.well-known/capabilities.txt on your host with a Resolvers line. Put a minus sign before a resolver's origin to deny it, or write none to deny every resolver. A conforming resolver must stop listing your servers within 24 hours of reading the deny, even if the rest of the file is expired or invalid.

Can anyone run a resolver?

Yes. The design assumes many resolvers. The specification fixes the answer format, the signatures and the obligations, and leaves each resolver's selection method to the resolver. The open checker tests a resolver against every rule that can be checked over HTTP.

Model Context Protocol and MCP are trademarks of their respective owners. The specification text is licensed CC BY 4.0; the reference code is MIT.