excalibur-mcp

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

No annotations provided, so description carries full burden. Explains free operation, authentication requirement (dpop_token), and security measure to prevent scraping. Describes token format and constraints (e.g., nonce recommended, time window).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear purpose first, then details, then argument specifications. Slightly verbose but each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, but description still enumerates returned data types. Mentions what is not included (Authority tax balance). Additional context like 'Free' and authentication helps agent decide.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description adds full meaning: npub is Nostr public key, dpop_token is a kind-27235 event with specific requirements (not base64, must contain tool name, within 60s, etc.), days defaults to 30.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States 'Generate a patron's account statement at this operator' and lists returned data (purchase history, credit tranches, usage breakdown, daily logs). Distinguishes from sibling 'excalibur_check_balance' and clarifies it is not the Authority tax balance.

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

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

Clearly states it's free, requires proof of npub ownership via dpop_token, and warns against statement-scraping. However, does not explicitly compare to alternative tools for similar tasks.

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

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

With no annotations, the description carries full burden. It discloses cost (1 api_sat), verification mechanism (debited_or_deny), and detailed dpop_token requirements. It does not mention side effects, but as a read-like operation, this is acceptable. Provides good transparency on security and cost.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a clear one-liner, then what the infographic contains, then cost/verification, then parameter details. It is slightly lengthy but each sentence adds value. Good front-loading of key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and an output schema exists, the description is fairly complete. It covers purpose, all parameters with details, cost, and verification. It could mention error handling or output format (SVG) but is sufficient for an agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description adds significant meaning: npub format (npub1...), dpop_token detailed constraints (raw JSON, kind-27235, time limit, tags), and days defaults to 30. This goes well beyond the schema's bare definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Generate a visual SVG infographic of your account statement' with a specific verb and resource. It distinguishes from sibling excalibur_account_statement by noting it returns the same data rendered as an SVG graphic with specific components.

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

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

The description provides detailed guidelines for the dpop_token parameter, including format and constraints. It mentions cost (1 api_sat) and verification process. While it doesn't explicitly compare with alternatives, the distinction from account_statement is clear. No explicit when-not-to-use but sufficient context.

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

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

Given no annotations, the description must disclose behavior. It mentions 'free' and 'polls the Authority MCP-to-MCP' and lists possible statuses (pending/approved/rejected/provisioned). However, it does not discuss idempotency, permissions, or whether the operation is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences and a bullet list. The main purpose is front-loaded. However, it could be slightly more structured by adding parameter explanations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema and only 2 parameters, the description lacks essential context: no parameter descriptions, no authentication requirements, no explanation of the polling behavior or expected response format. The tool's purpose is clear but incomplete for reliable agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema parameter coverage is 0%, and the description does not explain any parameters. 'authority_npub' is implied by 'chosen Authority' but not explicitly described, and 'dpop_token' is entirely omitted. This is a critical gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'check', the resource 'operator's adoption-request status', and the scope 'at a chosen Authority'. It distinguishes from siblings like excalibur_request_adoption and excalibur_get_operator_onboarding_status.

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

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

The description implies usage (checking adoption status) but does not provide explicit when-to-use or when-not-to-use guidance, nor mentions alternatives among the many sibling tools.

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

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

Without annotations, the description discloses important behavioral traits: it is free, requires proof of npub to prevent DOS, and implies idempotency. Does not detail rate limits or exact side effects, but covers the core safety aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is front-loaded with core action and contains well-structured parameter explanations. Although somewhat verbose, every sentence adds value and clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description covers all essential aspects: purpose, usage guidelines, parameter semantics, and behavioral transparency. Relates well to sibling tools in the OAuth flow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides detailed semantics for both parameters: 'npub' is a patron npub, and 'dpop_token' is a raw kind-27235 Nostr event JSON with specific formatting constraints (not base64, not NIP-98).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Start the OAuth2 authorization flow' with verb+resource, explains it returns an authorization URL, and distinguishes from sibling 'check_oauth_status' by mentioning the completion step.

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

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

Explicitly instructs 'Do NOT call this pre-emptively' and specifies when to use: only when a live tool fails with 'upstream_auth_refresh_needed'. Provides exclusion context about pending check_oauth_status not indicating session lapse.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a critical behavioral trait: when the balance reaches zero, patron top-ups cannot be certified and the operator must call purchase_credits. It also notes the operation is free. However, it does not explicitly state that it is read-only, though the verb 'check' implies it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of four sentences, each adding essential information. The first sentence states the high-level purpose, the second describes the return value, the third explains the consequence of a zero balance, and the fourth clarifies ownership. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema exists, the description provides sufficient context: it explains the return value (sats available), the significance of the balance, and the next step if zero. It could marginally improve by explicitly stating it is a read-only operation, but overall it is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the baseline is 4. The description does not need to add parameter information since none exist. It correctly avoids mentioning parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks the operator's tax balance at the Authority, specifying it returns sats available for certifying patron credit purchases. It distinguishes itself from sibling tools like excalibur_check_balance by explicitly noting this is the operator's own funding, not a patron balance.

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

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

The description explains when to use this tool: to check sats available for patron credit certification. It also provides guidance on what to do when the balance reaches zero (call purchase_credits). However, it does not explicitly mention when not to use it or provide alternatives, leaving some room for improvement.

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

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

No annotations exist, so description carries full burden. It discloses that the tool is free (no credits required) and requires a Proof-of-Possession token to prevent enumeration. However, it does not explicitly state that the tool is read-only or has no side effects, missing a chance to clarify safety.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with an intro, key notes, and parameter details. It is front-loaded with purpose and usage guidance. However, the dpop_token explanation is quite lengthy; while necessary, it could be slightly condensed without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, output schema provided), the description covers purpose, cost, authentication requirement, parameter details, and differentiation from a sibling. The presence of an output schema reduces the need to describe return values, so the description is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides no descriptions (0% coverage), but the description fully explains both parameters: npub as the Nostr public key whose balance to check, and dpop_token in detail (raw JSON of a specific Nostr event, constraints on 'u' tag, content, created_at, nonce). This adds essential meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it checks a patron's credit balance at the operator, specifies it's the spending balance, and distinguishes from authority_check_balance. The verb 'check' and resource 'balance' are precise, and the description differentiates from siblings like 'excalibur_check_authority_balance'.

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

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

Explicitly says when to use this tool (check patron balance) and when not to (use authority_check_balance for operator's own balance). Also mentions the prerequisite of proof of npub ownership to prevent unauthorized enumeration, providing clear context for usage.

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

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

Transparent about the scope: reports only this authorization attempt, not existing session validity. Details proof of npub ownership requirement and exact dpop_token format. Minor lack of idempotency mention.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with front-loaded purpose, then usage context, then parameter details. Each sentence adds value without redundancy. Appropriate length for a technical auth tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, description doesn't need to document return values. It covers the overall flow, edge cases, and error handling. Provides complete context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description fully compensates: explains npub as same one used in begin_oauth, and provides detailed, precise instructions for constructing dpop_token including tags, content, and time constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it checks OAuth2 authorization flow completion. It distinguishes from siblings like begin_oauth and session_status by specifying the exact purpose and relation.

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

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

Explicitly states when to call: after authorization URL from begin_oauth and login. Also clarifies when not to interpret 'pending' as session lapse, and recommends fallback to begin_oauth only on specific error.

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

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

No annotations provided, so description carries full burden. It details auth requirements and token construction but does not explicitly confirm read-only behavior or mention any side effects. Output schema exists but is not described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and usage context, then detailed args. Slightly lengthy but every sentence adds value. Could be more concise, but structure is good.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers flow, auth requirements, and parameter sources. Does not explain output format, but output schema exists. For a payment status check with complex auth, it is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% coverage, so description fully explains each parameter: invoice_id from purchase_credits, npub as Nostr public key, dpop_token with detailed construction instructions, compensating for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Check the payment status of a Lightning invoice' and specifies that it should be called after paying the invoice from purchase_credits, which distinguishes it from siblings.

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

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

Explicitly states 'Call after paying the invoice from purchase_credits' and that it is free with no credits required, providing clear usage context. Could be improved by explicitly stating when not to use it, but current guidance is strong.

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

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 the tool is free, requires no credits, and previews cost including constraint effects. It does not mention side effects, but the read-only nature is implied. Additional context on any destructive effects would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two clear paragraphs plus an Args section. It is well-structured, front-loads the main purpose, and 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the main purpose and key parameters, but misses documenting npub and dpop_token. With 4 parameters and an output schema, the description should cover all parameters for completeness. The missing parameter documentation is a gap given the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the two key parameters (tool_id and tool_kwargs) with examples and usage details, covering 50% of the 4 parameters. However, the schema has 0% coverage, and the parameters npub and dpop_token are not described. The description adds value beyond the schema but is incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool previews the effective cost of a tool call, specifying it shows base cost and constraint effects (discounts, free trials, surge pricing). The name 'excalibur_check_price' and description uniquely identify its purpose among many sibling tools.

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

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

The description explains when to use the tool (to preview cost) and mentions it is free with no credits required. It does not explicitly state when not to use or list alternatives, but the context of siblings with distinct names makes the usage clear.

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

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

With no annotations, the description carries full burden. It states 'Free, no side effects — does not evict the cache or touch relays', clearly indicating read-only, safe behavior. However, it does not specify what happens if the token is not found or expired, which is minor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, starting with a direct purpose sentence, then adding contextual comparison, usage guidance, side effects, and parameter details. No superfluous information; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema, so return values do not need to be described. The description covers purpose, usage context, side effects, and parameters. It is complete for a check tool, though it could mention the result when the token is expired.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must compensate. The Args section explains both parameters (patron_npub and dpop_token) meaningfully, referencing related tools. However, the description marks them as 'Required' while the schema has defaults and no required constraint, creating a slight inconsistency.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Check' and the resource 'whether a previously-cached dpop_token is still valid'. It distinguishes itself from the sibling 'excalibur_check_oauth_status' by noting it mirrors that tool for the npub-proof flow.

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

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

The description provides explicit context: agents can use it before a paid call to avoid wasting credits on a guaranteed failure. It differentiates from check_oauth_status, but does not explicitly state when not to use it or list alternatives.

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

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

No annotations are provided, so the description must carry the full burden. It explains idempotency via client_req_id and return of post_id. However, it omits side effects like credit charges, authentication requirements, or error handling. Some behavioral info is present but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-organized, with a clear opening sentence and bullet-like parameter explanations. It front-loads the purpose and is mostly concise, though some redundancy exists. Overall, it is effectively structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, nested objects), the description is quite thorough, covering key parameters and providing examples. An output schema exists, so return details are not required. However, it could mention prerequisites or error cases for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 9%, but the description provides extensive detail for most parameters (doc, text_cache, publish_at, recurrence, etc.), including format and examples. Not all parameters are covered (e.g., tweet_url, dpop_token), but the major ones are well explained, compensating for low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Store a new post (draft or scheduled). Returns its post_id.' This specifies the verb (store), resource (post), and distinguishes between draft and scheduled. It also differentiates from sibling tools like excalibur_update_post and excalibur_delete_post.

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

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

The description does not explicitly provide when to use or alternative tools. While the purpose is clear, there is no guidance such as 'use this to create a new post; for updates use excalibur_update_post.' An agent can infer usage but lacks explicit context.

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

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

The description fully discloses the cascading deletion to patron redemptions, the no-op behavior for chain steps referencing the deleted coupon, and the operator restriction. With no annotations provided, this transparency is critical and well-executed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of three short sentences. It front-loads the main action and uses additional sentences to add necessary behavioral and access context without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core functionality, side effects, and access restrictions. An output schema exists (per context signals), so return values are not needed. Minor omissions like error handling or prerequisites are acceptable given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not mention or explain the two parameters (coupon_id and dpop_token) despite 0% schema coverage. The meaning of coupon_id is implicit from the tool name, but dpop_token remains unexplained, leaving the agent with insufficient guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a coupon' with a specific verb and resource, distinguishing it from other coupon tools like excalibur_mint_coupon, excalibur_list_coupons, and excalibur_update_coupon. The mention of cascading behavior and operator restriction further clarifies the tool's unique role.

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

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

The description indicates the tool is restricted to operators, providing some usage context. However, it does not explicitly compare with similar siblings like excalibur_forget_coupon or state when to use this tool over alternatives, leaving some ambiguity.

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

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

With no annotations, the description carries full burden. It discloses that this is a write operation to a sensitive credential vault, requires ownership proof via a detailed dpop_token format, and that it removes only one field without affecting others. This adds significant context beyond the name and schema, though it omits potential side effects or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a clear header, a brief summary paragraph, and an Args list. The essential information is front-loaded. The dpop_token description is lengthy but necessary given its complexity. No wasted sentences, though could be slightly more compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only 3 parameters and an output schema exists, the description covers the core functionality, authentication, and parameter details. It explains the cost ('Free') and scope. It does not describe error cases or behavior when field doesn't exist, but for a deletion tool the description is quite complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates well. It explains each parameter: npub is a Nostr public key, dpop_token is a Raw JSON with specific constraints (kind-27235, u tag, timing, etc.), and field is the credential field name. The dpop_token details are especially helpful. Minor improvement could list valid field values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Remove a single patron credential field' and 'Deletes one field from stored credentials without affecting other fields.' This provides a specific verb-resource action, but does not explicitly differentiate from siblings like update or forget credentials, which reduces clarity slightly.

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

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

No explicit guidance on when to use this tool versus alternatives such as excalibur_update_patron_credential or excalibur_forget_credentials. The description mentions 'Proof of npub ownership is required' and that it's a write operation, but does not advise on selection criteria or contraindications.

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

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

No annotations provided, so description carries full burden. It discloses the core behavioral difference between soft and hard delete, but lacks details on reversibility, authentication requirements, or cascading effects. Adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, second sentence explains the key parameter. No unnecessary words. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the availability of an output schema, return values are covered. However, the description omits authentication context (despite 'npub' and 'dpop_token' parameters) and prerequisites. For a delete tool, this is a moderate gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 25% schema description coverage, the description is needed to explain parameters. It explains 'hard' well but does not describe 'npub', 'dpop_token', or 'post_id' beyond implication. Insufficient compensation for low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (delete), the resource (stored post), and distinguishes between soft and hard deletion. It differentiates from sibling tools like excalibur_delete_coupon or excalibur_delete_snippet by specifying the resource.

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

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

The description explains when to use hard vs soft delete with the 'hard' parameter, but does not provide guidance on prerequisites (e.g., ownership, authentication) or alternatives (e.g., update tool). No explicit when-not-to-use info.

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

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

With no annotations, the description must disclose behavioral traits. It states the destructive nature ('Delete') and owner-scoping, but omits crucial details: whether deletion is irreversible, any side effects, permission requirements beyond npub, or error handling. The lack of annotation support makes this description insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, front-loading the action and ownership. However, it may be too brief, omitting important behavioral and parameter details. Every sentence earns its place, but more could be added without verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description does not explain what the tool returns (e.g., success message, deleted snippet). It lacks constraints, idempotency, and error scenarios. Given the simplicity of a delete operation, the description is incomplete for reliable agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33% (only npub has a description). The tool description does not add meaning to the snippet_id parameter beyond 'by id', nor does it clarify format or constraints. Since coverage is low, the description should compensate but fails to do so.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (delete) and the resource (saved snippets by id). The phrase 'Free and owner-scoped' further specifies who can use it and at what cost. This distinguishes it from sibling tools like excalibur_save_snippet and excalibur_get_snippet.

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

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

The description implies usage for deleting one's own snippets ('owner-scoped'), but does not explicitly state when to use this tool versus alternatives. No 'when not to use' or direct comparisons to siblings are provided, leaving the agent to infer appropriateness.

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

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

Since no annotations are provided, the description carries full burden. It discloses polling behavior, status transitions, owner-scoping, and watchdog re-kick of stalled jobs. It lacks mention of rate limits or potential side effects but covers key behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a short, well-structured paragraph that front-loads the primary purpose and then details statuses and behavior. Every sentence adds value, with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With output schema present, the description covers polling protocol, status meanings, and watchdog behavior. It is nearly complete for a polling tool, though it omits details like maximum poll intervals or timeouts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (npub only). The description adds context for claim_check by linking it to resolve_dynamic_block, but does not explain npub or dpop_token beyond schema descriptions. It provides some added value but not full compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: redeeming a claim check from resolve_dynamic_block. It specifies it is free and proof-gated, and explicitly contrasts with the initial resolve_dynamic_block call, distinguishing it from siblings.

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

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

The description provides clear when-to-use guidance: poll with the claim_check until status is 'done'. It outlines different response statuses and mentions owner-scoping and watchdog behavior. It does not explicitly state 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.

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

With no annotations, the description takes on full burden. It discloses key traits: cosmetic-only effect, re-redeemability, and authentication requirement. This goes beyond a simple action statement, though it omits idempotency or error handling details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff. The most critical information (what it does, cosmetic nature, requirement) is front-loaded. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema (handling return values), the description covers the effect and prerequisite for a simple mutation. It lacks mention of edge cases (e.g., coupon not in list) but is sufficient for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must explain parameters. It only mentions npub as 'proof', ignoring coupon_id and dpop_token. This leaves significant gaps in understanding parameter purpose, especially for dpop_token.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Remove a coupon from this patron's redemption list') and specifies the resource and scope. It distinguishes itself from sibling tools like delete_coupon by emphasizing the cosmetic nature and that the coupon still exists.

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

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

The description provides context ('cosmetic only', 'requires proof of npub') but does not explicitly guide when to use this tool versus alternatives like delete_coupon or redeem_coupon. The usage is implied, not explicit.

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

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

With no annotations, the description carries full burden. It explicitly states that deletion is "as destructive as a write" and requires proof of npub ownership. It also details the dpop_token format requirements, adding transparency beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose and uses a clear structure. However, the dpop_token explanation is quite lengthy and could be condensed. Given the necessity due to schema lack, it remains reasonably concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers authentication, parameter details, and usage hints. An output schema exists, so return values are likely covered there. It does not explicitly mention success/failure behavior or error handling, but the destructive hint mitigates that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description compensates fully. It explains each parameter: service (credential service), npub (Nostr public key), and dpop_token (raw JSON event with specific constraints on time, tags, and format), providing critical meaning absent from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with "Delete vaulted credentials for a specific service and npub." clearly specifying the verb (delete) and resource (vaulted credentials). The unique resource and action distinguish it from siblings like excalibur_delete_patron_credential or excalibur_delete_post.

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

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

The description provides context for which npub to use (operator vs. patron) and emphasizes the need for proof of ownership. However, it does not explicitly state when to use this tool versus other deletion tools or mention any exclusions.

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

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

With no annotations, the description carries the full burden. It discloses the read-only nature, public data source, and return fields including empty profile case. However, it does not explain handling of default empty npub or potential errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with two sentences, front-loaded with the main purpose, and every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple one-parameter tool with output schema, the description sufficiently covers what the tool does and returns. It lacks error information but is adequate for a straightforward read operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must add context. It explains npub is a Nostr public key, but doesn't clarify the default empty value or expected format. More detail on the parameter's role would be helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads a public Nostr profile for a given npub, specifies NIP-01 kind-0 metadata, and distinguishes from sibling write tools like excalibur_publish_nostr_profile and other read tools like excalibur_get_x_profile.

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

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

The description mentions that the tool is free and requires no proof, but does not explicitly state when to use it versus alternatives or exclude cases. The differentiation from siblings is implicit through naming and context.

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

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

With no annotations, the description carries the burden. It states the tool generates a proof (implying read-only), but does not explicitly confirm no side effects or disclose any behavioral traits like idempotency or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the main purpose. The Args section adds clarity but could be integrated. No wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return format details are not needed. The description covers the tool's purpose and required parameters adequately. However, it could mention that the proof is used for verification purposes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds meaningful explanations for both parameters: 'notarization_id' is the record ID, 'npub' is the patron's Nostr public key with format hint. This goes beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Generate a Merkle inclusion proof that a patron's balance was included in a Bitcoin-notarized snapshot.' This is a specific verb+resource combination, distinguishing it from sibling tools like excalibur_list_notarizations or excalibur_notarize_ledger.

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

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

There is no explicit guidance on when to use this tool versus alternatives (e.g., excalibur_check_proof_status, excalibur_receive_npub_proof). No prerequisites or context for invocation are provided.

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

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

Although no annotations are provided, the description discloses the tool's behavior: it shows which settings are configured/missing and how to deliver missing values. This adds context beyond the name, but does not explicitly state whether it is read-only or any other traits. Given its simple nature, it is fairly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences: first states purpose, second details output, third gives alternative. No fluff, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and the existence of an output schema, the description sufficiently explains what the tool does and what it returns (configured/missing settings and delivery guidance). It is complete for a status tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is 100%. The description does not need to add parameter meaning, and the baseline of 3 is appropriate as no additional insight is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'reports configuration readiness' for the operator, specifying verb+resource. It distinguishes itself from the sibling tool 'get_patron_onboarding_status' by noting the different scope (operator vs. patron-level).

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

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

The description explicitly tells when to use this tool (for operator configuration readiness) and when not (for patron-level credential status, directing to 'get_patron_onboarding_status'). This provides clear guidance on alternatives.

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

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

With no annotations, the description carries full responsibility. It transparently states that values are never exposed, the list itself is sensitive, and provides detailed authentication requirements and timestamp behavior. This covers key behavioral aspects 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose and structured into paragraphs with an 'Args:' section. It is not overly verbose, but the dpop_token explanation could be slightly more concise. Overall, it is well-organized and each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (auth requirements, sensitivity) and the presence of an output schema (context signals: true), the description is complete. It explains what is returned (field names and timestamps) and the security implications, leaving no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates by defining npub as the patron's Nostr public key and providing extensive detail on dpop_token: raw JSON of a kind-27235 event with constraints on tags, content, created_at, and nonce. This adds critical meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists patron credential field names, not values, using the verb 'List' and specifying the resource. It distinguishes from sibling tools like excalibur_delete_patron_credential by focusing on reading field names only.

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

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

The description provides context for when to use the tool (to verify configured fields and their age) and prerequisites (proof of npub ownership). It does not explicitly exclude alternatives, but the purpose is clear enough that an agent can infer when to use this vs. other credential tools.

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

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 credential presence is sensitive, requires proof of ownership, and is free. It also explains behavior for different service types. Could mention if it is read-only or has no side effects, but overall good transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a purpose paragraph followed by parameter definitions. It is not overly verbose but contains necessary details. Could be slightly tighter, but overall concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the parameter count of 2 and presence of an output schema, the description covers the tool's purpose, prerequisites, and parameter semantics adequately. It explains the two service types and the sensitive nature. Doesn't describe return values, but that is acceptable due to output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain parameters. It does so in the Args section, defining patron_npub as the Nostr public key and dpop_token as a signed event. This adds meaning beyond the schema's type-only definitions, helping the agent understand the inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the purpose: 'Report a patron's credential readiness for this operator.' It distinguishes between set-once and dynamic/OAuth2 services and explains what is shown for each, making it specific and differentiating from siblings like excalibur_get_operator_onboarding_status.

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

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

The description provides context on when to use the tool, including that proof of npub ownership is required. However, it does not explicitly mention alternatives or when not to use this tool, so it lacks explicit usage boundaries. Still, the context is clear.

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

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 does not disclose whether the operation is read-only, safe, or idempotent. Error conditions (e.g., post not found) and authorization requirements beyond 'owner-scoped' 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. However, it could benefit from brevity-relevant details (e.g., auth hint) without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema, return format is covered, but the description lacks usage guidance, behavioral disclosure, and parameter elaboration. The tool is simple, yet the description feels incomplete for an AI agent to invoke correctly in all contexts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (npub documented). The description adds no semantics for post_id or dpop_token beyond implying post_id is the identifier. The phrase 'by id' does not clarify format or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Read one stored post by id (owner-scoped)' clearly states the action (Read), the resource (stored post), and the scope (by id, owner-scoped). It distinguishes from sibling tools like list_posts (multiple posts) and create/delete (write operations).

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

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

No explicit guidance on when to use this tool versus alternatives. The phrase 'owner-scoped' hints at access restrictions, but does not state when to choose get_post over list_posts, nor any prerequisites or limitations.

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

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

With no annotations, the description carries the burden. It discloses that data is append-only, ordered by capture time, and empty if not yet harvested. This is strong behavioral context, though it skips auth details (but 'Patron' implies ownership).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: three sentences that front-load the purpose and add only essential behavioral details. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description doesn't need to detail return shape. It adds ordering, emptiness semantics, and ownership, providing enough context for a simple read-only getter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67%, and the description adds no parameter details. The post_id is well-described in schema, but dpop_token is undocumented in both schema and description, leaving a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns an append-only snapshot series for one owned post, listing specific fields and ordering. This specific verb+resource+scope distinguishes it from siblings like post_performance.

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

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

It provides clear context: use for raw metric snapshots of one owned post, and notes that an empty result means the post hasn't been harvested yet. It doesn't explicitly name alternatives, but the context is unambiguous.

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

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

Despite no annotations, the description fully discloses key behavioral traits: it is free, self-initializes a scaffold if no model exists, and explicitly states 'No economic data from code.' This is comprehensive for a getter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. First sentence states purpose, second clarifies a special case. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and existence of an output schema, the description covers the essential behavioral aspects (initialization, cost, data source). No further info needed for a low-complexity tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. The description does not add parameter info beyond the schema, but the baseline for zero-parameter tools is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Get the active pricing model for this operator', which is a specific verb-noun combination. Distinguishes from sibling tools like set_pricing_model and reset_pricing_model by being the getter operation.

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

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

Implicitly clear when to use: querying the pricing model. Mentions free cost and self-initialization behavior, but does not explicitly state when not to use or list alternatives. However, the description provides enough context.

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

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

With no annotations, the description discloses key behaviors: the tool is owner-scoped, requires npub proof, and returns different data based on user role. It also describes the return structure and auth requirement ('Free; npub proof required'). No contradictory information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded. It explains the tool's purpose, use case, scope rules, and return format. Every sentence adds value, though slightly verbose in places. Overall, it is concise for the amount of information conveyed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is nearly complete for a read tool with three parameters and no output schema. It explains what the tool does, who can use it, what data is returned, and auth requirements. Sibling tool comparison is absent but not critical given the clear purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers two of three parameters with descriptions (npub and limit). The description adds context about how npub determines scope but does not elaborate on dpop_token. Given 67% schema coverage, the description provides marginal additional value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads 'recent scheduler-tick outcomes' from 'process_scheduled_posts' runs, distinguishing it from siblings like excalibur_process_scheduled_posts and excalibur_scheduler_status. It specifies the output is for debugging and shows heartbeat per tick and per-post outcomes.

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

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

The description explains when to use the tool (to debug worker behavior) and what it shows. It lacks explicit when-not-to-use or alternative tools, but the context signals and sibling list provide implicit guidance. The scope differentiation (owner vs other patrons) is clearly stated.

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

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

With no annotations, the description carries full burden. It discloses that the operation is read-only ('Read'), free, and owner-scoped. It also specifies the return format (success with snippet or error) but does not detail potential errors or side effects beyond 'snippet_not_found'. This is reasonably transparent for a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long with no redundancy. It efficiently conveys purpose, scope, and return format. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (indicated) and 3 parameters, the description covers core purpose and return format. However, it lacks parameter details and does not mention sibling tools or alternatives. It is functional but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33%, and the description does not add any extra meaning to the parameters. The snippet_id parameter lacks format details in both schema and description. The npub and dpop_token parameters are not explained beyond the schema defaults. For low coverage, the description should compensate, but it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads a saved snippet by ID, and distinguishes it from sibling tools like excalibur_save_snippet, excalibur_delete_snippet, and excalibur_list_snippets. The verb 'read' and resource 'snippet' are specific, and the scope 'owner-scoped' adds clarity.

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

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

The description mentions 'Free and owner-scoped', implying it should be used by the owner for their own snippets. However, it does not explicitly state when to use this tool versus alternatives like excalibur_list_snippets or excalibur_get_post. No direct exclusions or scenarios are provided.

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

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

With no annotations, the description carries full burden. It discloses that an empty Voice is returned if none saved, that it is owner-scoped, and that pricing applies. It does not detail authentication or error states but covers the key behavioral traits for a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loaded with the core action, and contains no verbose or redundant phrases. Every sentence adds value: purpose, return behavior, and pricing context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema, the description does not need to details return fields but explains the empty case and structure. It covers ownership and pricing adequately. Minor gap: no mention of error scenarios, but acceptable given output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (npub has a description; dpop_token does not). The description does not add meaning for either parameter, missing a chance to explain dpop_token or clarify usage. With moderate coverage, the description should compensate but fails to do so.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads a saved writing Voice, including its components (profile blur and banned chips). It distinguishes from siblings like excalibur_save_voice and mentions owner-scoping and default empty return, making the purpose specific and unambiguous.

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

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

The description provides usage context: owner-scoped and priced via check_price. It implies when to use (when needing to read the Voice) but does not explicitly exclude alternatives or state when not to use it. The guidance is clear but lacks direct comparison with other tools.

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

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 the use of vaulted OAuth token, X API call, and return format including the unconnected state. However, it omits potential issues like token expiration, rate 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: first states purpose, second explains mechanism and return format, third gives concrete use case. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity and presence of output schema (return format explicitly listed), the description covers purpose, input (vaguely), mechanism, output, and use case. It lacks prerequisite guidance (e.g., OAuth must be linked) but is otherwise sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: only `npub` is described as 'Required. Your Nostr public key'. The description does not clarify `dpop_token` at all, leaving it undocumented. The description fails to compensate for the missing parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches the connected X account's handle and name, specifying the resource (X account) and the action (fetch). It distinguishes itself from siblings like excalibur_get_nostr_profile (Nostr profile) and excalibur_check_oauth_status (OAuth status check).

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

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

The description implies usage for tweet-card preview and mentions OAuth token, indicating a prerequisite, but lacks explicit when-not-to-use or alternatives. It does not guide the agent to check OAuth status first or compare with similar tools.

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

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

With no annotations provided, the description carries full responsibility and does so richly. It discloses the tool's draining behavior (mutating job rows), the data loss risk on missed cadence, the retry mechanism (5 attempts), dead-letter queue handling, the ability to requeue via requeue_dead_id, and the OAuth context requirement. These are significant behavioral traits beyond simple operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact but dense: a one-line summary, a detailed operation sentence, a failure-mode sentence, and an integration sentence. Every sentence adds critical information (scope, process, risk, retry, automation context) without fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the presence of an output schema, the description is remarkably complete. It covers the full operational flow, error handling, dead-letter queue, manual requeue option, and integration with process_scheduled_posts. No missing critical context is apparent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67% (npub and requeue_dead_id are described; dpop_token is not). The description adds context for requeue_dead_id as a dead-letter job UUID, but does not clarify dpop_token's purpose. This is above 50% coverage, so baseline 3 applies, with only marginal added value for parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a 'cadence-aware metrics harvest sweep' and details its specific actions: draining due metrics_harvest_job rows, fetching non_public_metrics/organic_metrics under OAuth context, and appending post_metrics_snapshot rows. It distinguishes itself from siblings by noting it runs as phase 3 of process_scheduled_posts, separating it from single-post metric fetchers.

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

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

The description explicitly marks the tool as 'Operator-only' and describes its cadence-aware batch behavior, implying when it should be used (for harvest sweeps) vs. per-post metric retrieval. It also mentions it runs automatically as phase 3 of process_scheduled_posts, giving context on manual vs. automatic usage. However, it does not explicitly list alternative tools or exclusion criteria.

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

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

Despite no annotations being provided, the description fully discloses behavior: it notes 'Free, no side effects,' explains that renamed functions change mcp_name but keep tool_id, and details the registered:false/unregistered semantics for deployment drift detection. It even references issue numbers (#174, #175) for context. This is rich behavioral disclosure that carries the entire burden absent annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear paragraphs covering purpose, consumers, canonical-UUID design, and wire-surface diffing, ending with 'Free, no side effects.' It's slightly verbose with some redundancy ('flag deploy drift' appears twice, the canonical-UUID point is reiterated), but each sentence earns its place and there's no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with an output schema present, the description is thorough. It explains the return structure (registered flags, unregistered array), the semantics of tool_id stability across renames, and the drift-detection value. Given no params to document and an output schema exists, the description fully covers what an agent needs to use this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and 100% schema coverage (effectively empty schema, nothing to document). With 0 params, the baseline is 4. The description adds value by explaining what the output contains (registered:false, unregistered array) which orients expectations even though no parameter semantics are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns canonical (tool_id, mcp_name, ...) for every exposed tool, which is a specific verb+resource+deliverable. It distinguishes itself from siblings by directly positioning it as the authoritative source for identity resolution, unlike list_coupons, list_posts, etc. which list domain data.

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

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

The description names concrete consumers ('Studio, agents, FE') and specific use cases ('Reconcile uses this output to UUID-join against the stored pricing model'). It explicitly states when NOT to use it ('no name-based UUID derivation, no guessing') and explains what the authoritative-canonical design solves. This gives an agent clear decision context for when this tool is the appropriate choice.

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

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

No annotations are provided, so the description carries full burden. It discloses the tool is free and does not consume credits, which is valuable beyond the obvious 'list' operation. It does not mention authentication or potential errors, but given the simplicity, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: first states the purpose, second adds details about output. No redundant words, front-loaded for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with no parameters and an output schema. The description explains what is returned and that it is free. This is complete for a query tool of this nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, and schema coverage is 100%. The description does not need to add parameter meaning, and it briefly lists what each constraint includes (type, category, etc.), adding context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all available constraint types and their parameter schemas, specifying what data is returned (type, category, description, parameter specs). It distinguishes itself from sibling tools by focusing on constraint enumeration for pricing pipelines.

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

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

The description indicates the tool is for listing constraints usable in a pricing pipeline, providing clear context. While it does not explicitly mention when not to use it or alternatives, there are no closely related sibling tools that might cause confusion.

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

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

With no annotations provided, the description carries full burden. It discloses ordering and the auth restriction, but does not mention read-only nature, rate limits, or other behavioral details. Adds some value beyond the name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no redundancy. Purpose, data field, and restriction are efficiently conveyed. Highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, return values are not needed. However, the description lacks details on error conditions, pagination, or the meaning of 'requires proof'. For a simple list tool, it is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter (dpop_token) has 0% schema description coverage, and the tool description does not explain its purpose or usage. The description adds no value for parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it lists coupons minted by the operator, ordered newest first. Provides context about the 'times_redeemed' field. However, does not distinguish from the sibling tool 'excalibur_list_my_coupons', which likely has a different scope.

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

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

Mentions 'RESTRICTED to operator – requires proof', indicating a prerequisite. No explicit when-to-use or when-not-to-use guidance, and no alternatives referenced. The constraint is noted but not elaborated.

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

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

With no annotations provided, the description carries the full burden. It discloses that both active and exhausted redemptions are returned, and explains the status field values. It also notes it is free, providing clear behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences, front-loaded with the main action, and each sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description sufficiently covers purpose, usage, behavior, and parameter requirement, providing complete context for a simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions the npub parameter as required, but does not explain the dpop_token parameter. This partially adds meaning but lacks full parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and resource 'coupons', and specifies the scope 'this patron has redeemed on this operator', distinguishing it from similar tools like 'excalibur_list_coupons'.

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

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

The description mentions the prerequisite 'requires proof of npub', which guides usage, but does not explicitly state when not to use or list alternatives.

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

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

With no annotations, the description carries the full burden. It states it lists records but omits behavioral traits like read-only nature, authentication needs, rate limits, or default ordering. The term 'recent' implies ordering but is vague.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: one sentence for purpose and two lines for parameter definitions. Every word is informative with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and only two optional parameters, the description is adequate but lacks details on ordering ('recent' is ambiguous) and pagination limits beyond 'limit'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no descriptions (0% coverage), but the description explains each parameter: 'limit' as maximum records (with default), and 'status' as optional filter with examples. This adds necessary meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list) and the resource (Bitcoin notarization records). It distinguishes from siblings like excalibur_get_notarization_proof and excalibur_notarize_ledger.

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

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

The description provides no guidance on when to use this tool vs alternatives. It does not mention when not to use it or suggest other tools for specific scenarios.

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

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

No annotations are provided, so the description carries full burden. It explains server-side processing, pagination (0-indexed, page_size range), sorting, filtering (status as set, regex search, date bounds), and the returned structure. However, it does not mention potential rate limits, idempotency, or authentication requirements beyond npub.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but each sentence adds value. It is front-loaded with the core purpose and then details parameters. Could be slightly more structured (e.g., bulleted list) but remains concise without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (12 parameters, output schema exists), the description covers filtering, sorting, pagination, and response format. It lacks mention of error cases, prerequisites (e.g., authentication flow with dpop_token), and potential edge cases. Still very thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 8%, so the description compensates well. It explains most parameters in detail: status filter (comma-separated set), sort_col and sort_dir choices, search (regex, case-insensitive), date_from/to (format and inclusivity), date_field linkage, template_id, page, page_size. Only dpop_token lacks explanation, but overall exceeds expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List your stored posts' with specific verb and resource. It distinguishes from sibling tools like excalibur_get_post by emphasizing listing, filtering, sorting, and pagination.

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

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

The description implies usage for retrieving filtered lists of posts, but does not explicitly mention when not to use it (e.g., for a single post use get_post) or compare with other list tools. The context is clear, but exclusions are absent.

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

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 server-side sorting, filtering, offset pagination, owner-scoping, and the return format. It does not mention potential performance limits or errors, but it adequately describes the behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose and then lists parameters efficiently. It is somewhat lengthy but every sentence adds necessary detail without redundancy. Could be slightly more concise, but well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists (context signals indicate true), so the description does not need to detail return values beyond what it provides. It covers all key aspects: filtering, pagination, scope, and the response shape. Complete for a listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 10%, so the description must compensate. It does so by detailing each parameter's meaning: sort_col values, sort_dir, search as regex, date range format, page indexing, page size range. This adds substantial value beyond the sparse schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'List your saved post snippets,' which is a specific verb+resource pair. Among sibling tools, there are delete, get, and save snippet, but only this one lists snippets, making it clearly distinguishable.

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

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

The description explains the filtering and pagination parameters and states 'Free, owner-scoped,' which implies it's for the user's own snippets. It does not explicitly say when not to use it or compare with siblings, but the context is clear.

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

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

With no annotations, the description discloses the creation behavior, operator-only restriction, and auth requirement. It does not mention idempotency or error handling, but the primary behavior is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement followed by a list of parameters. Every sentence adds value, and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 7 parameters and existence of an output schema, the description adequately covers creation, restrictions, auth, and parameter meanings. It lacks details on return value fields and error conditions, but remains functional.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains 6 of 7 parameters with details like uniqueness, range, ISO-8601 format, and defaults. The dpop_token parameter is omitted, leaving a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a new operator-owned discount coupon,' specifying the verb and resource. It distinguishes from sibling tools like list, delete, update, and redeem by focusing on creation.

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

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

The description explicitly restricts usage to operators and mentions required authentication. However, it does not provide explicit guidance on when to use this tool versus alternatives like update_coupon or redeem_coupon, though the action is self-evident.

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

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

Given no annotations, the description fairly discloses the key behavioral traits: it's a background task, Bitcoin confirmation takes 1-6 hours, and it's free. However, it doesn't mention idempotency or potential side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences with zero wasted words, efficiently conveying purpose, usage context, and cost.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the purpose, timing, and who can use it. With an output schema available, it doesn't need to detail return values, but could mention what triggers the task or if it's idempotent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so the baseline of 4 applies; the description adds no parameter info which is acceptable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool builds a Merkle tree of patron balances and submits the root to Bitcoin via OpenTimestamps, with a specific verb and resource, distinguishing it from the many sibling tools.

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

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

It specifies it's an operator-only background task, indicating who should use it, but lacks explicit guidance on when not to use or alternatives.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It only says 'Free', which hints at no cost but does not address side effects, authentication needs, rate limits, or whether the description is static or dynamic. This is insufficient for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with no wasted words, but it is under-specified. It could be expanded to add more clarity without becoming verbose. A sentence that explains what the output contains would improve it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema exists, the description is minimal. It does not explain what the Oracle provides or what the output format is. While the output schema may fill gaps, the description should offer more context for users to understand the tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema coverage is trivially 100%. The description adds no meaning beyond the schema, which already declares no parameters. A baseline of 3 is appropriate because the schema covers everything.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Describe the DPYC ecosystem via the Oracle', which clearly indicates the verb 'describe' and the resource 'DPYC ecosystem'. However, it lacks specificity about what aspect of the ecosystem is covered, and the term 'Oracle' is not explained. It distinguishes from sibling tools like excalibur_oracle_get_tax_rate or excalibur_oracle_lookup_member, but could be more precise.

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

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

No guidance on when to use this tool versus alternatives. Among many sibling oracle tools (e.g., excalibur_oracle_how_to_join, excalibur_oracle_network_advisory), the description provides no context for when to choose this one.

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

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

With no annotations provided, the description carries the full burden. It only mentions 'Free' which hints at no cost, but lacks details on read-only nature, idempotency, or any side effects. For a tool with no annotations, more behavioral context is expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with a single sentence. Every word is meaningful and there is no extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity (no parameters, simple output), the description is adequate but could be improved by stating what the tax rate is applied to or any prerequisite conditions. The mention of 'Free' adds value, but more context like 'read-only' or 'call anytime' would enhance completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so there is no need for parameter descriptions. According to the baseline rule for 0 parameters, a score of 4 is appropriate as the description doesn't need to add extra meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: getting the current DPYC certification tax rate. The word 'Free' provides additional context. However, it does not explicitly distinguish this tool from sibling tools like excalibur_oracle_network_advisory or excalibur_check_price.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, typical contexts, or situations where a different tool would be more appropriate.

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

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

With no annotations provided, the description carries full burden. It only mentions the tool returns instructions and is 'Free', but does not disclose any behavioral traits like whether it requires authentication or how it behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: 6 words in one sentence. Front-loaded with the key action and resource. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an output schema, the description adequately identifies the tool's purpose. However, it could briefly clarify what 'DPYC' stands for or what type of instructions are provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline is 4. The description adds no parameter meaning but is not required to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'DPYC onboarding instructions from the Oracle'. It distinguishes itself from sibling Oracle tools like 'oracle_about' and 'oracle_lookup_member' by focusing on onboarding instructions.

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

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

No guidelines on when to use this tool versus alternatives. The description does not mention prerequisites, context, or when not to use it.

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

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

With no annotations, the description must disclose behavior. It only mentions it's free, but omits authentication requirements, rate limits, error handling (e.g., invalid npub, member not found), and whether it has side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the core action. However, it could include additional context without becoming verbose, so it doesn't achieve absolute efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, lookup), the description covers the basics. However, it lacks context on input validation, response format (though output schema exists), and edge cases. It is minimally viable but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no description for npub). The description merely repeats the parameter name without explaining what an npub is or its expected format (e.g., hex, bech32). This fails to compensate for the missing schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Look up', the resource 'DPYC community member', the key identifier 'npub', and adds a bonus feature 'Free'. It effectively distinguishes from sibling tools like excalibur_oracle_about or excalibur_get_nostr_profile.

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

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

No guidance is provided on when to use this tool versus alternatives. With a large set of sibling tools, the agent would benefit from conditions like 'Use this for DPYC members, use excalibur_get_nostr_profile for general Nostr profiles.'

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

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

With no annotations, the description must disclose behavioral traits. It only mentions that the tool is 'Free', implying no cost, but provides no information on idempotency, side effects, permissions, or error handling. This is insufficient for informed invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two short sentences. Key information (action, resource, cost) is front-loaded with no filler. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of parameters and the presence of an output schema, the description does not need to explain return values. However, it fails to clarify what 'network advisories' entail or how the output is structured, leaving some contextual gaps for a tool with many siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema coverage is trivially 100%. Per the baseline rule, a score of 4 is appropriate since there is no need for the description to add parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (get) and resource (active network advisories), identifying the tool's primary function. It distinguishes from sibling oracle tools like 'oracle_about' and 'oracle_get_tax_rate', but does not define what constitutes a 'network advisory', leaving some ambiguity.

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

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

No guidance is provided on when to use this tool versus alternatives. The description lacks any conditions, prerequisites, or exclusions, forcing the agent to rely solely on the tool name and context.

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

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

With no annotations, the description fully discloses key behaviors: uses a fresh scribe keypair, p-tags user's npub as author, publishes to DPYC relays, succeeds if at least one relay accepts, and lists relay responses. It honestly clarifies that the note is not truly signed by the user's key.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy (5 paragraphs) and includes technical details. While informative, it could be more concise. It is front-loaded with purpose but has room for trimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of Nostr protocol, the description covers scribe key, author assignment, relay acceptance logic, and response format. Missing minor details like error handling and dpop_token purpose, but output schema presumably covers return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond schema: 'message' is the note text, 'npub' is the proven DPYC patron npub. Schema covers npub description, but dpop_token is not explained in description. Overall, it compensates for 33% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool publishes a public Nostr note (kind 1) authored by the user's proven npub. It distinguishes from siblings like excalibur_create_post (different post type) and excalibur_publish_nostr_profile (profile update).

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

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

The description explains when to use: to publish a Nostr note from your proven npub. It details the scribe key mechanism and relay acceptance. However, it does not explicitly state when not to use or list alternatives, though context makes it clear.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does add context about the data source (durable snapshot store) and the derived nature of the output, but it does not explicitly confirm read-only behavior, authentication requirements, rate limits, or side effects. The 'Patron:' prefix hints at access restrictions but is not explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately concise and front-loads the main purpose, but it includes jargon-heavy flourishes like 'signals that come from owning the curve' that add little practical value. A tighter, less poetic phrasing would improve clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains what metrics are computed and notes the data source, and an output schema exists to cover return values. However, it lacks explicit usage guidance, auth context, and side-effect clarity, and relies on undefined jargon that may hinder an agent's full understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema describes npub but leaves dpop_token with an empty description, and the tool description does not explain either parameter. With schema description coverage at 50%, the description needed to compensate for dpop_token's meaning but did not, leaving the auth token's role ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool computes derived reach scores across the user's harvested post corpus and enumerates specific metrics (escape velocity, breakout ratio, cohort medians, snippet/voice attribution). It distinguishes this from simple X endpoint proxying, and the sibling infographic tool is implicitly separated by focusing on raw derived scores rather than visual output.

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

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

The description implies the tool is for analyzing derived performance metrics from one's own stored corpus, but it does not explicitly state when to use it versus alternatives like excalibur_get_post_metrics or excalibur_post_performance_infographic. There is no mention of conditions, prerequisites, or exclusions, so usage guidance is only implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions it 'Mirrors account_statement_infographic' and lists included metrics (corpus size, median t+15m impressions, etc.), but it does not state whether the tool is read-only, whether it requires OAuth or patron credentials, what side effects occur, or how the SVG is returned. The 'Patron:' prefix hints at access restrictions but is ambiguous.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that front-load the purpose and then add relevant detail about theme and content. Every sentence contributes value, with no redundant filler or vague jargon.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives a good overview of the output content and theme, but it omits critical context about authentication, prerequisites, and parameter usage. While the presence of an output schema reduces the need to describe return values, the tool still requires npub and dpop_token, and the description doesn't explain how these are used or why they are needed. This leaves the tool somewhat incomplete for an agent to invoke confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides no explanation of the 'npub' and 'dpop_token' parameters beyond what the schema already gives for npub. The 'dpop_token' parameter is entirely undocumented in both the schema and description, leaving a significant gap. Since schema coverage is only 50%, the description should have clarified the role of the token but did not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states this tool produces an 'SVG infographic of post performance' with a specific gold-steel theme, which identifies the resource and output type. It also references the sibling 'account_statement_infographic' to give context, but it doesn't explicitly state the action verb (e.g., 'generate' or 'create') nor directly contrast with 'excalibur_post_performance' for data vs. infographic.

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

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

The description implies similarity to 'account_statement_infographic' but provides no explicit guidance on when to use this tool versus alternatives like 'excalibur_post_performance' or other infographic tools. There is no mention of scenarios, prerequisites (e.g., being a patron), or exclusions, leaving the agent to infer usage context.

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

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

No annotations provided; description discloses markdown conversion and npub for credit attribution but does not mention failure modes, rate limits, or authorization beyond npub.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Relatively concise with a clear intro, helpful markdown table, and args list. The args list repeats schema info slightly but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema in description; no mention of return values (e.g., tweet ID), character limits, or error handling. Leaves agent guessing about post-output behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Describes text and npub clearly but omits dpop_token entirely. Schema coverage is 33%, so description partially compensates but leaves a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states action (post) and resource (tweet) with a specific feature (markdown to Unicode rich text). Distinguishes from siblings like excalibur_post_tweet_image.

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

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

Describes markdown conversion and npub requirement but lacks explicit guidance on when to use vs alternatives like excalibur_post_tweet_image or excalibur_create_post.

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

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

No annotations are provided, so the description carries full burden. It describes that image_url is fetched and attached, banner_svg is rendered to PNG, and npub is for credit attribution. However, it does not disclose authentication requirements, side effects (e.g., duplicate detection), rate limits, or what happens on failure. The dpop_token parameter is completely unexplained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is fairly concise with two paragraphs. The first paragraph states purpose and parameter alternatives. The second paragraph repeats parameter info in an args style, which adds minimal value. Overall, it is efficient but could be slightly more streamlined.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, return values need not be described. The description covers the main functionality (post tweet with image) and the two image sources. However, it lacks context on authentication (likely requiring OAuth, given sibling tools like excalibur_begin_oauth), and does not explain whether posts are immediate or scheduled. The dpop_token parameter's role is unclear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 20%, so the description adds significant value by explaining text (markdown), image_url vs banner_svg alternatives, and npub for attribution. However, it misstates npub as required when it has a default and is not in the required array. The dpop_token parameter is not mentioned at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it posts a tweet with a hero banner image to X/Twitter, specifying the action, resource, and platform. The name and description distinguish it from sibling tools like excalibur_post_tweet (which presumably posts without an image) and excalibur_post_nostr_message (for Nostr).

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

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

Explicitly provides guidance on using either image_url or banner_svg, and notes that text supports the same markdown as post_tweet. However, it does not explicitly state when to prefer this tool over post_tweet (e.g., when an image is needed), but this is implied by the name and description.

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

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 tool claims posts atomically, starts background publishers, returns immediately, and that the actual publishing may take minutes. It also specifies the return format and the operator requirement. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is succinct and front-loaded with the core action. Each sentence adds essential information (operator-only, atomic claim, async behavior, outcome retrieval, return format). No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the presence of an output schema (implied by description of return format), the description covers all critical aspects: purpose, prerequisites, behavior, outcomes, and caveats. It is complete for an agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%, with only npub having a description. The description adds value by stating 'Requires the operator's npub proof', reinforcing the schema. However, dpop_token is undocumented in both the schema and description. The description compensates partially but not fully for the low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool launches a publisher for every due post, operator-only. It specifies the action (selecting, claiming, starting publishers) and distinguishes from the actual publishing process, which is done by a separate publisher. This differentiates it from sibling tools that handle other tasks.

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

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

The description explains when to use the tool (for due scheduled posts) and what it does not do (publishing). It also mentions that outcomes can be read from get_scheduler_log or post rows, providing guidance for follow-up. While it does not explicitly list alternatives, the context is sufficient for an AI agent to understand usage.

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

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

With no annotations, the description fully discloses behavioral traits: the wheel verifies the signature, relays to public relays, and operates without key custody. It also notes the tool is free, adding important context for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear lead, explanatory paragraphs, and an Args list. It is slightly verbose but every sentence adds value; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has two parameters, no required params, and an output schema exists, the description covers the entire flow: input, verification, relay broadcast, and security model. It is complete for an agent to understand and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It clearly explains that npub is the patron's public key and signed_event is a JSON-encoded, client-signed kind-0 event, adding crucial meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool publishes a kind-0 Nostr profile to relays for an npub. It distinguishes from siblings like 'excalibur_get_nostr_profile' and 'excalibur_post_nostr_message' by specifying the action and resource.

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

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

The description explains when to use this tool (when a client-signed event is available), explicitly states that the wheel never holds a patron nsec, and clarifies that the signature is authorization. It provides clear guidance on prerequisites and security model.

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

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

The description discloses key behaviors: creates a Lightning invoice, requires npub ownership proof, is free to call, and that payment must be confirmed via check_payment. No annotations exist, so the description carries full burden. It doesn't detail failure scenarios or side effects, but the core flow is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a one-line summary, a brief process paragraph, a free call note, and a clear 'Args' section. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description does not need to explain return values. It covers input parameters thoroughly and mentions the follow-up call to check_payment. However, it lacks error handling or prerequisite details, which would make it more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description thoroughly explains each parameter: npub (what it is), dpop_token (detailed format and requirements), and amount_sats (unit and default). This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Buy credits via Bitcoin Lightning', clearly stating the tool's purpose. It explains the process of creating a Lightning invoice and the need to call check_payment, distinguishing it from related tools like check_payment. The free call mention is an additional clear benefit.

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

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

The description says 'then call check_payment to confirm', providing a clear after-use action. It implicitly tells when to use: when buying credits via Lightning. However, it does not explicitly exclude alternatives like redeem_coupon, so it lacks full usage boundaries.

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