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

With no annotations, the description must disclose behavioral traits, but it only states high-level guarantees (buyer/seller protections). It doesn't clarify whether this call actually moves funds (sibling fund_escrow suggests the flow may be split), nor mention fees, failure behavior, or the dispute/auto-release mechanics already present in 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 four concise sentences that front-load the core action and then explain value. It is slightly promotional with claims like "can't be stolen" but every sentence contributes to understanding purpose and 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?

For a 7-parameter financial tool with no output schema or annotations, the description is too high-level. It omits what the tool returns, whether funding is part of this call, and how the payment method/chain relate to the escrow lifecycle. This leaves critical operational gaps for an agent.

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 100% coverage with detailed descriptions for all 7 parameters, so the description is not required to explain each field. The text adds the fiat/crypto context that aligns with paymentMethod and chain, but no parameter-specific semantics 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?

The description uses a specific verb+resource pair ('Lock funds in escrow') and clearly conveys the tool's role in escrow creation. It doesn't explicitly contrast with siblings like fund_escrow or release_escrow, but the initial locking action makes the purpose unmistakable.

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 use when a buyer and seller need a neutral trust layer for a job, mentioning fiat/crypto bridging. However, it provides no explicit guidance on when to use create_escrow versus related tools like fund_escrow or predict_escrow, nor any when-not-to-use conditions.

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