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

With no annotations, the description carries the full burden. It discloses that it's a background, resumable download, extracts tar.gz files, reports multi-GB transfer progress via job_status, and runs on the machine hosting the MCP server. These are critical behavioral traits. It omits permission or storage requirements but covers the key operational details.

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 tightly packed sentences, front-loaded with the core action and constraints. No filler, highly efficient.

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?

An output schema exists, so return values need not be explained. However, with six parameters at 0% schema coverage, the description omits crucial details for dest, extract, filename, and force_reextract. It covers the high-level behavior and name/url parameters well but is incomplete for safe, correct invocation.

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 0%, so the description must compensate. It explicitly explains the name and url parameters and clarifies how to obtain the name. It does not address dest, extract, filename, or force_reextract, leaving half the parameters undocumented. Baseline of 3 is appropriate for partial parameter guidance.

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 (download) and resource (Serpent data library) with explicit scope. It distinguishes itself from the sibling list_data_libraries by noting that the name parameter should come from that list.

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?

Clear context: use name from list_data_libraries or an explicit url. Does not state when NOT to use it or mention alternatives for verification, but provides sufficient routing guidance for this download tool.

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 is transparent about the return payload (syntax, params, notes, doc link) and the operation is clearly a read-only documentation lookup, so risk is low. It says nothing about case sensitivity of the name, error behavior for unknown cards, or any auth/rate constraints.

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 waste, with the capability statement front-loaded and the examples placed second to clarify accepted inputs. Nothing is padded.

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?

An output schema exists, so return values need not be detailed, and the one required parameter is illustrated with examples. For a simple single-argument lookup the description is nearly sufficient; only the exact name-format rules are 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?

Schema description coverage is 0% for the single 'name' parameter, so the description must compensate. It partially does by supplying concrete example values including a multi-word form ('set acelib'), which hints at the accepted input format. It still does not state whether the 'set ' prefix is required, whether names are case-sensitive, or how aliases resolve.

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 enumerates exactly what is returned: exact syntax, parameter list, notes and documentation link, for a Serpent input card or set option. The examples ('surf', 'mat', 'set acelib') make the resource concrete. It does not explicitly contrast itself with the sibling list_cards, so it stops 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?

Usage is implied by the examples — an agent infers this is the lookup tool for a single known card or option name. There is no explicit statement of when to use this versus list_cards, get_reference or search_docs, and no exclusions or prerequisites are given.

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 what is detected and returned, which implies a read-only diagnostic, but it does not explicitly state whether the operation has side effects, whether the optional refresh changes cache state, or what permissions are needed.

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 with no filler; the scoping statement is front-loaded and the usage condition follows directly. Every sentence 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?

An output schema exists, so the description need not explain return values, and it already lists the main environment details. It gives clear usage context. The only notable omission is the meaning of the optional refresh parameter, which is minor for this diagnostic 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?

The schema has one parameter (refresh) with 0% description coverage, and the description does not mention refresh at all. It therefore adds no meaning beyond the schema for the only input, which is a clear gap.

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 ('Show') and enumerates the exact environment details returned: Serpent executable, version, CLI flag style, data libraries, server configuration, and documentation cache status. This distinguishes it from siblings like list_data_libraries or search_docs, which serve narrower purposes.

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 explicitly states when to call it: 'Call this first on a new machine or when a run fails with ‘sss2 not found’.' This gives clear triggering conditions, but does not name alternatives or state when not to use 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, the description carries the full burden, and it does disclose the important behavioral trait that the tool operates in two modes: a listing mode with no argument and a 'best match' retrieval mode with a topic. It does not describe permissions, ambiguity handling when no example matches well, or anything about result size, so the disclosure is partial.

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, no filler, with the enumeration and the conditional behavior front-loaded. Every clause 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 one-optional-parameter tool with an output schema already defining return shape, the description covers both invocation modes adequately. Only the topic-matching semantics remain underspecified.

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% and the single 'topic' parameter is undocumented in the schema, but the description compensates by explaining its effect: supplying a topic changes the output from a list to the best-matching example content. This is meaningful added semantics, though it omits matching behavior (fuzzy? exact?) and the null default's meaning.

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 bundled Serpent input examples') and enumerates the concrete example categories (pin cell, shielding, burnup, group constants, minimal sphere), so the agent knows exactly what comes back. It does not explicitly contrast itself with siblings like get_reference or search_docs, 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?

The description implies usage through its dual-mode sentence ('With topic, return the best matching example content'), but it never states when to prefer this tool over get_reference, search_docs, or get_card, nor any exclusion. Usage is inferable rather than guided.

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 disclosure burden. It does convey that this is a static curated read-only reference and lists its breadth, but it does not say what happens for an unrecognized topic (error vs. full reference), nor whether the result is cached or static. Adequate but incomplete for an 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 sentences, front-loaded with the purpose and followed by the parameter guidance. The long parenthetical topic enumeration is dense but each item adds real scope information, so there is little waste.

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?

An output schema exists, so return-value format need not be described, and the tool is simple with one optional parameter. Between the enumerated coverage and the parameter examples, an agent has enough to call it correctly; only the invalid-topic behavior is left open.

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, and it does: it names the single parameter, marks it optional, and supplies four concrete example values. It falls short of an authoritative topic list ('e.g.' implies open-ended), and 'versions' appears in the examples but not in the enumerated content list, a minor inconsistency.

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 ('Return the curated Serpent 2 quick reference') and enumerates the exact subject areas covered, which makes the scope unambiguous. The word 'curated' implicitly separates it from search_docs/get_card, but it never names a sibling to make the boundary explicit.

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 second sentence explains how to use the optional parameter ('Optionally request one topic'), which is implied usage guidance. It says nothing about when to prefer this reference over search_docs, get_card, or get_examples when an agent needs Serpent 2 knowledge, and no exclusions or prerequisites are given.

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 full burden. It mentions default file selection and optional summaries, but does not disclose error handling if no _res.m exists, permission requirements, whether reading is destructive, or the format of returned data. Crucial behavioral traits remain undocumented for a tool claiming to 'read' files.

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 sentences, front-loading the main action and default behavior, then quickly covering return values and a parameter tip. It is efficient with no wasted words, though it could be slightly more structured with bullet points for return values.

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?

An output schema exists, so return values need not be fully detailed, but the description must cover parameter usage and behavioral aspects. With 6 parameters at 0% schema coverage and no annotations, the description is incomplete: it omits guidance on 5 parameters and fails to describe error conditions or output format. The existing output schema mitigates some need, but the overall definition leaves an agent guessing about key invocation details.

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 0%, and the description only partially compensates by explaining the 'variables' parameter ('Use variables=[...] to extract specific _res.m variables') and implying 'file' or 'workdir' via defaults. Five other parameters (file, input, workdir, max_rows, sections) receive no explanation, leaving significant gaps for an agent to interpret their purpose.

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 and resource: 'Read and summarise Serpent output files', naming the exact file type (_res.m) and the specific outputs returned (k-eff, run parameters, integral rates). It distinguishes itself from sibling tools like plot_results and job_output by focusing on Serpent result extraction, though it could more explicitly contrast with plot_results.

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 through default behavior ('Defaults to the newest _res.m') and a specific scenario for variables extraction, but no explicit when-to-use versus alternatives (e.g., plot_results or job_output) is provided. An agent must infer that this is for programmatic result reading rather than visualization.

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. Disclosing SIGTERM then SIGKILL for local jobs is genuinely useful behavioral context, but there is no mention of permissions, remote-job behavior, whether the operation is idempotent, or what the true final state 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 front-loaded sentence with zero filler that earns every clause by including the signal escalation detail.

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?

An output schema exists, so return values need not be explained, and the description covers the core destructive behavior and signal sequence. It stops short of permissions, idempotency, and remote-job handling, leaving minor 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 0% for the single job_id parameter, so the description must compensate, and it does not say what a job ID looks like, where to obtain one, or what format it takes. Baseline 4 is overridden by the documented coverage gap.

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 ('Terminate') and resource ('running background job'), and gives the signal sequence, making it clearly distinguishable from read-only siblings like job_status or job_output.

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 name and 'running background job' scoping, but there is no explicit when-to-use guidance or mention of alternatives (e.g., job_status for inspection before killing).

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 behavioural burden. It mentions 'tail of the run log' which hints at the tail_chars default behavior, but does not disclose whether this is a safe read-only operation, whether partial output indicates job completion, or any other behavioral traits.

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 that front-loads the action and scope. 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?

An output schema exists, so return values need not be explained. However, with no annotations and 0% schema coverage, an agent still lacks clear guidance on permissions, whether the operation is read-only, and parameter details. Adequate but with clear 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 0%, so the description should compensate. It implies tail behavior ('tail of the run log') which gives some meaning to the tail_chars parameter, but job_id is entirely undocumented and no format or range details for tail_chars are given. Marginal value added, but does not fully compensate for the coverage gap.

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 ('Read') and resource ('log output from a background job'), and clarifies the scope with 'tail of the run log'. This is distinct from job_status and job_kill among siblings, though it doesn't explicitly name those alternatives.

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 'Read more log output' implies this is a follow-up for fetching incremental output, and 'background job' implies it applies only to asynchronous runs. However, no explicit when-to-use vs job_status or job_kill guidance is provided.

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, but an output schema exists, so the enumeration of returned fields (state, exit code, progress, log output) is largely redundant with structured data. The description does not state read-only semantics, whether calls block or poll, or how an unknown/expired job_id is handled, leaving the main behavioral burden unmet.

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 the core capability front-loaded and the mode-switching condition second; no filler, no restatement of the tool name.

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 2-parameter, zero-required, read-only-style tool with an output schema, the description covers modes, states, and what is returned. The only real omission is the meaning/default of 'tail' and any indication of error handling for invalid job IDs.

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 0%, so the description must carry parameter meaning. It explains job_id well (absent means list mode instead of detail mode), but 'tail' is never mentioned — its role as the log-line count is only weakly implied by 'recent log output,' leaving one of two parameters effectively undocumented.

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 ('Check') and resource ('background job state') and enumerates the possible states (running/finished/failed/lost), which helps an agent distinguish it from siblings like job_kill or job_output. It also discloses the dual behavior (state lookup vs. listing when job_id is absent), though it never names the sibling tools it is not.

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 an explicit conditional: 'Without job_id, list the most recent jobs,' which tells the agent how to trigger the listing mode. It does not name alternatives (e.g., job_output for full logs, job_kill to terminate), so the agent must infer when to prefer those tools.

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, and it does disclose the filtering behavior and the discovery intent. However it says nothing about scope limits, pagination, or whether set options and cards are returned in the same shape. For a read-only listing tool this is adequate but thin.

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, no filler, with the listing scope front-loaded and the usage caveat second. Every clause carries 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?

An output schema exists, so return values need not be described, and the description covers scope and filtering. It is nearly complete for a simple list tool, missing only clarification of what the enum values mean in practice.

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% and the single 'kind' parameter has only a default of 'all' documented. The description compensates by spelling out the accepted values (card|set|all), which is the key semantic the schema omits. The only gap is that it doesn't say what 'set' vs 'card' actually selects.

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 known Serpent input cards and set options') and names the optional filter. The discovery framing implicitly distinguishes it from the single-item sibling get_card, though it never names that 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?

Gives a clear when-to-use condition ('Useful for discovery when the exact name is unknown'), which is exactly the situation that routes an agent here over get_card or search_docs. It stops short of naming the alternatives or stating when not to use 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?

No annotations, so description must carry full burden. It discloses that entries include key, title, size, URL, and file name, which tells the agent what it gets. However, no info on filtering, pagination, or return format beyond that. Output schema exists, so return format is partly covered.

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, front-loaded with the core action and scope. 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 zero-param list tool with an existing output schema, the description is complete: it states what is listed and what each entry contains, which is sufficient for correct invocation.

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?

No parameters, so baseline 4. The description correctly implies no input is required and provides context about what the output contains.

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?

Specific verb+resource: 'List the official VTT Serpent nuclear data libraries that can be downloaded'. It enumerates examples and names the sibling (download_data_library) implicitly by contrasting available vs downloadable libraries.

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?

Clear context – this tool surfaces libraries that can be downloaded, while download_data_library performs the download. No explicit when-not-to-use or exclusions, but the purpose is unambiguous.

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 does disclose the key side effect ('Returns the path of the written image'), which tells the agent a filesystem write occurs, but it says nothing about where the file lands, whether it overwrites an existing output, permissions, or whether the source data must already exist from a prior run.

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 dense sentences with zero filler: the purpose leads, then the per-kind requirements, then the return value. Every clause carries information an agent needs before calling.

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?

An output schema exists, so the return-path sentence is arguably redundant, and the description need not restate return structure. But for a 9-parameter, annotation-free tool with 0% schema coverage, more than half the parameters remain semantically opaque, leaving the agent under-informed for a write-side-effect operation.

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% across 9 parameters, so the description must compensate. It explains the required 'kind' values and the conditional dependencies ('detector needs name', 'variables needs x and y'), which is meaningful semantic content, but leaves file, input, output, workdir, and lang entirely undefined.

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 ('Draw a PNG plot from Serpent output') that clearly separates it from the sibling set (run, get_results, job_output, etc.), which contains no plotting tool. It stops short of explicitly naming an alternative it might be confused with, but the 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?

The kind enumeration functions as de facto usage guidance: it tells the agent which kind to pick (detector, keff, burnup, variables) and the conditional prerequisites for two of them. However, there is no guidance on when to reach for plot_results versus the sibling get_results or job_output, nor any prerequisite/ordering 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 supplied, so the description carries the full behavioral burden. It does disclose the async/background nature, that the job id is returned, that validation runs by default, and that force=true bypasses it. It says nothing about error/failure behavior, whether jobs are cancellable or resource-limited, backend selection implications, or permissions, leaving substantial behavioral gaps for a mutation/launch 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?

Three tight sentences, front-loaded with the action and return value, with the validation/force note before the trailing parameter hints. Efficient, though the terse 'options: extra CLI flags' fragment and the missing mention of validate_first cost some clarity.

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?

An output schema exists, so the job-id return need not be explained in depth, and the description correctly covers validation and flag convenience. But for an 8-parameter launcher with zero schema coverage and no annotations, omitting backend, workdir, and validate_first leaves an agent without enough to invoke it confidently in non-default configurations.

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 0% across 8 parameters, so the description must compensate. It explains force ('skip validation'), options (CLI flags, e.g. ['--noplot']), and characterizes omp/mpi_tasks as 'convenience shortcuts,' which is genuine added meaning. But backend, workdir, and validate_first are entirely undocumented, and the relationship between force and validate_first is left ambiguous.

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 and resource: 'Start a Serpent calculation as a background job and return its job id.' This clearly separates it from the job-management siblings (job_status, job_output, job_kill) without naming them. It stops short of an explicit contrast with validate_input or get_results, so a 4 rather than 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?

It conveys the triggering context ('long runs must not block') and the validation default, which implies this is the launcher for non-blocking runs. However, it never states when to prefer validate_input first, when to use job_status to follow up, or what happens if validation fails, so usage is only implied.

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 must carry the behavioral burden. It usefully discloses the return shape ('matching sections with source links') and that the corpus is an index (hinting at the sync_docs dependency), but says nothing about pagination/limit behavior, result ranking, index staleness, or that the operation 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?

Three compact sentences, front-loaded with purpose and scope, then the enum values, then the return shape. No filler or repetition.

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?

An output schema exists, so return values need not be spelled out. The critical enum ambiguity in the schema is resolved by the description, and purpose is clear; the only residual gap is the undocumented 'limit' parameter and the absence of any read-only/side-effect statement.

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 0% and the schema leaves 'kind' as a bare string with no enum, so the description's enumeration 'all|card|guide|extra|wiki' adds real meaning the schema does not provide. It also clarifies that 'query' is a full-text query; only 'limit' remains undocumented by both schema and description.

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 (full-text search) and resource (indexed official Serpent documentation), and enumerates the covered corpora (syntax manual, user guide, appendices, wiki). An agent can distinguish it from retrieval siblings like get_reference, get_card, get_examples, and from the index-management tool sync_docs.

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 phrase 'indexed official Serpent documentation' suggests this is the tool for fuzzy lookup across all docs, versus the more targeted get_* siblings. There is no explicit when-to-use statement, no when-not, and no named alternative for cases like fetching a known reference or example.

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 load. It usefully discloses that the sync runs in the background (non-blocking) and returns sync status, which is genuine behavioral context. It omits idempotency, whether re-running is safe, permission/auth requirements, and potential rate limits on the upstream docs source.

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, action first, with no filler. Slightly redundant to state 'Returns current sync status' when an output schema already exists, but the structure is front-loaded and efficient.

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?

An output schema exists, so return values need not be spelled out. However, the undocumented force parameter and the absence of any guidance on when this lengthy background sync should be triggered leave the definition minimally adequate for an agent to call it competently.

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 is a single 'force' boolean with 0% schema description coverage, and the description never mentions it. The 'trigger or refresh' wording hints faintly at a first-run vs re-run distinction but gives no rule for when force=true is needed, so the parameter's semantics remain unexplained.

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?

Clear specific verb+resource: triggering/refreshing the Serpent documentation cache. An agent can distinguish it from read-only siblings like search_docs or get_reference. It does not, however, explicitly name those siblings or when to prefer this over 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 phrase 'trigger or refresh' implies use when the cache is missing or stale, but there is no explicit when-to-use, no mention of when not to call it, and no routing to alternatives like search_docs. It also never explains when the force parameter should be set.

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 burden and does well: it discloses that the deeper mode invokes an external process (`sss2 -noplot -norun`) and that this only happens 'when the executable is available', which is real environmental/behavioral context. It does not state that validation is non-mutating or how long the external run may take, but the key conditional behavior is surfaced.

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 dense but front-loaded sentences: the core validation purpose and its checks come first, with the optional deep mode second. No filler, though the first sentence packs a long enumeration that could be trimmed slightly.

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?

An output schema exists, so return values need not be described, and the check inventory is thorough. The gap is the unexplained text/input parameter pair and the undefined intermediate levels, which an agent needs to choose arguments correctly for a 4-param 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 0%, so the description must explain all four parameters. It partially covers level and run_norun, but the critical distinction between the `text` and `input` parameters (raw text vs. file path?) is left entirely unexplained, and the meaning of level values below 3 is absent.

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 ('statically validate a Serpent input file') and enumerates the actual checks performed (known cards/options, duplicate names, undefined references, unit mixing, source/neutron-mode consistency). This clearly separates it from execution-oriented siblings like run and job_status, since it is explicitly static.

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 a concrete condition for the deeper mode ('level=3 (or run_norun=true) also runs sss2...'), which is useful routing within the tool. However, it never says when to reach for validate_input rather than run or get_reference, nor what levels 1 and 2 mean, so the when-to-use guidance is only implied.

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