ERC-8257: Agent Tool Registry

ERCs
13

Hello @ryanio and @cody!

Thanks for writing this up! A few questions regarding this ERC:

  • What exactly is the definition of an Agent Tool? In the manifest schema I see fields for endpoint, inputs, outputs so is it intended to be an https-only callable endpoint with query/body params? A canonical definition would help here I think (or a link to an established definition if one exists).

  • On manifest trust anchor: origin binding + self-attestation is probably sufficient here. Though, leaving the door open for signed manifests and ENS resolution would be great.

  • On pricing hints: an opaque string works fine here, however perhaps there should be a list of canonical strings to avoid variations of the same protocol (e.g. “native-transfer“ vs. “native_transfer“)

  • On payment settlement: this protocol should remain payment-free IMO. Unless I’m misunderstanding, adding a settlement primitive would involve routing payments through this contract which may interrupt certain payment flows. For example an x402 payment would have to route through this contract instead of being a direct payment to an x402 resource address. Also, the core USDC contract doesn’t have hook functions so composability is limited there unless you use a wrapper contract (like CCTP from Circle).

  • Last month I authored ERC-8239: Agent Skill Registry which is remarkably similar to what is proposed here. The contract reference implementations are nearly identical in logic (register skill/tool identity, set manifest and hash, define attestations, interact via CLI tool, etc) so trying to map out the scope of overlap between our proposals. A few differences I noted:

    • ASR follows the ERC-8004 template by minting ERC-721 tokens for each skill registration so skillId == tokenId. ATR stores a ToolConfig object in a mapping keyed by toolId.
    • ASR manifest schema acts like an onchain package manager with an array of registered targets that can be resolved to access agent skill files. ATR seems to define an HTTPS API endpoint and its call structure.
    • ATR explicitly defines onchain access/policy control as a predicate contract. ASR supports this but doesn’t prescribe a pattern in the spec.

Great work on drafting this btw! Would love to collaborate since it seems we’re both aiming for nearly the same idea :slight_smile:

1 Like