TASK+BUDGET procurement: describe what you need in plain language + max spend; Aegis picks the best verified service, executes with failover, captures only on delivery, returns data + Ed25519-signed receipt. Never over budget. Dynamic x402 via _meta.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | ||
| budget | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses several key behaviors: service selection, execution with failover, payment only on delivery, signed receipt, and budget enforcement ('Never over budget'). This goes beyond basic mutation but does not cover potential errors, auth, or rate limits.
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 concise at two sentences, front-loading the purpose with 'TASK+BUDGET procurement'. While it includes jargon ('Aegis', 'x402', '_meta') that may require prior knowledge, every sentence contributes valuable information about behavior and constraints.
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?
For a simple 2-parameter tool with no output schema, the description is relatively complete. It indicates the return value ('returns data + Ed25519-signed receipt') and key behavioral guarantees. However, 'data' is vague, and the term 'x402 via _meta' is unexplained, leaving some gaps in understanding the full context.
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 description coverage is 0%, so the description must explain the parameters. It does this directly: 'need' is described as 'what you need in plain language' and 'budget' as 'max spend'. This adds essential meaning beyond the bare type declarations in the schema, fully compensating for the lack of schema descriptions.
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 clearly states the tool performs 'TASK+BUDGET procurement' with a specific verb and resource. It distinguishes itself from sibling tools by focusing on executing a purchase/service engagement, unlike discovery or routing tools, with details like 'picks the best verified service' and 'executes with failover'.
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 description provides clear usage context: 'describe what you need in plain language + max spend' tells the agent how to invoke the tool. However, it does not explicitly state when not to use this tool or mention alternatives, leaving the when-to-use versus siblings implied rather than explicit.
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.
Multiple tools have overlapping purposes: discover and smart_discover both find services but differ only by price and method; procure and route both buy services with failover; erc8004_reputation and trust_check both assess trust. This creates ambiguity in tool selection.
Tool names mix bare verbs (discover, procure, route), compound verbs (smart_discover, trust_check), and noun-style names (erc8004_reputation). No consistent verb_noun or action_resource pattern is followed.
Seven tools is a reasonable count for the domain of service discovery and procurement. However, some tools are near-duplicates, so the count feels slightly inflated but not excessive.
The set covers discovery, trust evaluation, and procurement. Missing pieces include service registration/management and perhaps a way to query past transactions, but core consumer workflows are represented.