Server Quality Checklist

Tool Scores

• wot_compare_providersB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses behavioral output ('consensus classification' and 'provider agreement') but lacks critical operational context given the 'payment_hash' parameter suggests freemium limitations. No mention of rate limits, authentication needs, or what constitutes consensus.

  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?

  Two sentences with zero waste. Front-loaded with primary action (Compare), followed by output description. Every word earns its place.

  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?

  Adequate for a read-only comparison tool with rich schema coverage, but missing output structure description (no output schema provided) and NIP-85 domain context that would help agents unfamiliar with Nostr protocols.

  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?

  With 100% schema coverage, baseline is 3. Description mentions 'pubkey' but adds no semantic detail beyond the schema's 'Nostr public key in hex format'. Baseline maintained.

  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?

  Specific verb 'Compare' with clear resource 'trust scores' and scope 'across multiple NIP-85 providers'. Implicitly distinguishes from sibling 'wot_score' (single score) by emphasizing cross-provider comparison and consensus.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this versus siblings like 'wot_score' or 'wot_sybil_check'. While 'across multiple providers' implies use-case, there are no 'when to use' or 'when not to use' directives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wot_anomaliesA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Without annotations, the description carries the full disclosure burden. It effectively lists the specific anomaly types detected (ghost followers, asymmetric relationships, cluster patterns), but omits operational context like the payment/freemium model (hinted at by the payment_hash parameter), rate limits, read-only status, or return value structure.

  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?

  Two well-constructed sentences with zero redundancy. The first establishes the core purpose, the second enumerates specific detection capabilities. Every word earns its place with no filler or repetition of the tool name.

  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?

  Given the lack of output schema and annotations, the description adequately covers the tool's functional scope but leaves operational gaps. Notably, it fails to explain the payment/freemium implications suggested by the payment_hash parameter, nor does it describe expected return formats or how to interpret anomaly findings.

  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%, documenting both the pubkey format and payment_hash purpose. The description adds no parameter-specific context, meeting the baseline expectation that high-coverage schema reduces the description's burden for this dimension.

  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 uses a specific verb ('Detect') with a clear resource ('Nostr pubkey's network behavior') and distinguishes itself from sibling WOT tools by focusing specifically on 'anomalous patterns' rather than general scoring, trust paths, or sybil checks. The enumerated checks (ghost followers, asymmetric relationships, cluster patterns) provide concrete scope definition.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through its specific scope (anomaly detection), but provides no explicit guidance on when to choose this over siblings like wot_sybil_check, wot_follow_quality, or wot_network_health. No 'when not to use' or alternative recommendations are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wot_predict_linkA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, description carries full burden. Provides excellent methodological transparency listing the 5 specific topology signals used (Common Neighbors, Adamic-Adar, etc.), but misses operational behaviors: the payment/freemium model implied by the payment_hash parameter, rate limits, and what the prediction output format looks like (probability score, range, confidence).

  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?

  Two efficient sentences: first states purpose, second discloses methodology. No redundancy, front-loaded with the prediction task, and every word earns its place including the specific algorithm inventory.

  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 description (important since no output schema exists) - should specify if returns probability 0-1, confidence score, or structured analysis. Also omits payment tier behavior despite payment_hash parameter suggesting rate limiting. However, the 5-signal methodology disclosure provides substantial context for an ML/statistical tool.

  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% ('Source Nostr pubkey in hex', 'Target Nostr pubkey in hex', 'Payment hash if free tier exhausted'), so baseline 3 applies. Description adds no parameter-specific context, but schema is self-documenting. The mention of 'Nostr pubkeys' in the description aligns with but doesn't expand on 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?

  Clear specific verb 'Predict' with explicit resource 'how likely two Nostr pubkeys are to connect'. Distinguishes from siblings like wot_trust_path (which finds actual paths) and wot_score (which scores individual nodes) by specifying this is for probabilistic link prediction between specific pairs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Implies usage context through the mention of '5 topology signals' suggesting algorithmic link prediction, but lacks explicit when-to-use guidance versus alternatives (e.g., when to use this vs wot_trust_path or wot_anomalies). No mention of prerequisites like payment requirements.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wot_follow_qualityA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, so description carries full disclosure burden. Lists specific return values (quality score, ghost follower ratio, diversity entropy, suggestions) which helps understand output behavior. However, omits operational details: rate limits, cost implications of 'free tier,' or whether analysis is cached/real-time.

  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?

  Two efficient sentences with zero waste. Front-loaded with action verb, follows with return value documentation. Every word earns its place.

  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?

  Good coverage given no output schema: enumerates four specific return metrics (quality score, ghost follower ratio, diversity entropy, suggestions). Would benefit from brief explanation of 'ghost follower' concept or payment model details, but adequately complete for tool selection.

  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 clear descriptions ('Nostr public key in hex format', 'Payment hash if free tier exhausted'). Description adds functional context about analyzing follow lists but doesn't supplement parameter syntax or validation rules beyond 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?

  Specific verb 'Analyze' + resource 'Nostr pubkey's follow list' + scope 'quality'. Clearly distinguishes from siblings like wot_score (general scoring), wot_sybil_check (sybil detection), and wot_influence (influence metrics) by focusing specifically on follow list quality.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Implies usage through specificity ('follow list quality' vs other WoT metrics), but lacks explicit guidance on when to choose this over wot_score or wot_anomalies. No mention of prerequisites or conditions beyond the payment_hash hint.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wot_influenceA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses simulation nature (safe, read-only) and algorithm (PageRank) which is crucial given no annotations. However, fails to mention the free tier/payment constraint indicated by the payment_hash parameter schema, leaving a gap in behavioral disclosure since annotations are absent.

  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?

  Two sentences with zero waste. First sentence establishes the core simulation scenario; second sentence establishes the analytical method and scope. Every word earns its place.

  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?

  Adequate given 100% input schema coverage, but gaps remain: no output schema exists yet the description only vaguely hints at output ('Shows ripple effect') without indicating return format (scores, rankings, probabilities). Also omits the payment/free tier constraint.

  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 (baseline 3), the description adds value by binding parameters into a narrative: 'one pubkey follows/unfollows another' contextualizes how pubkey, other, and action relate semantically. This exceeds the isolated parameter descriptions in 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?

  Excellent clarity: specifies 'Simulate' as the action, the resource (network effects of follow/unfollow), the scope (ripple effect across network), and methodology (differential PageRank). Distinguishes from siblings like wot_predict_link and wot_score by focusing on hypothetical scenario modeling rather than prediction or current-state scoring.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The term 'Simulate' implies hypothetical usage (previewing before actual action), but lacks explicit when-to-use guidance versus similar siblings like wot_predict_link or wot_follow_quality. No explicit alternatives or exclusions are named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wot_scoreA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, so description carries full burden. Discloses rate limiting (50/day), payment requirement (L402/Lightning), and return structure (score, rank, percentile, followers). Could add detail on error behavior when limit exceeded.

  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?

  Two densely packed sentences with zero waste. Front-loaded with core purpose and algorithm, followed by constraints and returns. Every clause delivers unique information (algorithm type, range, return fields, rate limits, payment protocol).

  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, but description compensates by enumerating return values (score, rank, percentile, followers). Covers authentication/rate limits (L402). Given 2 simple parameters and 100% schema coverage, the description provides sufficient context for invocation decisions.

  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 contextualizing payment_hash through rate limit note ('50 free...then L402') and implicitly explaining the pubkey purpose via 'Nostr pubkey' reference. Does not merely repeat schema descriptions.

  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?

  Specific verb 'Look up' + resource 'Web of Trust score' with algorithm specificity 'PageRank-based' (0-100). Distinguishes from siblings like wot_follow_quality or wot_trust_path by specifying the scoring methodology. Lists return values to clarify scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit rate limit guidance ('50 free requests/day') and payment mechanism ('then L402'), which is crucial usage context. However, lacks explicit comparison to sibling wot_* tools or guidance on when to choose this over wot_influence or wot_follow_quality.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wot_network_healthA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, so description carries full burden. It discloses return structure by listing specific metrics, compensating somewhat for missing output schema, but omits rate limits, caching behavior, or freemium authentication details beyond the parameter description.

  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?

  Two highly efficient sentences with zero waste, front-loaded with verb and resource. Every word earns its place, including the parenthetical list of metrics and the sibling-differentiating final clause.

  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?

  Adequate for a read-only aggregation tool; compensates for missing output schema by enumerating return metrics and distinguishes from siblings. Could benefit from explicit read-only declaration or rate limiting notes given complete absence of 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?

  Schema coverage is 100% (payment_hash fully described in schema), establishing baseline 3. The description focuses entirely on output metrics and adds no parameter-specific guidance beyond what the schema provides.

  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 'Get' and resource 'Nostr network health metrics' with exact output enumeration (node count, Gini coefficient, etc.). 'No pubkey needed' explicitly distinguishes this aggregate tool from individual-focused siblings like wot_score or wot_sybil_check.

  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 phrase 'No pubkey needed' provides clear contextual guidance distinguishing this global network tool from pubkey-specific siblings, though it lacks explicit 'when not to use' statements or named alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wot_sybil_checkA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Without annotations, the description carries significant burden and delivers: it discloses the 5 specific analysis dimensions and the 4 possible classification outputs (filling the gap of no output schema). However, it omits discussion of the payment/free tier model implied by the payment_hash parameter.

  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?

  Two efficient sentences with zero waste. First sentence establishes the operation and target; second sentence details the methodology and return values. Information density is optimal.

  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 2-parameter tool with no output schema, the description adequately compensates by enumerating the classification return values. It explains what the analysis entails (5 signals) but could strengthen completeness by noting the optional payment requirement when free tier is exhausted.

  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% (both pubkey and payment_hash have descriptions), establishing baseline 3. The description adds no additional parameter semantics beyond what the schema already provides, but none is needed given complete schema coverage.

  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 clarity with specific verb 'Run', resource 'Nostr pubkey', and distinct scope '5-signal Sybil detection'. The five specific signals listed (follower quality, mutual trust ratio, etc.) clearly differentiate this from siblings like wot_follow_quality or wot_score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides implied usage through the Sybil detection focus and classification outputs, but lacks explicit guidance on when to choose this over wot_anomalies or wot_score. No explicit when-not or alternative recommendations provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wot_trust_pathA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses output format (hop-by-hop with trust scores) which compensates for missing output schema. However, lacks disclosure of free tier constraints (only mentioned in schema parameter), error behavior when no path exists, or side effects. No annotations provided to contradict.

  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?

  Three sentences each earning their place: (1) core action, (2) output format, (3) use case. No redundancy or boilerplate. Perfectly front-loaded with action verb.

  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 no output schema, description adequately describes return structure (hop-by-hop with scores). All 3 parameters documented (100% schema coverage). Minor gap: doesn't explain 'no path found' behavior or free tier limits beyond schema parameter hint.

  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% coverage with clear descriptions ('Source Nostr pubkey', 'Target Nostr pubkey'). Description mentions 'two Nostr pubkeys' aligning with required params, but adds no syntax/format details beyond well-documented schema. Baseline 3 appropriate for high-coverage 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?

  Specific verb 'Find' + resource 'trust path' + domain 'Nostr pubkeys' clearly establishes scope. Distinguishes from siblings like wot_score (returns aggregate score) and wot_trust_circle (returns clusters) by specifying 'path between two' pubkeys.

  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?

  Clear use case provided: answering 'how am I connected to this person?' Guides agent toward path-discovery queries between specific entities. Missing explicit alternatives (e.g., 'use wot_score for single-user ratings') but provides strong positive guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ask_bitcoinA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, but description carries the burden well by disclosing: AI model (Llama 3.3 70B), cost (21 sats), and payment mechanism (Lightning L402). Critical behavioral info for a paid tool. Does not disclose output format or error handling.

  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?

  Two front-loaded sentences with zero waste: purpose first, implementation details second. Every word earns its place. No redundancy with schema or name.

  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?

  Adequate for a 2-parameter Q&A tool with 100% schema coverage. Critical omission would be payment details, which are included. Only minor gap is lack of output format description (though 'ask' implies text response).

  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%, but description adds crucial context for 'payment_hash' by explaining the L402 payment flow and cost ('21 sats via Lightning L402'), giving semantic meaning to why the parameter exists beyond the schema's technical definition.

  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 verb ('Ask') + specific resources ('Bitcoin, Lightning Network, or cryptocurrency'). Distinct from Web of Trust siblings (wot_*) and generate_image through explicit domain scoping in first sentence.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Defines the domain (Bitcoin/crypto questions) providing implicit usage guidance, but lacks explicit when-to-use vs alternatives (e.g., doesn't clarify when to use this vs querying WOT data directly). No exclusion criteria or prerequisites mentioned beyond payment.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• generate_imageA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, so description carries full burden. Successfully discloses cost model (100 sats), payment protocol (Lightning L402), and specific AI model used. Missing output format details (returned as URL? binary?) but covers financial/operational traits well.

  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?

  Two tightly-worded sentences. Front-loaded with action ('Generate an image'). Zero redundancy—every element (model name, cost, payment method) is essential operational information.

  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 payment complexity and lack of output schema, description adequately covers the unique operational requirements (L402 payment, 100 sats cost, retry mechanism via payment_hash). Minor gap: doesn't specify return value format (JPEG, URL, etc.).

  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 (both prompt and payment_hash documented in schema). Description adds general context ('text prompt') but doesn't extend parameter semantics beyond what the schema already provides. Baseline 3 appropriate for high-coverage schemas.

  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 (Generate) + resource (image) + specific model (FLUX.1 Schnell 12B). Completely distinguishes from Bitcoin/WoT siblings (ask_bitcoin, wot_* tools) by being the sole image generation tool in the set.

  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?

  Discloses critical operational constraint: 'Costs 100 sats via Lightning L402' informs the agent this is a paid operation. The payment_hash parameter schema (referenced in context) indicates retry capability, though explicit 'when not to use' alternatives aren't listed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wot_trust_circleA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations or output schema, the description carries the full burden: it discloses the output structure ('Returns members with roles, cohesion, and density metrics') and implicitly reveals payment behavior by referencing the payment_hash parameter's purpose for when 'free tier [is] exhausted'.

  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?

  Two tightly constructed sentences with zero waste: the first establishes operation and scope, while the second describes output structure, making it appropriately front-loaded and concise.

  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 absence of annotations and output schema, the description adequately compensates by detailing return values (members, roles, cohesion, density metrics) and payment behavior, though explicitly noting the read-only nature would provide additional context.

  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 description coverage (baseline 3), the description adds value beyond the schema by contextualizing the pubkey as the target of the trust circle analysis and clarifying the payment_hash's role in tier management.

  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 phrase 'Get a pubkey's trust circle' provides a specific verb and resource, while the parenthetical '(mutual follows with trust strength)' distinguishes this tool from siblings like wot_follow_quality or wot_trust_path by defining the specific trust mechanics involved.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  While it lacks explicit 'when-to-use' directives against alternatives, the parenthetical clarification '(mutual follows with trust strength)' provides implied usage context that distinguishes it from path-finding or follow-quality analysis, though explicit guidance would be stronger.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.