On-chain ERC-8004 reputation for any registered agent (Base IdentityRegistry) + Aegis probe cross-check + divergence flag. Paid $0.005 via x402 (_meta['x402/payment']).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | ||
| agent_id | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It discloses the $0.005 payment via x402, which is a critical side effect, and mentions the Aegis probe cross-check and divergence flag. However, it does not state whether the operation is read-only, what the divergence flag represents, or how failures (e.g., unregistered agent) are handled.
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, consisting of two sentences that are front-loaded with the primary purpose. The payment information is included as a separate sentence, which is important and earns its place. The style is slightly noun-heavy, lacking a direct verb, but there is no wasted wording. It could be improved by starting with 'Get' or 'Fetch.'
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 the lack of annotations and output schema, and the sparse parameter documentation, the description is not complete enough. It explains what the tool does at a high level and notes the cost, but it does not describe the return value, the exact meaning of parameters, or edge-case behavior. An agent would need more information to invoke this tool correctly, especially regarding the 'domain' parameter.
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?
The input schema has two parameters, domain and agent_id, with zero description coverage (0%). The description does not explain either parameter explicitly. It hints that 'agent_id' corresponds to an agent in the Base IdentityRegistry, but 'domain' remains ambiguous. With no schema descriptions, the description should compensate but does not provide sufficient per-parameter meaning.
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 identifies the tool as providing on-chain ERC-8004 reputation for agents on the Base IdentityRegistry, plus an Aegis probe cross-check and divergence flag. It lacks an explicit verb like 'Get' or 'Fetch,' but the noun-phrase style still conveys the purpose. It distinguishes from siblings by referencing ERC-8004 and Aegis, though it doesn't explicitly compare to 'trust_check.'
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?
There is no explicit guidance on when to use this tool versus alternatives. The description mentions 'any registered agent' and a payment requirement, but it does not state scenarios where this should be preferred over sibling tools such as 'trust_check' or 'discover.' It only implies that it is used when ERC-8004 reputation is needed.
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.
discover and smart_discover overlap as discovery mechanisms, differing mainly in query style. procure and route both involve paying Aegis to fulfill a service with failover, so an agent could struggle to choose between them despite different framing.
Most names use lowercase with underscores and verb-like prefixes, but erc8004_reputation and trust_check are noun-phrase names while discover, procure, route, and route_batch are imperative verbs. The mixed conventions are readable but not predictable.
Seven tools cover the core facets of the Aegis service registry, discovery, procurement, routing, batch execution, and trust verification. This is a well-scoped size for the server's stated purpose.
The set covers discovery, on-chain reputation, trust checking, single routing, batch routing, and budget-based procurement. Minor gaps like explicit payment status or account balance checks exist, but agents can complete primary workflows without dead ends.