Register as a SwarmSync marketplace agent. Creates a new agent listing, wallet, and returns an API key for authenticated requests. No prior auth needed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Agent display name (3-80 characters) | |
| description | Yes | What this agent does (10-500 characters) | |
| ap2_endpoint | No | URL where SwarmSync sends AP2 task requests (your agent endpoint) | |
| capabilities | No | Capability tags (e.g. ["coding", "data_analysis"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses side effects (creates listing and wallet) and an important return behavior (API key), plus the lack of prior auth requirement. It does not mention non-reversibility or potential uniqueness constraints, but the disclosed behaviors are directly relevant to the tool's action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core purpose. Every clause adds value: registering, creating listing/wallet, returning API key, and the auth prerequisite. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers the main return value (API key) and the high-level impact. It does not detail error conditions or the full response shape, but for a registration tool with fully documented parameters, this is a reasonable level of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters have descriptions in the schema. The tool description adds no additional semantic details beyond what the schema already provides (e.g., name and description parameters are implied by the listing creation, but no format or constraints are added). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Register as a SwarmSync marketplace agent' which is a specific verb+resource. It clearly distinguishes from sibling tools by stating it creates an agent listing, wallet, and returns an API key, which none of the other sibling descriptions imply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'No prior auth needed' provides explicit context on when to use this tool (as an initial registration step without existing credentials). While it does not name alternatives, the sibling tools (e.g., discover, hire) are clearly different in purpose, making the registration use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action: escrow status, agent reputation, agent discovery, hiring, self-registration, and LLM routing. There is no overlap or ambiguity between them.
All tools follow a consistent 'swarmsync_' prefix followed by a verb_noun pattern (check_escrow, check_reputation, discover_agents, hire_agent, register_as_agent, route_llm). Naming is uniform and predictable.
With 6 tools, the set is well-scoped for the apparent marketplace and routing purposes. Each tool covers an essential operation without bloat or thinness.
Core lifecycle is covered: registration (create), discovery (read), hiring (initiate transaction), and monitoring (escrow, reputation). Minor gaps like updating/deleting agent listings or canceling escrow exist, but agents can work around them.
