docs

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful context beyond those annotations by clarifying that the returned version refers to the published release, not the installed client, which prevents a common misuse.

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 filler. The core purpose is front-loaded, and the important caveat about installed client versions follows immediately. Every word 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 parameterless read-only tool with strong annotations, the description fully covers the tool's purpose, scope, and key assumption. No output schema exists, so detailed return-shape documentation is not expected, and nothing essential 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?

There are zero parameters, so the baseline is 4. The description references what the tool returns (version and release artifacts), which is sufficient given no input is required.

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 ('Read'), a clear resource ('current published Empryo version and available release artifacts'), and is clearly distinct from the documentation-focused sibling tools. An agent can immediately understand what this tool does without opening the schema.

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?

It provides clear context: this tool reports the published release, and it explicitly warns against assuming the installed client matches. It doesn't name alternative tools, but the sibling tools are documentation reads, so the usage boundary is mostly clear.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral detail about the two modes (page list vs. one page's sections/export URLs), though it does not disclose return format, pagination, or error behavior.

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 entire description is one front-loaded sentence that states the main action first and the parameter-dependent alternate mode second. There is no filler, repetition, or reference to structured data that is already visible.

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 tool with one optional parameter, no output schema, and no nested objects, this description is largely sufficient: an agent can call it with or without page and understand the nominal result. It is only slightly incomplete in not prescribing return formatting or when to prefer sibling read/search tools.

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 explain the 'page' parameter, and it does: the phrase 'of one page' clarifies that providing page switches the call into the sections/export-URL mode. This goes beyond the raw schema pattern, though it stops short of specifying accepted page values or output details.

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: it 'lists Empryo documentation pages' and distinguishes a second mode for one page's sections and export URLs. This separates it from read_docs and search_docs by operation and from current_release by resource scope.

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 explicit guidance about when to use list_docs versus read_docs or search_docs, and no exclusion conditions. The intended usage can be inferred from the verb 'list', but the description leaves all routing decisions to the agent.

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?

Annotations already establish the tool is read-only, idempotent, and non-destructive. The description adds meaningful behavior beyond that: it can return a full page or an exact section, supports two text formats, and defines the 'empty anchor' default. It does not describe error behavior, but the annotation coverage lessens that burden.

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 deliver the core action, output format, and the key selector/anchor usage rule with no filler. The most important behavioral detail, full page vs exact section, 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?

The description is complete for a read-only docs tool: it covers scope, output format, selector usage, and the essential default for anchor. A small gap is that it does not state what happens when 'format' is omitted, but the schema and sibling references make the tool callable without that detail.

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?

With 0% schema description coverage, the description carries full parameter meaning and does so well. It explains that 'page' is a docs page chosen via selectors, 'anchor' selects an exact section with empty meaning introduction, and 'format' maps to Markdown or plain text. This goes beyond the raw schema and gives actionable guidance for all three parameters.

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 names a specific verb ('Read'), resource ('Empryo docs page'), and scope ('full page' or 'exact section'), and clarifies output formats ('Markdown or plain text'). It also creates separation from the sibling search/list tools by saying selectors are returned by those tools, so the agent knows read_docs is for retrieving content, not for discovering it.

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?

It gives clear workflow context: use selectors returned by search_docs/list_docs, and an empty anchor means the introduction. This implies when read_docs should be used after searching or listing, though it does not explicitly state an exclusion like 'use search_docs to find pages.'

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?

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds useful behavioral detail by specifying the return content (exact selectors and citation URLs), but it does not disclose other relevant behavior such as pagination behavior with the limit parameter or any absence guarantees if the search fails.

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 two short sentences with no filler. It front-loads the action, states the target resource, and then specifies the return value. Every word 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?

Given the simplicity of the tool, the rich annotations, and the straightforward schema, the description is nearly complete. It covers purpose and output format, and safety is already covered by annotations. The only minor gap is lack of guidance on limit usage or result shape beyond selectors and citations, but the description is sufficient for a search tool of this 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?

The schema has 0% description coverage and the description does not meaningfully compensate. The term 'query' is implied by 'Search', but the description does not explain the meaning of the required query parameter, how the limit parameter affects results, or how queries should be formulated. With two parameters and no schema descriptions, more parameter guidance is needed.

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 ('Search'), a clear resource ('current Empryo documentation'), and the output ('exact page and section selectors and citation URLs'). This clearly distinguishes it from sibling tools like list_docs and read_docs, which would list or read documentation content rather than search it.

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 makes it clear that this tool is for searching current documentation, which implies when to use it. However, it does not explicitly mention alternatives such as list_docs or read_docs, nor does it state conditions for when to prefer one over the other. The usage context is implied rather than explicit.

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