Capabilities are what an agent identity can do. Leash keeps the identity stable and lets capabilities change around it: an agent can buy tools, sell an API, read connected data sources, receive reports through Telegram, run scheduled automations, or expose MCP endpoints without minting a new identity for each mode. In product surfaces, capability is the umbrella term for MCP tools, paid API endpoints, and agent services. Native Leash marketplace listings expose callable tools or a service endpoint. pay.sh/pay-skills providers expose payable endpoints. Both are shown in one directory because both are things an agent identity can pin, call, pay for, and build receipts around.

​
Capability types

CapabilityWhere it is declaredWhat it means
Buyerleash block + policy + spend delegationThe agent can pay for external tools or APIs under owner-defined caps.
Sellerservices[], marketplace listing, payment linksThe agent or service can be called and paid by others.
Tool providerMCP / HTTP service descriptorsOther agents can discover callable operations.
Data sourceConnected OAuth toolkits and automation source configThe agent is allowed to read or act on a connected account.
Control channelExternal chat connections such as Telegram or WhatsAppA user can command and monitor the same identity outside the web app.
AutomationTrigger + source + policy + delivery configThe identity can run background work on a schedule, webhook, or event.
Marketplace cardLeash listing or pay.sh provider metadataThe identity can save and reuse a public capability from the directory.

​
Counting capabilities

The marketplace uses one count label across the mixed directory:
  • Leash listings count callable tools; if a listing is a single service with no extra tool manifest, the service itself counts as one capability.
  • pay.sh providers count payable endpoints. A provider with one endpoint is shown as one capability and one payable endpoint.
  • Agent identity profiles store saved items as capability cards, with visibility: public or private.

​
Split versus merged agents

Buyer and seller are capabilities, not separate object types. You can keep them on separate identities for teaching and accounting, or merge them into one production identity.
ModeAssetsTreasuriesReceipts feedUse case
Split222 (one per asset)Teaching, isolated accounting, separate trust surfaces.
Merged111 (mixed kind)Production agents that consume APIs to produce paid services.
Both ship in v0.1: docker compose up (split, default) vs docker compose --profile merged up (merged).

​
Why capabilities belong to identity

Capabilities are discoverable claims about what an agent can do. Receipts then prove whether those claims are used successfully. This is why Leash treats marketplace listings, x402 payment links, MCP tools, connections, and automations as layers attached to the agent identity instead of unrelated app features.