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

No annotations are provided, so the description must carry the behavioral burden. It usefully discloses the fields returned and that bond status has three discrete values (pending/active/slashed), which implies a read-only snapshot, but it never states that it is non-mutating, what auth is required, or when the snapshot is taken.

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?

A single sentence with the action front-loaded and the payload enumerated compactly. Every clause earns its place, including the parenthetical enum of statuses.

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 no output schema, the description compensates by listing exactly what comes back, and there are no parameters to document. It is close to complete for a zero-arg status tool, though it omits read-only/auth context an agent might want before calling.

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 takes zero parameters, so per the rules the baseline is 4. Nothing in the description is needed to explain inputs and nothing is misleading.

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 a specific verb ('Show') plus the resource and an explicit enumeration of returned fields (id, bond status, trust badges, receipt count, open disputes). That is enough to distinguish it from siblings like register_agent or escrow_status, though it never names an alternative directly.

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 when-to-use, no prerequisites, no mention of how it differs from escrow_status or find_agents. The mention of 'slashed' and 'open disputes' hints at a health-check use case, but that is inference, not guidance.

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. It does disclose the return contents (status, amounts, deadline, payout state, last error), which is useful since there is no output schema, but it never states that the call is read-only, whether it requires authorization, or whether it errors when the escrow does not exist.

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?

One compact sentence with the resource front-loaded and the returned fields listed inline. Nothing is wasted, though the parenthetical is slightly ambiguous.

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 single-parameter read tool with no output schema, listing the returned fields is the right move. However, with no annotations and no usage guidance, an agent still lacks the when-to-call context needed to pick this over the other escrow tools.

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 single parameter escrow_id has 0% schema description coverage, and the description never explains the identifier, its format, or where it comes from. The '(either party)' phrase is the only hint about the ID's scope, leaving the schema to carry an undocumented parameter.

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?

Names a specific resource (one escrow) and enumerates what 'full state' means: status, amounts, deadline, payout state, last error. It is distinguishable from the sibling bond_status by resource, though it never explicitly contrasts the two.

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 statement of when to call this versus open_escrow, fund_escrow, release_escrow, or bond_status. The '(either party)' note hints at access scope but gives no usage context or 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, and it does disclose a meaningful trait: the relay only ever holds ciphertext and decryption happens locally with the agent's keys. However, it omits auth/eligibility requirements, ordering or pagination behavior, and what happens when decryption fails.

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?

A single well-formed sentence with the key concept (fetch + local decrypt) front-loaded and no filler. It is tight, though extremely terse for a tool with two undocumented parameters.

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, no annotations, and two required parameters neither documented in schema nor description. The agent is not told what the tool returns (plaintext list? single message?), how results are ordered or paginated, or what errors to expect.

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% and the description explains neither required parameter. 'A room's ciphertext' loosely implies room_id, but counterparty_id is entirely unexplained despite being required, so the description does not compensate 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?

States a specific verb (fetch) and resource (a room's ciphertext) plus the key mechanism (fetch from relay, decrypt locally with this agent's keys). It is clearly distinguishable from the write-oriented sibling send_message, though it never names an alternative explicitly.

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 when-to-use guidance, no prerequisites (must the agent already be a room member? must the room exist?), and no mention of alternatives such as send_message for the opposite direction. The agent must infer the whole invocation 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 full burden, and it does disclose a genuinely non-obvious trait: the receipt is not final until the counterparty co-signs the same room/bucket/outcome/ts. It omits, however, whether keys/permissions are required beyond 'this agent's key', whether re-calling overwrites or duplicates a signature, and what happens on a ts mismatch.

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, and the core action is front-loaded before the completion condition. The 'room/bucket/outcome/ts' slash-run is slightly terse but packs the matching constraint efficiently.

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 5-parameter, unannotated signing tool with no output schema, the description conveys the essential two-party handshake idea but leaves gaps around parameter meanings, permission/key requirements, and failure or idempotency behavior. Adequate as a minimum viable definition, 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 description coverage is 0%, so the description must compensate, and it names room/bucket/outcome/ts as the tuple that must match while adding real guidance for ts ('the ts you agreed on inside the room'). It offers nothing on counterparty_id or amount_bucket semantics and does not explain the completed/failed enum, so the compensation is only partial.

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 a precise verb+resource ('Sign a completion receipt ... and submit it') and explains the bilateral completion model. It is clearly distinguishable from sibling tools like release_escrow or send_message, though it never explicitly contrasts itself with them.

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?

'Pass the ts you agreed on inside the room' gives implicit workflow context (agree on a timestamp in the room, then file), and 'becomes complete when the counterparty submits their signature' clarifies the condition. However, it does not say when to file a receipt versus using release_escrow/escrow_status, nor what prerequisites must already be satisfied.

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 behavioral burden. It hints at a read operation with 'public profiles,' but doesn't disclose pagination, result limits, ordering, or what happens when the filter matches nothing.

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 short, well-front-loaded sentences with no wasted words. It could be slightly more informative without bloat, but the economy is fine.

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 single optional-parameter read tool with no output schema, the description is minimally adequate. It states the operation and filter but leaves the return shape and matching semantics unstated, which an agent would need to guess.

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% for the single 'capability' parameter, but the description does explain it matches a substring. That compensates somewhat for the empty schema, though it omits case-sensitivity or matching behavior.

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 a specific verb (discover/find) and resource (registered agents, public profiles), which is fairly clear. It doesn't distinguish itself from siblings like register_agent explicitly, but most siblings serve different domains (escrow, messaging) so confusion is unlikely.

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 notes an optional filter but offers no guidance on when to use this versus alternatives. It implies read-only browsing but doesn't state prerequisites or how results should be interpreted.

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 and does substantial work: it discloses that funds lock at the platform node without settling, that the escrow state transitions to 'funded', and that the caller must poll until funded. Missing are error/idempotency behavior and any permission or pre-requisite (existing escrow) notes.

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, front-loaded with the return value and then the action sequence; no filler 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?

With no output schema and no annotations, the description adequately covers the return payload (funding state, payment_request, status), the state transition, and the polling requirement. The shape of the returned object and failure cases are left unspecified, but an agent has enough to call it 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?

One parameter (escrow_id) with 0% schema description coverage; the description never defines it, though its meaning is self-evident from context. It does name the response field payment_request, but that is an output, not a parameter, so it adds no input 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 states a specific verb and resource: it returns an escrow's funding state plus the BOLT11 hold invoice, and explains the fund flow (pay payment_request, funds lock at the platform node). It is clearly distinct in content from escrow_status, though it never names a sibling to route the agent away from.

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 gives concrete usage instructions: pay the payment_request from your own Lightning wallet, and poll this tool until status=funded. That is clear context for invoking it, but there is no explicit when-not or named alternative (e.g. escrow_status or open_escrow) to disambiguate.

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 and does well: it discloses the hold-invoice (non-settling) semantics, the BOLT11 payment_request return, the escrow_unconfigured failure mode, and the 1% seller-side fee mechanics. It omits auth/permission requirements and any timeout behavior, so it is strong but not exhaustive.

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 the core action, then return value, then failure mode, then fees — each sentence adds distinct information with no repetition. Dense but well-structured for a tool with no annotations and no output schema.

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 no output schema and no annotations, the description covers the essentials: what is created, what is returned (BOLT11 payment_request, net_payout_sats, fee_sats), and how it fails. The unexplained timeout_secs parameter is the one notable gap for a 4-parameter mutation/creation 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 coverage is 0% across 4 parameters, so the description must compensate, and it only partially does: counterparty_id is clarified as the seller and amount_sats is implied by the fee discussion. room_id is only implied ('on a room') and timeout_secs is never explained anywhere, leaving a required-adjacent parameter fully opaque.

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 a specific verb+resource ('Open a Lightning hold-invoice escrow on a room') and clarifies the agent's role (buyer) and counterparty (seller). It does not explicitly distinguish itself from siblings like fund_escrow or release_escrow, leaving the agent to infer that this is the initiation step rather than the funding or settlement 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?

Gives clear context: use as buyer to lock funds for a seller, with the explicit note that funds do NOT settle until release. It also names a concrete failure condition (escrow_unconfigured until the operator configures a Lightning node). No explicit when-not guidance or named alternative sibling, which keeps it below a 5.

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 supplied, so the description carries the full behavioral burden. It discloses the bonding precondition and that the room is 'sealed' (implying privacy), but says nothing about idempotency, failure modes when a party is unbonded, cost, or what state is created — meaningful gaps for a state-creating 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?

Two short sentences, zero waste, with the action and its input front-loaded before the precondition. Nothing is padded or repeated.

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

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

For a simple one-parameter tool with no output schema and no annotations, the description covers the action and the main precondition. However, it omits what the call returns or creates (room id, state) and what happens on precondition failure, leaving the agent under-informed for an operation that establishes shared state.

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% and the single parameter has no schema description, so the description must compensate. It clarifies that the parameter is the counterparty's agent id (as opposed to a room id or self id), which is useful, but adds no format, lookup, or validation detail beyond that.

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 a specific verb+resource ('Open a sealed negotiation room') and names the key input ('counterparty agent id'), so the action is unambiguous. It does not explicitly distinguish itself from siblings like open_escrow or send_message, but the resource name is distinctive enough to route the agent correctly.

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?

Provides a concrete precondition: 'Both agents must be bonded (active)', which tells the agent when this call can succeed. It names no alternatives or exclusions (e.g., what to do when a party is unbonded), so it stops short of full when/when-not guidance.

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 and does disclose real side effects: it registers with an external service, can trigger trust-badge verification, and will bond immediately based on a server env var. It omits auth/permission requirements and what happens on repeat invocation, so it is strong but not exhaustive.

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, front-loaded with the core action, then the optional parameters, then the conditional bonding behavior. No filler and no repetition of the schema.

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 mutation tool with no annotations and no output schema, the description covers purpose and side effects but leaves gaps an agent would want: what the call returns (identity/agent id), whether re-invocation is idempotent, and any auth requirements. Adequate but not fully self-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 description coverage is 0%, so the description must compensate, and it does explain that domain and business_name are optional and that they trigger trust-badge verification. It does not give format expectations (bare domain vs URL) or any constraint on business_name, leaving some ambiguity for both 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 names a concrete verb pair (create/load identity) and its target (register with Darkroom), which is specific enough to distinguish it from siblings like bond_status or find_agents. It stops short of explicitly contrasting itself with any sibling tool, so it lands at clear-but-undifferentiated.

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 implicitly tells the agent when to supply the optional params (domain/business_name trigger trust-badge verification) and when bonding occurs (DARKROOM_BOND_TXID set), which is useful conditional context. However it never states when to call this tool versus alternatives, nor any prerequisites or exclusions, leaving tool selection to inference.

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 present, the description carries the full burden and does so well: it discloses the actor constraint (buyer), the prerequisite artifact, the settlement mechanics (hold invoice settled, payout invoice paid if registered), the terminal status, and detailed fee behavior (seller receives net after a 1% platform fee; fee_sats stays in the operator node and is recorded on the escrow). This is material side-effect and irreversibility context no annotation provides.

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, front-loaded with the action, actor, and precondition before behavior and fee detail. No filler; the fee sentence is dense but each clause conveys a distinct rule.

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 one-parameter tool with no output schema and no annotations, the description covers prereqs, side effects, terminal status, and fee distribution, which is nearly everything an agent needs. It stops short of naming the failure mode when the receipt is absent or the coverage of the single parameter.

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

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

Schema description coverage is 0% and the single parameter escrow_id is never described in terms of format or source. The description does add contextual meaning about which escrow is valid (must be funded and tied to a room with a completed receipt), which partially compensates, but it is not parameter-level 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?

Specific verb+resource ('release a funded escrow') with the caller role ('As buyer') stated up front. It is clearly separable from the sibling open_escrow/fund_escrow/escrow_status verbs without opening any schema.

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?

States the precondition explicitly ('requires the dual-signed completed receipt for the room to exist') and routes to the prerequisite tool ('see file_receipt'), which is exactly the guidance an agent needs. It lacks an explicit when-not/exclusion statement versus escrow_status, which keeps it from a 5.

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, and it does disclose a genuinely useful trait: encryption happens client-side and the relay never sees plaintext. However, it omits auth requirements, whether the message is persisted, idempotency/retry behavior, and failure modes, which are material for a write/relay 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?

Two tight sentences with the security-relevant fact front-loaded and zero filler. Nothing could be cut without losing 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?

For a 3-param mutation tool with no annotations, no output schema, and 0% schema coverage, the description covers the security model well but leaves the operational model thin: no auth/prerequisite info, no confirmation of what the call returns, and no parameter semantics.

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% for all three required parameters, so the description must compensate and does not. It hints at 'room' and 'message' but never explains room_id format, what counterparty_id identifies (an agent id?), or any constraint on text.

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 gives a specific verb+resource: it encrypts a message and relays it into a room, and names the crypto primitives (X25519 + ChaCha20-Poly1305). That is clearly distinct from siblings like fetch_messages or open_room, though it never names the counterpart operation explicitly.

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 when-to-use guidance, no prerequisites (e.g., agent must be registered, room must be open, counterparty must exist), and no reference to alternatives such as file_receipt for non-message payloads. Usage is only implied by the verb 'relay'.

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 seller role, the amount <= escrow amount constraint, and the workflow dependency on funding, but omits overwrite/idempotency behavior, error cases, and whether the invoice can be replaced.

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 front-loaded sentences with no filler. The timing guideline follows the main action and keeps the total length appropriate.

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

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

For a simple 2-param mutation with no annotations or output schema, the description covers purpose, role, timing, and a key validation constraint. It leaves some operational details unstated but is otherwise sufficient for 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 description coverage is 0%, so the description must explain both parameters. It adds meaning for invoice (BOLT11, amount constraint, payout leg) and implies escrow_id via escrow-release context, but escrow_id's format and role are not explicitly defined.

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 a specific verb and resource: register the BOLT11 invoice, scoped as seller for the payout leg. It distinguishes itself from release/fund escrow by focusing on invoice setup before release, though it does not explicitly name a sibling alternative.

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 to do this before or right after funding so release can complete in one step, giving clear timing context. It does not state when not to call it or name alternative tools.

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