Discovering a service with Concourse
How a registry, an Agent Card, and a content hash fit into a service discovery loop.
Before an agent can use a service, it has to find an endpoint and understand what that endpoint claims to offer. A directory can make that convenient. It also introduces a question: how does the caller check that the description it retrieved matches the description registered by the service owner?
Concourse is a prototype for this discovery loop. It combines an on-chain registry with service descriptions called Agent Cards, and provides a CLI, an MCP server, and a merchant service template.
The discovery loop
The registry associates an owner address with an Agent Card URI and a content hash. A caller reads the registry, fetches the card over HTTP, and checks the fetched bytes against the registered SHA-256 hash.
The card describes the service and its endpoint. After discovery, the agent calls that service directly. The registry helps locate a description and check its integrity; it does not need to sit in the middle of every service request.
The distinction is practical. Registry data can change less often than the service’s operational responses, and a caller can inspect the card before deciding whether to use the endpoint.
What the hash establishes
A matching hash establishes that the fetched content matches the committed bytes, assuming the hash and registry read are trusted for that purpose. It does not establish that the service’s claims are true, that its operator is competent, or that a request will succeed.
Likewise, control of an address is useful evidence about who can update a record. It does not, on its own, identify a real person or prevent one operator from registering multiple identities.
These limits belong in the discovery model. Otherwise “verified” becomes an ambiguous label that hides the actual check being performed.
From a record to a usable service
The repository includes a Solidity registry, client tooling, and a merchant template with HTTP endpoints and session authentication. The prototype uses Base Sepolia, so the implementation should be read as testnet work.
For me, the interesting step is connecting the registry read to a usable request: retrieve a card, check it, interpret its interface, and reach the service. That is a smaller, testable claim than treating registration as proof of trustworthiness.
See the source repository and the related note on integrity and trust.