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

No annotations exist, so the description carries the full burden; 'Read' signals a non-mutating lookup, and it usefully discloses what the response contains, which is the main behavioral unknown. It says nothing about permissions, failure when the block is unknown, or whether unpublished blocks are returned, all of which matter for a no-annotation 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?

A single sentence, front-loaded with the verb and resource, then the lookup key, then the returned payload. Nothing is padded and no clause needs rereading.

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 only two parameters and no output schema, the description covers the essentials by enumerating the return fields in place of a schema. It falls short on input formats for source/name and on not-found behavior, so an agent still cannot fully predict valid calls or outcomes.

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 compensate. It does add real value by framing 'source' and 'name' as a composite key that identifies exactly one block, matching the fact that both are required, but it gives no format or domain for either (URL vs registry namespace, case sensitivity, name syntax), leaving the agent to guess valid 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?

States a specific verb and resource ('Read one block') plus the lookup key ('by source + name') and enumerates the payload (description, file list, registry dependencies, publication targets). That is enough to distinguish it from search_blocks, which is a discovery rather than a single-item fetch, though the description never names the sibling 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?

The phrase 'by source + name' hints that both identifiers must already be known, which implicitly routes discovery work to search_blocks, but the description states no when-to-use condition, no exclusions, and no alternative. The agent must infer invocation context from the sibling list.

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