get_transactions

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

With no annotations, the description carries the full behavioral disclosure burden. It reveals that not-found digests are returned in a `not_found` list rather than dropped, that duplicates are collapsed (in schema as well), and that get_transaction should be used when there are more than 50 events because this batch tool pages events differently. It also clearly frames the operation as read-only by starting with 'Read', which is important since no readOnlyHint is available.

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 dense but every clause earns its place. It front-loads the core capability, then return contents, then concrete use cases, then edge-case behavior, then the alternative. It avoids filler and is organized so an agent can quickly extract purpose, usage, and limitations.

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 two-parameter, no-output-schema tool, this description is remarkably complete. It specifies input semantics (digests, network), batch limit (50), behavior when digests are missing, return value highlights, and the boundary with the single-transaction sibling. An agent has enough information to select the tool and invoke it correctly for both common and edge cases.

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 100%: both `digests` and `network` already include detailed descriptions in the schema, including Base58 format, min/max items, duplicate collapsing, and network enum semantics. The tool description does not add meaning beyond what the schema provides for these parameters; it only adds usage context. This meets the baseline for high schema coverage but does not exceed it.

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 opens with a specific verb-object pair: 'Read up to 50 Sui transactions in ONE call, given their digests.' It clearly identifies the resource (transactions by digest), the batch scope, and the key returned fields (sender, status, timing, balance changes, move call targets, events with decoded fields, protocols). It also explicitly contrasts with the sibling get_transaction, making differentiation effortless.

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 gives explicit when-to-use guidance: 'Use this whenever you hold several digests at once' with concrete examples (fan-out outputs, cluster edge evidence, hops to compare). It states the alternative and the exact condition for switching: 'For ONE transaction, or for a transaction with more than 50 events, prefer get_transaction.' No inference is required.

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