mcp-azeth

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.24
Disambiguation5/5
Each tool has a clearly distinct purpose, covering different aspects like accounts, payments, messaging, reputation, and guardian management. The detailed descriptions ensure an agent can differentiate between tools like azeth_pay and azeth_smart_pay or various get_ and list_ tools.
Naming Consistency4/5
Tools follow a consistent azeth_<verb>_<noun> pattern, with verbs like create_, get_, list_, update_. Minor deviations exist, such as azeth_history instead of azeth_get_history, and azeth_pay/azeth_smart_pay being verb-only, but these are still clear and predictable.
Tool Count4/5
With 34 tools, the count is on the higher side but appropriate for the broad domain covering accounts, payments, reputation, guardian, messaging, and trust registry. Each tool serves a specific function, and while some could be merged, the count does not feel excessive.
Completeness4/5
The tool set covers the core lifecycle of the Azeth platform, including account creation, deposits, transfers, payments, agreements, reputation, and guardian management. A minor gap is the lack of a tool to remove a service from the trust registry, but this is an edge case. Overall, the surface is well-scoped and mostly complete.
Average 4.5/5 across 34 of 34 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 3 community issues answered or closed in the last 6 months
- 16 commits in the last 12 weeks
- Last stable release on July 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: partial history when indexer unavailable, a flag indexedHistoryUnavailable=true, and that it never errors. It also explains account determination from environment variable. This exceeds minimum transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear sections (use cases, returns, note, example). Every sentence serves a purpose, though some phrasing could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists return fields and handles edge cases (indexer unavailability). It is complete for a history tool, covering output, limitations, and configuration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions, so baseline is 3. The description adds an example and clarifies account resolution for smartAccount. It adds marginal value beyond the schema, earning a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent transaction history for an Azeth smart account, with specific use cases. It is distinct from sibling tools, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool (review past transactions, verify payment, audit activity) and notes limitations when the indexer is unavailable. It does not provide alternatives or when-not-to-use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds critical behavioral context not in schema: warns that 'First call may be slow due to XMTP initialization' and describes return value structure ('Array of conversations with peer address and creation time'). However, omits other behavioral details like sorting order, pagination limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with clear section headers (implied via 'Use this when:', 'Returns:', 'Note:', 'Example:'). Front-loaded with purpose, zero wasted words. Each sentence provides distinct value (purpose, usage criteria, return format, performance warning, usage example).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Compensates well for missing output schema by describing return values (array with peer address and creation time). Includes performance warning about XMTP initialization. Could be improved by defining 'active' conversations or mentioning result ordering, but sufficient for a simple list operation with one optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'chain' parameter fully documented including default behavior and accepted values. Description adds no parameter-specific guidance, but with high schema coverage, baseline 3 is appropriate—the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'List' + resource 'XMTP messaging conversations' + scope 'active'. Clearly distinguishes from sibling messaging tools like azeth_receive_messages (which gets content) and azeth_send_message (which sends), as this returns conversation metadata/addresses rather than message content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when:' section stating two clear scenarios: checking communication history and verifying if a conversation exists with a specific peer. Lacks explicit 'when not to use' or named alternatives (e.g., contrast with receive_messages), but context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full disclosure burden effectively. It explicitly states 'state-changing on-chain operation', explains the auth mechanism (AZETH_PRIVATE_KEY env var), describes the permanent identity aspect of the token ID, and clarifies discoverability outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear visual separators (Use this when:, Returns:, Note:, Example:). Each section serves a distinct purpose. Slightly verbose but no wasted sentences; the example JSON is helpful though incomplete (omits complex parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex blockchain operation with no output schema, the description adequately explains return values (token ID and transaction hash) and their significance. Covers auth, state change, and network effects well, though could mention error scenarios or gas implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, establishing a baseline of 3. The JSON example adds concrete semantic context for capabilities and entity types, but does not fully illustrate complex nested parameters like 'catalog' structure or pricing formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence clearly states the specific action (Register), resources (service, agent, or infrastructure), and scope (ERC-8004 trust registry). It distinguishes from siblings like 'azeth_update_service' (implied by 'Register' vs 'Update') and 'azeth_discover_services' (.publish vs .discover).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when' clause stating the discoverability intent. However, it lacks explicit guidance on when to use 'azeth_update_service' instead for existing registrations, or prerequisites like needing an account first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses critical behaviors: queries Azeth server API, environment variable configuration, default ranking by reputation, usableEndpoint flag, and that no private key is required. Minor omission: no mention of caching or rate limits, but acceptable for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose, clear sections, and examples. It is 8 sentences, efficient but not overly terse. Minor redundancy: example at end repeats schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully explains the return format: 'Array of registry entries with token ID, owner, entity type, name, capabilities, endpoint, and status' plus 'usableEndpoint flag'. Combined with the rich input schema (6 params all described), the tool is completely contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds usage context (examples, ranking behavior) but does not significantly extend beyond schema details. The offset parameter is not explained in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find services, agents, and infrastructure on the trust registry' with specific verbs and resources. It distinguishes from siblings like 'azeth_discover_agent_capabilities' and 'azeth_get_registry_entry' by focusing on broad discovery with filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'Use this when: You need to find a participant that offers a specific capability... or you want to browse available services filtered by type and minimum reputation score.' While it doesn't state when not to use, it gives sufficient context for appropriate tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explicitly states 'read-only and safe to call at any time'. Discloses return structure including 'pending timelock changes' which warns about pre-committed state. Doesn't mention auth requirements, but substantial behavioral coverage provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure: 1) Purpose, 2) When to use, 3) Return values, 4) Safety declaration, 5) Example. No wasted words; front-loaded with critical info. Sentence density is high with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so describing return values ('Returns: Full guardian state...') is essential and present. Covers safety profile, parameter usage via example, and distinguishes from mutation tools. Could briefly mention relationship to azeth_guardian_status, but complete enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for both chain (including default fallback chain) and smartAccount (including 'me' shorthand). Description includes example usage reinforcing the 'me' pattern, but since schema already documents all semantics thoroughly, this meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb 'View' + resource 'guardian security configuration'. Explicitly distinguishes from siblings like azeth_guardian_status (implied to return current status vs full configuration) and write operations like azeth_whitelist_token by focusing on security inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use this when:' section lists specific inspection scenarios (spending limits, whitelists, daily tracking). Clearly indicates appropriate contexts. Lacks explicit named alternatives or 'do not use when' guidance, but use cases are specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains the process: fetches URL, parses 402 terms, creates on-chain agreement. Mentions returns and prerequisite (service must advertise terms). Could detail side effects like gas costs, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: a brief paragraph plus a note. Every sentence adds value—purpose, usage, process, returns, and important note about automatic detection. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavior, prerequisites, and returns. Without an output schema, it names the returned fields (agreement ID, transaction hash, details). Lacks exact format but is sufficient for the tool's complexity (5 params, 1 required, no nested objects).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. The description does not add significant meaning beyond the schema's parameter descriptions; it focuses on high-level behavior rather than parameter details. Adequate but not over-performing baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool subscribes to an x402-gated service by creating a payment agreement. It distinguishes from the sibling tool azeth_pay by specifying it is for setting up a subscription instead of per-request payment, and implicitly differentiates from azeth_create_payment_agreement by focusing on automatic parsing of 402 terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this when: You want to set up a subscription instead of paying per-request,' and notes that after subscribing, azeth_pay will automatically use the agreement. Provides clear context but does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations exist, description carries full burden and succeeds well: discloses 'read-only operation', explains data source ('Names come from the trust registry'), and documents auth mechanism ('owner is determined by the AZETH_PRIVATE_KEY environment variable'). Also details return structure comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured with clear semantic blocks: purpose statement, usage guidance, return value specification, and behavioral notes. No redundant text; every sentence adds distinct value beyond the schema. Well front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a listing tool: compensates for missing output schema by detailing exact return values (EOA owner, indexed list with #N, name, address, tokenId). Covers authentication, data provenance, and workflow integration despite zero annotations and only one optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'chain' parameter, which is fully documented in the schema itself. Description does not mention the parameter, but with high schema coverage, baseline 3 is appropriate—no additional semantic value needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'List all your Azeth smart accounts with their names, addresses, and trust registry token IDs' provides exact verb, resource, and scope. Clearly distinguishes from sibling creation/mutation tools like azeth_create_account or azeth_transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong 'Use this when' section explicitly lists three scenarios (view at glance, find by name, get #N index). Mentions integration with other tools via indices. Lacks explicit 'when not to use' or named alternative tools, preventing a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It covers critical security behavior ('verifies ON-CHAIN that the target is a real Azeth smart account owned by you'), return values ('Transaction hash and deposit details'), and default fallbacks ('deposits to your first smart account'). Missing only gas/confirmation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense and front-loaded with the core action first. Structure follows logical progression: purpose → usage → security → parameters → examples. Lengthy but justified by the complexity of ETH vs ERC-20 handling and security requirements; no sentences are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multi-chain, multi-token, cryptographic ownership verification), the description adequately covers prerequisites, security constraints, and return values despite lacking an output schema. Sibling differentiation is implicit but sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds substantial value through conditional logic: 'omit the token parameter' for ETH, 'provide... AND decimals' for ERC-20, and the amount format clarification ('human-readable units'). The concrete JSON examples provide syntax clarity beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise action statement: 'Deposit ETH or ERC-20 tokens from your EOA wallet into your own Azeth smart account.' It specifies the exact resource types (ETH/ERC-20), source (EOA), and destination (Azeth smart account), clearly distinguishing it from sibling tools like azeth_transfer (likely inter-account) or azeth_pay (payment operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when' clause linking to specific downstream operations ('funding for transfers, x402 payments'). Includes clear security exclusions ('You cannot deposit to someone else's smart account'). Does not explicitly name sibling alternatives, though the context sufficiently differentiates it from payment/transfer tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden effectively. It specifies return formats (18-decimal USD, signed delta), aggregation logic (across tokens via oracle), value constraints (Always >= 0), auth requirements (no private key unless resolving 'me'/names), and read-only nature. Deducting one point only for missing edge case behavior (e.g., non-existent accounts).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure: one-line summary, usage clause, bulleted mode explanations, default behavior notes, auth disclaimer, and JSON examples. Every sentence serves a distinct purpose (scope, usage, behavior, safety, syntax). Length is appropriate for the complexity of the dual-mode logic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a read-only query tool lacking annotations or output schema. Explains domain context (payment-gated reputation), return value semantics, and address resolution behavior. Would be perfect with brief mention of error cases or zero-result handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds significant value by explaining the two operational modes (total USD vs per-token delta) and how parameters interact to trigger each mode. Examples provided ('0x0...0 for native ETH', '#1') supplement the schema constraints effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource combination ('Check how much one account has paid another') and clearly distinguishes this from siblings like azeth_balance (holdings) and azeth_pay (action) by specifying the directional payment relationship between two accounts and the net aggregation concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when' clause targeting payment verification for reputation system feedback weight. While it doesn't explicitly name sibling alternatives to avoid (e.g., azeth_history), it clearly defines the specific verification use case that distinguishes it from general balance checks or payment execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Good: No annotations provided, so description carries full burden. Discloses 'read-only and safe', on-chain resolution behavior for addresses, and detailed return structure (name, capabilities, reputation score). Missing error behavior or rate limit disclosures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent: Well-structured with clear logical sections (Purpose, Usage, Input guidance, Returns, Safety, Example). Front-loaded with core purpose. No redundant text; every sentence adds unique value beyond the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Strong for complexity level: No output schema exists, but description compensates by documenting all return fields. Covers all 3 parameters with chain aliases noted. Would benefit from error case documentation (e.g., 'not found' handling).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Strong: Schema coverage is 100%, but description adds critical semantic constraints beyond schema—the XOR requirement ('Provide EITHER...') and address resolution logic. Includes concrete JSON examples that clarify expected formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent: States specific verb 'Look up' + resource 'participant on the trust registry' + exact identifiers 'token ID or smart account address'. Clearly distinguishes from sibling discovery tools by emphasizing 'specific participant' lookup vs broad discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong: Contains explicit 'Use this when' clause defining the specific scenario (known address/token ID seeking details). States parameter constraint 'EITHER...OR (at least one required)'. Lacks explicit 'when not to use' or named alternative siblings (e.g., vs discover_services).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It successfully explains critical behavioral traits: it signs userOpHash with AZETH_PRIVATE_KEY, transmits via XMTP, and returns different structures based on mode. Minor gap: could clarify irreversibility of approvals or network confirmation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sectioning (concept explanation, three modes, technical mechanism, returns, examples). Front-loaded with purpose. Slightly verbose but every sentence adds necessary context for a security-critical blockchain operation. Examples are appropriately placed at end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema (has_output_schema: false), so description must compensate for return values. It mentions returns at high level ('List of pending requests' or 'confirmation') but does not describe the structure/shape of these return objects (e.g., what fields comprise a 'request' object), which limits the agent's ability to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. The description adds significant value through the 'Three modes' narrative that contextualizes parameter combinations (e.g., request_id omission triggers list mode), and provides concrete JSON examples showing how parameters interact, which aids agent reasoning beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (review/approve/reject) and resource (guardian approval requests). It distinguishes itself from sibling `azeth_guardian_status` by emphasizing the active response capability ('Use this tool to review and respond') versus passive status checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('When an agent exceeds its autonomous spending limits... sends you an approval request'). Documents three distinct operational modes (list, approve, reject) with clear prerequisites for each, effectively serving as usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It successfully documents: end-to-end encryption nature, account determination via AZETH_PRIVATE_KEY environment variable, initialization latency on first call, and dual behavioral modes. Missing rate limits or caching details, but covers critical runtime characteristics well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, usage trigger, behavioral modes, return values, implementation notes, and examples. Front-loaded with essential information. Slightly verbose but information-dense; the mode differentiation and return structure documentation justify the length given no output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Excellent compensation for missing annotations and output schema. Describes return structure (array with sender, content, timestamp, conversation ID), encryption characteristics, environment variable dependencies, and performance characteristics. Covers all 3 parameters conceptually and provides concrete usage examples. Complete for a message retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage (baseline 3). Description adds value by explaining the interaction model between parameters—the 'Two modes' section clarifies that omitting 'from' triggers inbox overview behavior while including it enables specific sender filtering with limit application. Examples demonstrate valid parameter combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb 'Read' and resource 'incoming encrypted messages from the XMTP messaging network.' It clearly distinguishes from sibling azeth_send_message by describing this as the 'inbox view' for reading what others sent you, versus sending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when' guidance for checking messages from other agents. Documents two distinct usage modes (with/without 'from' parameter) that clarify behavioral alternatives. Lacks explicit 'when not to use' or comparison to azeth_list_conversations, but the 'inbox' framing provides clear contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It details that only the owner can update, the requirement for guardian co-signature, the auto-signing for self-guardian accounts, and the specific error (GUARDIAN_COSIGN_REQUIRED) for distinct guardians. It also explains the impact on executor modules and returns a transaction hash. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Use this when, Why it matters, Returns, Note, Example). It is moderately long but each sentence adds value without redundancy. Slight verbosity in the 'Why it matters' section could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with guardian and whitelist logic), no output schema, and no annotations, the description covers purpose, usage context, behavioral nuances, return value, and provides an example. It adequately prepares an agent to select and invoke the tool correctly without missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions (100% coverage). The description's example and note about using the zero address for native ETH add marginal value beyond the schema. It does not explain chain aliases or smart account defaults beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add or remove a token from your smart account's guardian whitelist.' It specifies the resource (guardian whitelist) and the context (payment agreements or executor-module operations). While there is a sibling tool 'azeth_whitelist_protocol', the description's specificity and depth effectively distinguish its purpose from general whitelist operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this when: You need to whitelist a new token for payment agreements or other executor-module operations.' It also notes default whitelisted tokens (ETH, USDC, WETH). However, it does not explicitly exclude alternative tools or mention when not to use it, lacking full comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the action is a single atomic transaction, installs 4 modules, permanently revokes factory access, details gas sponsorship and fallback, explains guardian derivation from environment variables, and specifies return fields (address, token ID, tx hash, creationPath). This is comprehensive and goes beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, usage scenario, atomic details, returns, gas info, guardian setup, and an example. It is somewhat lengthy but every sentence adds necessary information without redundancy. Front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description covers creation behavior, gas handling, guardian configuration, defaults, and includes an example. It does not exhaustively cover all edge cases or errors, but it provides sufficient context for an AI agent to understand invocation and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds significant value by explaining defaults (chain from env var, guardian from env var, explicit default spending limits per network), providing an example, and clarifying behavior for optional parameters like 'emergencyWithdrawTo'. This enriches the schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deploy a new Azeth smart account') and the resource ('register it on the ERC-8004 trust registry'). It distinguishes from sibling tools like 'azeth_accounts' (list accounts) or 'azeth_balance' (check balance) by focusing on creation and registration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: 'An AI agent or service needs its own on-chain identity with spending limits and trust registry presence.' It also mentions that one EOA can own multiple accounts, providing context. It does not explicitly state when not to use, but the purpose is clear enough to avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It effectively covers prerequisites ('target agent must be online and have a MessageRouter'), protocol details ('Sends a JSON capabilities request'), synchronous behavior ('waits for their response'), and failure modes ('If no response within the timeout').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose (sentence 1), usage guidelines (sentence 2), behavioral details (sentences 3-4), parameter notes (sentence 5), return values (sentence 6), and example (sentence 7). Every sentence earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations or output schema, the description is comprehensive. It explains return values ('capabilities including services, pricing, and usage instructions'), timeout behavior, and prerequisites that would otherwise be unknown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description duplicates the agentAddress format documentation from the schema and includes a helpful JSON example, but does not add significant semantic value beyond the well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a specific action ('Discover what services an agent offers') and mechanism ('sending them a capabilities request over XMTP'), distinguishing it from sibling tool 'azeth_discover_services' (which likely queries the registry) by emphasizing direct agent-to-agent communication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use this when' pattern clearly defines the context (finding services/pricing) and positions the tool relative to alternatives ('before making a service request or payment'), implying when to use payment/agreement tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully covers behavioral aspects: it states the tool is read-only, requires no private key or gas, and notes that values only update when a storage proof is submitted (azeth_prove_reputation). This provides essential transparency about side effects and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear title, usage guidance, return description, a behavioral note, and an example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains the return format (aggregate, per-chain breakdown, human-readable summary) and the update mechanism. For a read-only query tool with moderate complexity, this provides sufficient completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters (from, to, l1Chain). The description adds an example usage and a note about l1Chain defaults, but does not substantially enhance parameter meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get L1-proven cross-chain payment reputation between two accounts from TrustL2Reader.' It identifies the specific resource (cross-chain payment reputation) and action (get), and distinguishes from sibling tools like azeth_get_net_paid and azeth_get_weighted_reputation by emphasizing cross-chain and L1-proven aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use this when: you want the trust-weighted net USD one account has provably paid another across all registered L2 chains, as visible on Ethereum L1.' It does not explicitly exclude scenarios or mention alternatives, but the context is specific enough to guide appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the scanning nature ('scans all agreements'), performance implications ('consider filtering... for large-scale'), return structure ('Array of due agreements with...'), and workflow integration ('can be passed directly to azeth_execute_agreement'). Lacks explicit confirmation of read-only safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
optimally structured with clear functional sections: purpose (sentence 1), usage context (sentence 2-3), return value (sentence 4), workflow integration (sentence 5), and performance note (sentence 6). No redundant text; every sentence advances agent understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully compensates by detailing the return structure (array with payer account, agreement ID, expected payout). It also explains the keeper/execution workflow context essential for blockchain payment agreement tools. Complete for a 2-parameter query tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for both 'chain' and 'accounts' parameters. The description references 'one or more accounts' which aligns with the accounts parameter, but does not add semantic detail beyond what the comprehensive schema already provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Find') and resource ('payment agreements that are due for execution'), clearly distinguishing this from sibling tool 'azeth_list_agreements' by emphasizing the 'due' status filter. It also explicitly names 'azeth_execute_agreement' as the downstream consumer, establishing clear separation of concerns between querying and execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains an explicit 'Use this when:' section identifying two distinct personas (keeper bots and service providers) with concrete scenarios. It also provides implicit 'when-not' guidance via the Note recommending filtering for large-scale operations, helping agents optimize usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden and excels: declares 'read-only on-chain query' (safety), warns 'may take a few seconds' for large accounts (performance), notes 'iterates through all agreements' (implementation), and specifies return format 'Array of agreement summaries sorted by ID' (output compensation for missing schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfect structure: purpose statement → use cases → returns → technical notes. No wasted words. Performance warning is essential context. Front-loaded with clear intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a list tool: compensates for missing output schema by describing return array structure and sorting, covers performance implications of on-chain iteration, and documents behavioral characteristics that annotations would typically provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (chain variants, account formats, status enum values). Description mentions filtering by status in usage context but does not add syntax/format details beyond schema. Baseline 3 appropriate when schema does heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent: 'List all payment agreements for a smart account with summary status' provides specific verb (List), resource (payment agreements), scope (all, with summary status), and implicitly distinguishes from sibling azeth_get_agreement (singular detail fetch) by emphasizing 'all' and 'summary'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong 'Use this when' section lists four specific scenarios including finding agreement IDs and checking due agreements. However, lacks explicit 'when not to use' guidance or naming of alternatives like azeth_get_agreement for detailed single-record views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full disclosure burden effectively. Documents gas costs ('requires a transaction'), authorization ('Only the account owner'), prerequisites ('account must already be registered'), and return value ('Confirmation with transaction hash'). Missing only edge case/error behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear semantic blocks: purpose, usage conditions, supported values, important limitations (catalogs), return type, prerequisites, and example. Each sentence delivers unique information. Minimally redundant with schema (only capabilities format overlaps slightly).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a blockchain mutation operation with no output schema, coverage is strong: gas costs, ownership requirements, prerequisites, return format, and sibling relationships are all documented. Only lacks explicit error condition descriptions or idempotency notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description adds value by enumerating supported keys (redundant but scannable), emphasizing JSON array format for capabilities, and providing a concrete JSON usage example ('{"key": "endpoint", ...}') that clarifies the key-value structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Update metadata') and resource ('registered service on the trust registry'). Explicitly distinguishes from sibling azeth_publish_service by noting this is for changes 'after initial registration', clarifying the update vs. create distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when' clause with specific scenarios. Names prerequisite sibling tool (azeth_publish_service) for initial registration. Critically includes negative guidance ('Update your catalog...not via this tool') preventing common misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details on-chain nature, accrual mechanics, totalCap calculation, balance requirements, payer determination, and execution process. Very thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, when to use, returns, detailed behavior notes, examples. Slightly long but each part is informative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, description covers return values, default behaviors, constraints, and provides examples. Complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but description adds meaning beyond schema: explains totalCap defaults, interval minimum, endTime constraints, and provides examples. Adds value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sets up a recurring payment agreement on a fixed interval, with specific verb 'create' and resource 'payment agreement'. Distinguishes from siblings like one-time payments or cancellations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit 'Use this when' section listing examples like subscriptions and scheduled transfers. No explicit when-not but context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description fully compensates by disclosing: (1) safety profile ('read-only', 'No private key or gas required'), (2) calculation methodology ('weighted average where each rater's influence is proportional to their USD payment'), (3) return value structure ('weightedValue (int256), totalWeight, and opinionCount'), and (4) filtering behavior for empty raters array.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear logical sections: purpose, usage trigger, return semantics, behavioral note, parameter guidance, and examples. Every sentence conveys unique information. Examples are appropriately placed at the end without cluttering the core description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a read query tool. Since no output schema exists, the description commendably documents the return structure (int256 values, counts). It compensates for missing annotations with safety disclosures. Minor gap: it doesn't mention the chain parameter's default behavior (though the schema covers this thoroughly).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds valuable semantic context beyond the schema: it explains the default behavior when raters is empty ('Leave raters empty to aggregate across all raters'), and provides concrete JSON examples showing both minimal and full parameter usage patterns. Slight deduction as it doesn't augment the chain parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise action (Get) + specific resource (USD-weighted reputation) + source (on-chain ReputationModule). It clearly distinguishes this from sibling tools like azeth_get_active_opinion or azeth_get_net_paid by specifying the unique USD-weighted calculation methodology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when' guidance ('check the reputation of an agent or service before interacting'), which establishes clear intent. However, it lacks explicit 'when not to use' guidance or named alternatives (e.g., when to prefer azeth_get_active_opinion instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: auto-handles 402, checks agreements, signs USDC, requires balance, uses maxAmount cap, only HTTPS, payer from AZETH_PRIVATE_KEY. It also details return values and payment methods.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Approximately 150 words, well-paragraphed. Front-loads purpose, then usage, behavior, notes, example. Every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no output schema), the description is thorough: covers payment flow, return values, env vars, chain defaults, smart account selection, and examples. Could mention error handling but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds meaningful context: examples, explanation of maxAmount as a cap, default chain, smart account indexing, and body usage for POST etc. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pays for x402-gated HTTP services, handles 402 automatically, and returns the response. The verb 'pay' and resource 'x402-gated HTTP service' are specific and distinguish it from siblings like azeth_smart_pay or azeth_create_payment_agreement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this when: You need to access a paid API or service that uses the x402 payment protocol'. This provides clear context for when to use. It does not list alternatives, but the specificity is sufficient. No exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behaviors: proof building from current rollup anchor, simulation only by default, L1 transaction submission only when broadcast=true, read-only nature of broadcast=false, need for AZETH_PRIVATE_KEY and L1 ETH for broadcast, and requirement of an archive L2 RPC. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a clear purpose statement, usage condition, behavioral explanation, return fields, note, and example. Every sentence contributes necessary information without redundancy. It is appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description covers purpose, usage, parameters, behavior, return values, and side effects. It could be improved by mentioning potential error conditions or prerequisites like existence of TrustL2Reader, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the role of 'payer' (the account whose net USD payments are recognized) and explaining the 'broadcast' parameter's effect and prerequisites. The example also provides concrete usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'prove' and the resource 'L2 net-USD payment relationship on L1 via MPT storage proof against TrustL2Reader'. It distinctly differentiates from sibling tools by focusing on cross-chain reputation proof, a unique capability not shared by other azeth tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use this when: you want L2 (Base Sepolia) payment reputation between two accounts recognized on Ethereum L1...' It also clarifies the two modes (broadcast=false vs true) and their requirements. However, it does not explicitly exclude scenarios where alternative tools would be more appropriate, so a 4 is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description bears full disclosure burden. It successfully documents idempotency ('NOT idempotent'), authentication source ('AZETH_PRIVATE_KEY environment variable'), size limits ('10,000 characters'), and return values ('conversation ID and recipient address'). Only misses error handling or rate limiting details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: Purpose, Usage condition, Prerequisites, Return values, and Important notes. Front-loaded with the core action. Slightly verbose but justified given complexity (4 parameters, encryption context, prerequisites) and absence of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a messaging tool with no output schema and no annotations. Covers prerequisites (reachability), behavioral constraints (idempotency, length limits), authentication method, and return structure. No significant gaps given the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description adds value by consolidating the 'to' field syntax options into narrative context ('accepts: an Ethereum address...') and providing a concrete JSON example showing parameter usage patterns beyond raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Send an encrypted message'), target resource ('participant'), and network ('XMTP'). Clearly distinguishes from sibling 'azeth_receive_messages' by directionality and 'azeth_check_reachability' by being the actual messaging action versus a prerequisite check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when' clause defining the communications use case. Names specific prerequisite tool ('azeth_check_reachability first if unsure') for recipient verification, clearly delineating the workflow sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses sequential non-atomic execution, partial failure handling, max limit, off-chain catalog nature, and return value, exceeding expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and front-loaded purpose, but somewhat lengthy; could be slightly more concise while retaining all key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers return confirmation, edge cases like sequential execution and max items, and gives example; highly complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline 3; description adds value by explaining capabilities JSON array string, default chain, and providing an example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it updates multiple metadata fields for a registered service in one call, lists supported keys, and distinguishes from sibling tools by specifying batch updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (changing several fields at once), gives guidance on capabilities format and max items, but doesn't explicitly contrast with single update tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description comprehensively covers: read-only/safety nature ('read-only, single-RPC-call operation and safe to call repeatedly'), authentication mechanism ('owner is determined by the AZETH_PRIVATE_KEY environment variable'), and return structure ('Multi-account breakdown with per-token USD values... EOA is shown first (index 0)').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (action, usage context, returns, optional filtering, implementation notes, examples). Every sentence serves a distinct purpose. Front-loaded with core functionality, followed by when-to-use, then technical implementation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description fully compensates by detailing the return format (multi-account breakdown, per-token USD values, grand total, ordering of EOA vs smart accounts). Also covers environment variable dependencies (AZETH_PRIVATE_KEY, AZETH_CHAIN) making it complete for a balance query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. Description adds valuable contextual usage guidance: 'Optionally filter to a single smart account by providing its address' explains the filtering behavior, and the examples ('{} or { "smartAccount": "#1" }') demonstrate practical usage patterns beyond raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'Check all balances with USD values for your EOA and all Azeth smart accounts' provides clear verb (Check), resource (balances), scope (EOA + all smart accounts), and differentiates from siblings like azeth_transfer, azeth_pay, and azeth_deposit by focusing on portfolio reading vs execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong 'Use this when' section specifies exact scenarios (checking ETH/USDC/WETH holdings, getting portfolio value 'before making a transfer or payment'). Implicitly distinguishes from execution tools by mentioning the 'before' context, though it could explicitly name sibling alternatives like 'instead of azeth_transfer'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'This is read-only and safe to call at any time' and discloses the return value structure ('Whether an active opinion exists and its opinion index'). It lacks detail on error conditions or rate limits, but covers the essential safety and return contract adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, usage trigger, parameter semantics, return values, safety note, and example. Every sentence earns its place; there is no repetition of schema contents or unnecessary verbosity while maintaining completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description appropriately documents the return values ('Whether an active opinion exists and its opinion index'). For a read-only verification tool with 100% schema coverage, the description provides complete contextual information including prerequisites and safety characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds significant value by explaining that 'agentId' is an 'ERC-8004 token ID' and directing users to specific sibling tools to find valid token IDs. It also provides a concrete JSON example, which aids in correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Check') and clearly identifies the resource ('active reputation opinion') and scope ('for a specific agent'). It distinguishes itself from the sibling tool 'azeth_submit_opinion' by noting that submitting a new opinion would overwrite an existing one, implying this tool is for verification before that write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains explicit 'Use this when' guidance describing the specific scenario: verifying existing opinions before submitting new ones to avoid accidental overwrites. It also references sibling tools 'azeth_discover_services' and 'azeth_get_registry_entry' as prerequisites for obtaining the required token ID, providing clear navigation through the tool ecosystem.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description fully covers behavior: discovery by reputation, fallback, autoFeedback defaults, safety guarantee on intent miss, return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and examples. Slightly lengthy but front-loaded with core purpose and differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
10 parameters and no output schema, but description covers return values, intent resolution, and safety guarantees adequately for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds significant value: explains intent vs params, autoFeedback defaulting, chain aliases, maxAmount rejection behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it discovers and pays for the best service by capability. It distinguishes from sibling azeth_pay by contrasting capability-based vs. URL-based selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (by capability) and how it differs from azeth_pay. Provides flow description and intent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly discloses: requires a UserOperation (gas), only account owner can modify, requires guardian co-signature, explains self-guardian vs distinct guardian behavior, and mentions the return value (confirmation with transaction hash).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, a dedicated 'Use this when' section, a note about requirements, and an example. Every sentence earns its place, and it is appropriately sized without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and the comprehensive description covering behavioral aspects (permissions, co-signature, gas requirements) and an example, the description is complete. There is no output schema, but the return value is mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by providing an example, clarifying that the protocol field must be a valid Ethereum address, and noting default behaviors for chain and smartAccount. This enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add or remove a protocol (contract address) from your smart account's guardian whitelist.' This is a specific verb and resource, and it distinguishes from the sibling tool 'azeth_whitelist_token' which deals with tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when: You need to interact with a new DeFi protocol or contract through executor modules (like PaymentAgreementModule). Protocols must be whitelisted for automated operations to succeed.' This provides clear context and when to use, but does not explicitly state when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full burden: states 'state-changing on-chain operation', discloses auto-revocation of previous entries, notes AZETH_PRIVATE_KEY auth requirement, explains payment-gating mechanism, and specifies transaction hash return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, usage, returns, notes, examples). Slightly verbose but justified by complexity (8 params, blockchain mutation). Every sentence adds value; front-loaded with critical behavioral constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Excellent coverage for a complex state-changing operation: covers prerequisites (payment, auth), side effects (revocation), data formats (WAD), and return values. No output schema exists but return value is documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, adds crucial context: rating range (-100 to 100, decimals), WAD format storage details, tag usage examples ('quality', 'x402'), and private key environment variable dependency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Submit' combined with precise resource 'payment-gated reputation opinion' and target 'ERC-8004 Reputation Registry' clearly distinguishes this from sibling tools like 'azeth_get_active_opinion' or 'azeth_publish_service'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use this when' clause ('interacted with an agent/service and want to rate') and prerequisites ('must have a minimum USD payment to the target'). Also clarifies update semantics vs. alternatives ('previous entry is automatically revoked').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explicitly states 'This is a state-changing operation,' discloses return values (tx hash, sender/recipient addresses, amount), notes that resolved address is shown before executing, and explains sender determination via AZETH_PRIVATE_KEY env var.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Lengthy but well-structured with clear logical sections: purpose, usage conditions, input formats, warnings, returns, and examples. Every sentence conveys necessary information for safe blockchain operations, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Excellent coverage for complex tool with no output schema and 6 parameters. Documents return values, prerequisites, environment variable dependencies (AZETH_PRIVATE_KEY, AZETH_CHAIN), and safety guardrails (showing resolved address pre-execution). Complete despite lack of structured annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage (baseline 3). Description adds significant value: concrete JSON examples, explains conditional logic (omit token for ETH, required for ERC-20), clarifies relationship between token and decimals parameters, and documents valid 'to' field formats (address, name, 'me', '#N').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('Send') and resource ('ETH or ERC-20 tokens'). Explicitly distinguishes from siblings by specifying it sends FROM smart account (not EOA), contrasting with azeth_deposit (funding) and referencing azeth_accounts for the #N syntax.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use this when' section lists specific scenarios (pay participant, fund account, move tokens). Clear prerequisite guidance: 'Use azeth_deposit first to fund your smart account if needed.' Also warns about EOA vs smart account distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses critical behavioral traits: immediate effect ('no timelock'), financial consequences ('no penalty', 'not refunded'), authorization rules ('Only the payer'), and exact return value structure ('Transaction hash and final agreement state').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with zero waste. Front-loaded with action, followed by usage condition, behavioral warnings, and return specification. Clear logical flow from intent to execution to consequence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete coverage for a 3-parameter destructive operation. Compensates for missing output schema by documenting return values. Covers authorization, side effects, and financial implications necessary for safe blockchain operation invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage establishing baseline 3. Description adds semantic context about ownership ('Only the payer... can cancel') which reinforces the smartAccount parameter constraints, justifying the bump above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with specific verb+resource ('Cancel an active payment agreement') and explicitly distinguishes from sibling operations like create_payment_agreement or execute_agreement by stating it stops 'recurring payment subscription or data feed' and that 'Only the payer... can cancel'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains explicit 'Use this when:' clause defining the trigger condition (stopping subscriptions/feeds). Also includes prerequisite/authorization constraint ('Only the payer... can cancel') that guides agent away from using this tool for agreements the user doesn't own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Successfully documents: return structure (address + boolean), caching semantics (5 minutes), success criteria (active XMTP identity), and authentication mechanism (AZETH_PRIVATE_KEY env var). No contradictions present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, usage trigger, safety note, parameter details, return values, implementation notes, and examples. Every sentence conveys distinct information. Appropriate length for complexity level without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a 2-parameter tool without output schema. Documents return values, caching behavior, environment dependencies, and reachability logic. No gaps remain for safe invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% establishing baseline 3. Description adds practical value through concrete JSON examples showing different address formats (participant name 'Alice' vs hex address) and clarifying '#N' refers to account indices. Helps agents understand semantic distinctions between address input formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Check') against specific resource ('Ethereum address') within specific domain ('XMTP messaging network'). Clearly distinguishes from sibling messaging tools like azeth_send_message by positioning it as a pre-flight verification capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains explicit 'Use this when' clause specifying verification before sending messages. Explicitly identifies appropriate context (pre-send validation) and operational characteristics ('read-like operation and safe to retry'), guiding selection over alternatives like direct message sending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden and excels: it validates conditions on-chain (interval, caps), explains pro-rata accrual mechanics (capped at 3x), documents keeper routing logic for foreign accounts, and crucially discloses soft-failure modes (insufficient balance, guardian limits) that return reasons without reverting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured with front-loaded purpose, followed by use-case scenarios, keeper technical details, validation logic, and return values. No redundancy; every sentence advances understanding of when/how to use the tool or what happens during execution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high complexity (pro-rata calculations, keeper mechanics, soft-failures) and no output schema, the description is complete: it documents return values (tx hash, amount, execution count, next time) and all behavioral edge cases necessary for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds valuable semantic context: 'account' is clarified as potentially 'foreign' (not owned) triggering keeper routing, and 'agreementId' is explicitly linked to sibling tools (azeth_create_payment_agreement, azeth_list_agreements) helping users locate valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action 'Execute a due payment from an on-chain agreement' and immediately distinguishes this from sibling tools by clarifying this triggers payment execution versus creation (azeth_create_payment_agreement), cancellation (azeth_cancel_agreement), or querying (azeth_get_due_agreements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when' guidance covering three distinct roles: service provider collecting payment, payer manually triggering, and keeper bot executing. It further clarifies keeper mechanics for foreign addresses, effectively describing prerequisites and routing behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Comprehensive disclosure appropriate for zero annotations: explicitly states 'read-only on-chain query,' gas requirements ('no gas'), and authentication needs ('no private key required...but account resolution may need your key'). Also clarifies return characteristics ('human-readable amounts') and specific account syntax caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (main description, Use this when, Returns, Note). Front-loaded with core action. Every sentence conveys unique operational guidance; no redundancy with schema or sibling tool names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a read-only query tool: describes return value contents ('Complete agreement details with human-readable amounts') despite lack of output schema, covers blockchain-specific concerns (gas, keys, on-chain nature), and contextualizes within the broader agreement lifecycle (creation→inspection→execution/cancellation).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. Description adds value by explaining security implications for specific account parameter values ('me' or '#N' require key for resolution), providing critical semantic context beyond the schema's type description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'View full details of a payment agreement' provides clear verb+resource, and enumerates specific data points (status, payment history, next execution time). Clearly distinguishes from sibling tools like azeth_execute_agreement and azeth_cancel_agreement by emphasizing inspection/verification rather than mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Exemplary explicit guidelines under 'Use this when:' covering three distinct scenarios (pre-execution inspection, post-creation verification, payment history checks). Directly references sibling operations 'executing or cancelling' to establish clear selection criteria vs state-changing alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden and succeeds comprehensively. It documents the XMTP communication mechanism, enumerates all four terminal states (approved/rejected/pending/expired), specifies the 5-minute expiration timeout, and explains corrective actions (retry original operation for approved/expired states).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear visual hierarchy: purpose declaration, usage trigger, enumerated status outcomes with sub-bullets, return value summary, and example. No redundant text; every section serves a distinct purpose for agent decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema exists, the description compensates by detailing return value semantics ('signature if approved, reason if rejected'). It fully documents the asynchronous guardian approval lifecycle, providing sufficient context for the agent to handle all terminal states appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. The description adds value through a concrete JSON example ('Example: { "request_id": "abc-123" }') demonstrating expected input structure, though it does not elaborate further on parameter semantics beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Check the status of a pending guardian approval request') that precisely identifies the tool's function. It clearly distinguishes this from sibling tool 'azeth_guardian_approve' by positioning this as a polling/status-check operation rather than an action submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains explicit 'Use this when' clause that precisely defines the prerequisite state (previous timeout with request_id from co-signature operation). This prevents misuse by clarifying this is a follow-up tool, not for initial guardian requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/azeth-protocol/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/azeth-protocol/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/azeth-protocol/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/azeth-protocol/mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/azeth-protocol/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server