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

No annotations are provided, so the description carries the full behavioral burden. For a batch operation, the critical traits – partial-failure semantics, whether the call fails atomically, result ordering, and the 50-item cap (which appears only in the schema) – are not addressed. 'Supports mixed resource types' largely repeats what the schema enum already shows.

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 zero waste, and the core capability (multiple resources, single call) is front-loaded.

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 batch-read tool with a self-documenting schema, the definition is minimally adequate. However, with no output schema and no annotations, it omits the behavioral traits (failure handling, ordering) an agent would need to call it correctly in 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%, so the schema already documents the `requests` array with its max-50 constraint and the resource_type enum. The description adds no parameter-level detail (syntax, format, ordering) beyond the schema, so baseline 3 is appropriate.

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 (retrieve), a clear resource (multiple resources), and the batch scope ('in a single call'), which implicitly distinguishes it from the singular `get` sibling. It does not name siblings explicitly, but an agent can infer the batch-vs-single distinction.

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?

Usage is only implied: the agent can infer 'use when retrieving several resources at once.' There is no explicit when-to-use/when-not guidance versus repeated `get` calls, `search`, or `list`, and no mention of prerequisites or rate limits.

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 must carry the full behavioral burden. It mentions three check modes but omits whether the tool is read-only, its side effects, authentication needs, or rate limits.

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 a single, front-loaded sentence with no wasted words. It is appropriately concise, though it could be slightly clearer in phrasing.

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?

Given four parameters, no annotations, and no output schema, the description is incomplete. It does not explain the return format, side effects, or how to interpret the three check modes.

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 75%, with three of four parameters documented in the schema. The description adds no parameter-level meaning beyond the schema, so the schema does 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 clearly states the tool's purpose: checking a slug for existence, collision, or modification. It uses a specific verb and resource, but does not explicitly distinguish itself from siblings like validate_entry or diff.

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 no guidance on when to use this tool versus alternatives. It implies slug validation but does not state prerequisites, 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?

No annotations are provided, so the description carries the full burden. It does not say whether the comparison is read-only, how missing fields or absent resources are handled, or what the diff result contains, leaving real behavioral gaps for a tool whose output is the whole point.

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 front-loaded sentence with no filler, which is efficient. It is arguably too terse given the behavioral and usage gaps, so it is not a 5.

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 four parameters, a nested draft object, no annotations, and no output schema, the description should at minimum characterize the diff result and the read-only nature of the operation. It provides none of that, leaving an agent under-informed about calling and interpreting this 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 75%, above the midpoint but below the 80% baseline, and the schema already documents slug, draft, ignore_fields, and the resource_type enum. The description adds no parameter-level detail (e.g., ignore_fields semantics or draft object shape), so it neither compensates for nor improves on the schema.

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 (compare) and the two resources involved (draft entry vs. live API version), so an agent can distinguish this from siblings like validate_entry or get. It stops short of explicitly naming a sibling or the domain resource types, but the core action is unambiguous.

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 reach for this tool versus validate_entry, get, or normalize, and no mention of prerequisites such as the entry needing to already exist or be a valid draft. The intended workflow (e.g., checking changes before publish/PATCH) is only inferable.

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 behavioral burden, and it does not state whether this tool writes to disk, calls an API, requires authentication, or mutates state. It only says the output is 'suitable for submitting to open5e-api,' leaving execution side effects ambiguous. For a generation tool with nested object input, this is a notable gap.

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 a single efficient sentence with no wasted clauses, and it front-loads the action and output type. It is appropriately sized for the tool's scope. No structural issues.

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?

Given no output schema, no annotations, and a nested 'data' object, the description should explain the return value or side effects but does not. It also omits the workflow context (validation, slug checks) that would make the tool usable in a multi-step PR pipeline. It is too thin for the tool's complexity.

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 the input schema already documents all four parameters including enums for operation and resource_type. The description adds no parameter-level meaning beyond that baseline. A 3 is appropriate when the schema fully carries parameter 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 ('generate') and resource ('PR-ready JSON output') tied to open5e-api, which is clearer than a bare name restatement. However, it doesn't differentiate from siblings like validate_entry, normalize, or diff, which likely also operate on entries for the same API. The purpose is understandable but not sharply distinguished from neighboring tools.

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 or when-not-to-use guidance. The description doesn't mention alternatives such as validate_entry or normalize, nor does it explain the workflow position (e.g., run after validation, before submitting a PR). An agent has no direct signal for choosing this tool over siblings.

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 behavioral burden. It does disclose that the return includes frontend web URL, but it omits whether this is a read-only operation, permission requirements, error behavior for missing slugs, or rate limits.

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 efficient sentence that front-loads the verb and resource, with no wasted words. Every phrase earns its place.

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 single-resource get tool with full schema description coverage, the description is mostly complete: it states the lookup key and hints at return content. It could say more about what 'full details' includes or what happens when the slug is not found, but the core call contract is clear.

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%, including a clear enum for resource_type and a slug example, so the schema already does the heavy lifting. The description adds no syntax, format, or constraint details beyond what the schema provides, making the baseline 3 appropriate.

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 ('Get') and scope ('a single resource by slug'), and the word 'single' implicitly distinguishes it from the sibling batch_get and from search/list. The resource type is generic, but the schema enum supplies the concrete domain.

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?

Usage is implied by 'single resource by slug' and 'full details', suggesting it is for detail retrieval rather than searching or listing. However, no explicit when-to-use or when-not-to-use guidance is given, and alternatives like batch_get or search are never named.

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. It discloses the two things inspected (connectivity and cache) but not whether it is read-only, whether it hits external systems, whether it can be slow or rate-limited, or what the response contains. Some behavioral value is added, but the safety and output profile is absent.

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 tight sentence with no filler, front-loading the verb and the scope. Nothing could be removed without losing meaning.

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?

There is no output schema, so the description is the only source of information, yet it says nothing about the shape of the result (per-service status? error text? boolean?). For a diagnostic tool whose entire value is its return payload, that gap matters.

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 the baseline of 4 applies. The schema fully covers the (empty) input and the description has no parameter semantics to compensate for.

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 ('Check') and two concrete resources (API connectivity, cache status), so the agent knows exactly what the tool inspects. It does not, however, distinguish itself from the sibling rag_health, which likely overlaps in purpose.

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 no indication of when to call this versus rag_health, rag_stats, or any other diagnostic sibling, and no conditions or prerequisites are mentioned. Usage must be fully inferred from the name.

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 behavioral burden. It discloses one useful non-schema fact — that results include frontend web URLs — but says nothing about read-only nature, ordering, pagination behavior, or rate limits, leaving a fair amount undisclosed for a fully unannotated 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 short sentences, front-loaded with the core action, and the second sentence delivers a distinct piece of return-value information rather than restating the first.

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 8 parameters fully documented in the schema and no output schema, the description is adequate but thin. It partially compensates for the missing output schema by noting web URLs, but leaves filter-combination behavior and sibling routing unaddressed.

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%, including enum values and per-filter notes (cr, type, level, school), so the schema already does the heavy lifting. The description adds nothing about parameter meaning, making the baseline 3 appropriate.

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 ('List') and resource ('resources of a type'), so an agent knows this is a collection-listing operation. It does not distinguish itself from siblings like 'search', 'get', or 'list_documents', which is the main gap keeping it from a 5.

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 indication of when to use this versus 'search' or 'get', no mention of prerequisites, and no stated constraints on combining filters. The only guidance is the word 'optional' about filters, which is inferred from the schema anyway.

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 payload shape ('metadata and resource counts'), which implies a read-only enumeration, but says nothing about pagination, ordering, auth requirements, or result limits for a tool whose name advertises 'List all'.

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 front-loaded sentence with no filler. It is appropriately sized for a simple zero-parameter list tool, though it leaves obvious questions (pagination, scope) unaddressed rather than being maximally dense.

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 usefully names what is returned (metadata and resource counts), and for a zero-parameter listing tool that is largely sufficient. It falls short only on enumeration behavior such as pagination or completeness guarantees.

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 the schema has no semantics to add to and the baseline of 4 applies. The description adds only the output-content hint, which is not a parameter concern.

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 (List) and resource (source documents/books) and even previews the return content (metadata and resource counts). It is clear what the tool does, though it does not explicitly distinguish itself from generic siblings like 'list' or 'list_endpoints'.

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 guidance on when to use this instead of alternatives such as 'list', 'get', or 'search', nor any stated prerequisites or exclusions. The agent must infer usage purely from the name and one-line description.

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 does disclose the shape of the returned data (versions and URLs), which is meaningfully behavioral for a zero-parameter tool, but it never states that the call is read-only, whether auth is required, or how large the result set is.

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, with no filler or redundancy. Every clause adds 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?

With no output schema, the description must sketch the return value, and it does name the fields returned (versions, URLs). For a trivial zero-param lister that is nearly sufficient, though it omits any indication of scope or pagination.

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 the baseline is 4. There is nothing parameter-level for the description to clarify or compensate for.

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 (list + API endpoints) and specifies the payload returned (versions and URLs). It is distinguishable from generic siblings like list, get, or search, though it never names an alternative to route against.

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 guidance on when to call this versus the many other listing/discovery tools (list, search, list_documents, rag_sources). The only implied use is endpoint discovery, which the agent must infer.

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. 'Normalize' and 'standardize' imply mutation of supplied data, but it never says whether it writes back to storage or just returns a transformed payload, whether it is idempotent, or how failures are reported. That is a significant gap for a mutating tool with zero annotation coverage.

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, zero filler, front-loaded with the primary verb and resource. The only weakness is that the third capability (chunk generation) is tacked on as an aside rather than structured as a distinct mode.

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?

A mutating, multi-mode tool with nested options, no annotations, and no output schema leaves important questions open: what is returned, whether chunk generation is opt-in via options.generate_chunks or automatic, and how this differs from rag_chunk. The description stops short of what an agent needs to invoke it confidently.

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 67%, above the baseline threshold, and the description adds no parameter meaning beyond the schema — resource_type's enum, the data object, and all five options flags are documented in the schema itself. Baseline 3 is appropriate; it does not compensate for the undocumented remainder.

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 (normalize/standardize) and the three things it acts on: markdown formatting, field values, and RAG chunks. However it names no sibling, which matters here because 'generates chunks for RAG indexing' overlaps with rag_chunk in the sibling list, so the agent cannot tell which to pick.

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 preconditions, and no alternatives. The overlap with rag_chunk is left entirely unaddressed, and it never says whether this should run before validate_entry or instead of it.

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 provided, the description carries the full behavioral burden. It discloses that answers come 'with citations' and that the tool is a RAG chatbot, which is useful context beyond the name. However, it does not describe statefulness, how conversation history is handled, authentication needs, or whether it is read-only.

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 with no wasted words. The purpose is front-loaded and the second sentence adds the domain and return characteristic without redundancy.

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?

The description covers the basic purpose and citation behavior, but for a conversational tool with no annotations and no output schema, it lacks detail on how to manage multi-turn history (the 'history' parameter) or how top_k affects retrieval. It is minimally adequate but leaves notable behavioral gaps.

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 the schema already documents all three parameters (message, top_k, history). The description adds no additional meaning or usage guidance for any parameter, which is the baseline expectation when schema coverage is complete.

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 ('Chat', 'Ask questions') and resource ('Open5e RAG Developer Chatbot') and scope ('about Open5e API development'), and mentions the return type ('answers with citations'). It distinguishes itself from pure retrieval siblings like rag_search or rag_chunk by being conversational, but it does not explicitly name or differentiate from any sibling tool.

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 context 'Ask questions about Open5e API development' implies when to use this tool, but there is no explicit guidance on when to choose it over sibling tools such as rag_search, rag_chunk, or rag_sources. No exclusions or alternatives are stated.

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 provided, so the description carries the full burden. It does not state whether retrieval is read-only-safe, what happens if the ID is not found, whether results are cached, or anything about error behavior. A single clear verb is not enough behavioral disclosure for a zero-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?

One sentence, front-loaded with the verb and resource. Nothing superfluous.

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 single-param retrieval tool this covers the minimum, but with no annotations, no output schema, and multiple RAG siblings, the definition should clarify when to pick it over rag_search/batch_get and what it returns or errors on.

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%, and the one parameter is documented in the schema. The description merely restates 'by ID' without adding format, length, or source-context details beyond the schema, so baseline 3 applies.

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 ('Get') and resource ('a specific chunk from the RAG index') with scope indicator 'by ID'. Clear but does not distinguish itself from siblings like rag_search or batch_get beyond the singular-by-ID framing.

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?

Usage is implied by 'by ID' retrieval, but no explicit guidance on when to use this vs rag_search (search by content) or batch_get (multiple chunks). An agent can infer, but nothing routes it decisively.

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 behavioral burden. It does not say what 'health' comprises (liveness, latency, dependencies), what a failure response looks like, or whether the check is passive/read-only. A single sentence leaves significant behavioral gaps for a diagnostic 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?

One front-loaded sentence with no wasted words, appropriate for a simple zero-argument tool.

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 no-arg diagnostic tool with no output schema or annotations, the description is minimally viable but does not explain what the health result conveys or how to act on it. It is complete enough to invoke but thin on interpretation.

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 there is nothing for the description to clarify; the baseline for parameterless tools applies.

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 ('check') and resource ('Open5e RAG Developer Chatbot service health'), making the intent clear. It does not differentiate itself from the sibling 'health_check', which appears to target the same concern.

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 guidance on when to use this versus the closely related 'health_check' or 'rag_stats' siblings, nor any preconditions or exclusions. The agent is left to infer the 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?

No annotations are provided, so the description carries the burden; it does disclose the return shape (relevant code chunks with citations), which is useful given there is no output schema. However, it says nothing about permissions, rate limits, index freshness, or whether results are read-only safe beyond the obvious search semantics.

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 with zero filler; the purpose and the return shape are both front-loaded.

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 three-parameter read tool, the description covers purpose and return type (chunks with citations), and the schema covers all inputs. Missing only minor context such as index scope/staleness or guidance versus rag_chat, which is not decisive for calling 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?

Schema description coverage is 100%, so all three parameters (mode enum, query, top_k) are already fully documented in the schema, including defaults. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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 (Search) and resource (Open5e developer documentation RAG index), which clearly separates it from siblings like rag_health, rag_stats, and rag_sources. It does not explicitly distinguish itself from rag_chat or the generic search tool, so sibling differentiation is only partial.

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?

Usage is implied by the description (query the docs index to get code chunks), but there is no explicit when-to-use or when-not-to-use guidance. Given siblings such as rag_chat (likely conversational) and search (likely non-RAG), the agent must infer which to pick with no stated rule.

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 behavioral burden, and 'List all' only weakly implies a read-only operation. It says nothing about pagination, ordering, result size limits, or whether the listing can be large, which matters for a tool that enumerates an entire index.

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 tight sentence with no filler, and the resource being listed is front-loaded. It is efficient, though it is on the thin side rather than maximally informative.

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 zero-parameter list tool this covers the essentials, but with no output schema and no annotations, the description leaves the return shape and any volume/pagination behavior unspecified. It mentions GitHub URLs but not the other fields an agent would receive.

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 there is nothing for the description to disambiguate; the schema is trivially complete. Baseline 4 applies for a no-parameter tool.

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 ('List all indexed sources') and adds a content detail ('with their GitHub URLs') that helps an agent predict the output shape. It is reasonably distinguishable from siblings like rag_search or rag_stats, 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?

There is no guidance on when to use this versus rag_search, rag_chunk, or list_documents. The description simply asserts what the tool returns, leaving the agent to infer that this is the enumeration endpoint for browsing the index.

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 does not explicitly state that this is a read-only, side-effect-free call. That said, a parameterless "Get statistics" tool has minimal behavioral surface, and the enumerated return fields (source count, chunk count, embedding model) add useful disclosure.

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 front-loaded sentence that names the resource first and the payload second, with no wasted words.

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 the key metrics (source count, chunk count, embedding model), which is sufficient for a zero-parameter read tool. Only the when-to-use context against rag_health/rag_sources is missing.

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 the baseline is 4; there is nothing for the description to disambiguate. It correctly adds no redundant parameter discussion.

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 ("Get") and resource ("statistics about the Open5e RAG index") and enumerates the returned metrics, which clearly separates it from rag_search or rag_chat. It does not explicitly contrast with the closest siblings rag_health and rag_sources, so it falls short of a 5.

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 guidance on when to prefer this over rag_health or rag_sources, no prerequisites, and no exclusions. Usage is only implied by the tool name and the word "statistics".

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 behavioral burden. It adds one useful detail beyond the schema: results include frontend web URLs. However, it omits other key traits such as read-only nature, rate limits, authentication requirements, and pagination behavior (though the schema includes limit/offset parameters).

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 brief sentences, front-loaded with the core action and resource scope. The second sentence efficiently adds the return format detail. No filler or redundancy.

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?

The tool is moderately complex (5 parameters, no output schema, no annotations), and the description partially compensates by noting web URL results. However, it lacks usage guidance and behavioral details, leaving gaps that an agent would need to fill from the schema or external context.

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 five parameters are already documented in the input schema. The description adds no parameter-specific meaning, format hints, or defaults beyond what the schema provides, making the baseline score of 3 appropriate.

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: 'Search across Open5e resources (spells, monsters, etc.) with filters.' This clearly conveys the tool's function and scope, distinguishing it from generic list/get siblings. However, it does not explicitly differentiate itself from the sibling 'rag_search' or clarify when to prefer one search tool over the other.

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 mentions search supports filters but provides no guidance on when to use this tool versus alternatives like 'rag_search', 'list', or 'get'. No prerequisites, exclusions, or contextual triggers are given, leaving the agent to infer usage from the name and schema alone.

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 does not say whether validation is local or server-side, whether it mutates anything, what happens on failure, or whether errors are returned as data or thrown; for a tool with zero annotation coverage this is a real gap.

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 tight sentence with no filler, front-loading the action and the target. Nothing to trim.

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?

There is no output schema and no annotations, yet the description never explains what validation returns (an error list, a boolean, a 4xx on failure) or whether the input data is echoed back. For a validation tool whose entire value is its result, that is a significant omission.

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 three parameters including the resource_type enum and the strict flag are already documented. The description only adds the mild point that resource_type selects the governing schema, which is baseline-level value.

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 (validate) plus the resource (a draft entry) and the basis of validation (the Open5e schema for its resource type). It is distinguishable from siblings like normalize, diff, and check_slug, 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?

The word 'draft' hints at a pre-submission workflow, but there is no explicit when-to-use statement, no named alternative (e.g., normalize or diff), and no guidance on when strict mode should be turned on. An agent must infer the workflow entirely.

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