ddb_get_rules

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read. The description adds context beyond annotations: it discloses the coverage scope (core 5e SRD topics), the query-jumping behavior, and the lack of login requirement. It does not describe error behavior or return format, but given the annotation safety profile, 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 information-dense yet concise: main action, topic scope, query usage, alternative tool, and auth requirement are each covered in one or two sentences. No filler or repetition. The front-loaded first sentence immediately states the tool's purpose.

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-read tool with 3 params and no output schema, the description covers the essential context: what it retrieves, what topics are included, how to use the query parameter, when to use an alternative, and that no login is needed. It lacks explicit error handling or pagination details, but these are not required for such a tool and the schema covers max_chars bounds.

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%, so all parameters (name, query, max_chars) are already documented with examples and constraints. The description adds marginal context by referencing 'full SRD rules text' and 'long section' but does not substantially enhance parameter understanding. The baseline of 3 applies because the schema carries the heavy lifting.

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+resource+scope: 'Get the full SRD rules text for a topic by section name or slug.' It addresses coverage explicitly ('Covers all core 5e rules') and differentiates from sibling tools by naming ddb_read_book as the alternative for non-SRD or more detailed rules. This clearly distinguishes it from related tools like ddb_search_rules.

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 guidance: 'Use query to jump to a specific topic within a long section' and 'For non-SRD rules or more detail, use ddb_read_book.' It also states 'No login required,' informing the agent of prerequisite conditions. This is clear when-to-use and when-to-avoid guidance with a named alternative.

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