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

With no annotations, the description carries the burden and discloses useful traits: parsing modes, error behavior (rejects non-protein with a structured error naming the detected type), and operational profile (free, local compute). It stops short of explicitly confirming read-only/no side effects, but local compute strongly implies it.

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 short sentences, front-loaded with what the tool computes, then input/error behavior, then a terse operational note. Every phrase earns its place with no 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?

An output schema exists, so return values need not be described. But with no annotations and 0% parameter description coverage, the unexplained is_file behavior leaves the definition incomplete for correct invocation, especially when passing raw text.

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 3 parameters, so the description must compensate. It clarifies that source can be a FASTA file or raw text and mentions sequence_index for record selection, but never explains the is_file boolean (default true), which determines whether source is treated as a file path or raw sequence. That gap can cause incorrect invocation.

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 resource and output set (MW, aa composition, charge, GRAVY, pI) and the input modes (FASTA file or raw text). It does not explicitly name or distinguish a sibling such as fasta_stats or propka_summary, 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?

Usage is implied by the protein-specific scope and the explicit exclusion of non-protein sequences, which are rejected with a structured error. However, the description gives no guidance on when to choose this tool over siblings like fasta_stats or propka_summary.

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 does well: it discloses the premium/API-key auth requirement, a 24-hour disk cache, and that refresh=True forces a live fetch. It does not describe return contents, but an output schema exists, so that omission is acceptable.

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 short sentences, front-loaded with the core action, followed by the auth and caching constraints. Every sentence earns its place with no filler.

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 read-only fetch tool with an output schema covering returns, the description supplies auth requirements, caching semantics, and parameter meaning. It is nearly complete; only the sibling disambiguation 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?

Schema coverage is 0%, so the description must compensate, and it does: 'for a UniProt accession' gives the accession parameter concrete meaning, and 'refresh=True forces a live fetch' explains the refresh boolean's effect. This is meaningful semantic coverage over a bare 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+resource: fetching the AlphaFold DB model for a UniProt accession and summarizing its pLDDT confidence profile. This is clear and specific, but it does not distinguish itself from the sibling plddt_summary, which an agent might reasonably confuse it with.

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 a prerequisite hint (premium tool, API key required) but no explicit when-to-use vs alternatives guidance. The overlapping sibling plddt_summary is never mentioned, so the agent must infer which tool to pick when both could apply.

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 behavioral trait — that clear=True empties (mutates/destroys) the cache — which is real value. However it says nothing about consequences of clearing (lost responses, re-fetch cost), permissions, or irreversibility.

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 tightly written sentence, front-loaded with the primary action, with the destructive variant clearly bracketed. 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?

For a single-parameter utility with an output schema (so return values needn't be explained), this is nearly complete: it names what is cached and the clear behavior. A brief note on whether clearing is safe/reversible would close the remaining gap.

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 'clear' boolean has no schema description, so the description must compensate — and it does, explaining that clear=True empties the cache (default False = inspect). That is the essential semantics for the only parameter.

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 ('Inspect'/'empty') and resource ('local response cache'), and scopes it to the premium lookup tools (UniProt / AlphaFold DB / RCSB). No sibling tool touches the cache, so the agent can identify this uniquely from the name plus description.

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 parenthetical 'with clear=True, empty' implies the two usage modes, but there is no explicit when-to-use guidance, no statement of when clearing is appropriate, and no exclusions or alternatives named. 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?

With no annotations, the description carries the behavioral burden and does well: it discloses what is reported (sigma/epsilon values or MISSING entries), the failure mode it guards against, and its workflow position. It leaves read-only/local-scan nature implicit rather than stated, so not a 5.

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 no filler, and the scan-and-report behavior is front-loaded ahead of the prerequisite guidance.

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 no explanation, and the pre-flight purpose is fully covered. The only gap is the undocumented metals parameter, which leaves a small hole for a 2-parameter 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 compensate. It explains ff_path well (a force-field directory or .itp/.ff file), but the metals parameter and its 'ZN,FE' default are never mentioned in the description—the 'e.g. ZN, FE' example hints at it without documenting the parameter or its comma-separated syntax.

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 (scan) plus the exact resource (GROMACS force-field directory or .itp/.ff file) and the output content (sigma/epsilon or MISSING entries). It is easily separable from sibling tools like metal_geometry and query_metal_sites, which deal with sites/geometry rather than force-field atomtypes.

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?

Explicitly says to run this BEFORE pdb2gmx on any metalloprotein, and gives the consequence of skipping it (a missing metal atomtype kills the topology build). It does not name alternative sibling tools or state when-not to use it, so it falls short of a full 5.

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 core transformation (overlaying one value column across multiple files) and the output artifact (a comparison PNG). It is silent on defaults, what happens when column indices differ, error behavior for unreadable paths, and file-overwrite semantics for out_png, which matters for a writing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the resource and output are stated before the clarifying example. Efficient, though it could have spent a few more words covering the undocumented parameters.

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, which lowers the bar. Still, for a 6-parameter tool with zero schema descriptions and zero annotations, the definition leaves the majority of parameters and all write-side behaviors 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 0% across 6 parameters, so the description must compensate and largely does not. It clarifies that xvg_paths is comma-separated (a genuinely useful addition) and implies value_column selects the plotted data, but title, labels, out_png, and y_from_zero are left entirely 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?

States a specific verb (overlay) and resource (value column of several .xvg files) with a concrete output (one comparison PNG). The word 'several' and 'comparison' implicitly separate it from the sibling plot_xvg, though that sibling is never named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical example 'apo vs holo RMSD' gives a clear use context, so the intended scenario is inferable. However, there is no explicit when-to-use statement or any guidance on when to prefer this over plot_xvg or xvg_summary.

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, yet it only enumerates output metrics (plateau status, late-run means, drift, relative difference) that the output schema already covers. It says nothing about side effects, read-only nature, what happens with incomplete runs, or failure 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?

A single front-loaded sentence that names the operation, the two inputs, and the returned verdicts with zero filler. 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 two-input comparison tool with an output schema, the description is minimally adequate: the return values are covered elsewhere and the core purpose is stated. However, with no annotations and no parameter documentation, it leaves open whether the tool performs fresh computation, what the directories must contain, and how mismatched or partial runs are handled.

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 parameters are bare ('Dir A', 'Dir B'), so the description must compensate. It adds only that these are 'run directories' with a loosely illustrative 'apo vs holo' example, but gives no path format, structure expectations, or ordering semantics for the two arguments.

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+resource ('Side-by-side RMSD verdicts for two run directories') plus an example of the comparison axis (apo vs holo), so an agent knows exactly what it computes. It does not explicitly distinguish itself from nearby siblings like rmsd_summary or compare_plot, which keeps 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?

There is no statement of when to use this versus rmsd_summary (single-run RMSD) or compare_plot, and no prerequisites such as whether both directories must already contain completed analyses. Usage is only implied by the word 'compare'.

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 usefully discloses that it reuses the premium UniProt fetch (same key + relay/local path as uniprot_entry) and that positions are 1-based canonical, which is real behavioral context. However it omits auth/rate-limit implications of the 'premium fetch' and error behavior, 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?

Purpose is front-loaded in the first line, and the remaining lines add the fetch-path detail and the alignment prerequisite. It is appropriately sized for a single-parameter tool, though the mixed line breaks make it read a little densely.

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 output schema exists, return values need not be described, and the description correctly focuses on purpose, prerequisite workflow, and returned feature categories. For a one-parameter, unannotated read tool this is largely complete, with only auth/caching behavior left implicit.

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 there is one required parameter, so the description must compensate. 'For a UniProt entry' implies the argument is a UniProt accession/id, but no format, examples, or edge cases are given. It adds marginal meaning beyond the parameter name.

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 resource and output: a feature table (conservation/functional hint) for a UniProt entry, with named feature categories. It also distinguishes itself from the sibling uniprot_entry by noting it reuses the same fetch path. This is clear, though the primary verb is implied rather than stated outright.

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 prerequisite workflow — 'Align your PDB sequence first (sequence_from_pdb + read_fasta) before mapping positions' — naming the sibling tools to run first. It does not state when to prefer this over uniprot_entry directly, so exclusions are absent, but the contextual guidance is concrete.

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 usefully discloses the dual input modes (is_file=True/False) and that output includes confidence and notes, but says nothing about limitations such as behavior on multi-sequence input, how sequence_index affects selection, or error handling.

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 short, front-loaded sentences with zero filler: purpose first, then input modes, then return content. 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 return values needn't be re-explained, and the description correctly focuses on inputs and the classification categories. It is nearly complete, with only sequence_index semantics and multi-sequence handling left 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 0%, so the description must compensate. It clarifies the source/is_file relationship well, but the sequence_index parameter (default 0) is never mentioned, leaving one of three parameters semantically 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?

States a specific verb ('Detect') and resource ('FASTA sequence') and enumerates the exact classification outputs (protein, DNA, RNA, ambiguous, unknown). This clearly distinguishes it from siblings like read_fasta, fasta_stats, and aa_composition, which read or summarize rather than classify type.

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 explains the two input modes (file path vs raw text via is_file), which implies how to invoke it, but gives no explicit when-to-use guidance versus alternatives like read_fasta or fasta_stats. Usage context is implied rather than 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?

With no annotations, the description carries the full burden. It usefully discloses one real edge behavior — GC% is restricted to DNA records and returns null with a note otherwise — plus the zero-cost local execution profile. It says nothing about error handling for a missing/unreadable source or how the tool behaves on mixed or non-sequence input, leaving meaningful behavioral gaps.

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 lines with the most important information (the metric set) front-loaded and no filler. The trailing fragments ('Free; local compute.') are information-dense rather than wasteful, though their telegraphic style is slightly abrupt.

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. But for a 2-parameter tool with zero schema coverage and no annotations, the description omits how 'source' and 'is_file' interact, which is the main thing an agent needs to call 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 coverage is 0%: the two parameters ('source', 'is_file') have only titles and a default, no descriptions. The description does not mention either parameter, so it fails to clarify the critical distinction between source-as-path versus source-as-inline-sequence implied by is_file=true.

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 the resource (multi-FASTA) and enumerates the exact outputs (N50, length stats, per-type counts, GC%), which makes it unmistakable against siblings like read_fasta or aa_composition. However, it never explicitly contrasts itself with those siblings, which is the bar for 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 only implied — an agent infers 'call this to summarize a FASTA file.' The 'Free; local compute' note gives a useful cost/local-vs-server signal for tool choice, but there is no statement of when to prefer this over alternatives (e.g. read_fasta, detect_sequence_type) or any exclusion.

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 does reasonably well: it discloses the FASTA parsing step, the type-to-program mapping (blastp/blastn), that PDB IDs are returned, that ambiguous sequences fail with a structured error, and that an API key is required (premium). Cost/rate-limit details and whether results are ranked are unstated.

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?

Four tight sentences, front-loaded with the core action and progressively adding mapping, error, and auth details. No filler; every sentence adds actionable 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-value explanation is unnecessary, and behavioral/auth context is present. However, for a 4-parameter tool with 0% schema coverage, the absence of any parameter semantics leaves a real gap an agent would need to fill.

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 explains none of the four parameters (source, is_file, max_results, sequence_index). The FASTA mention loosely touches source/is_file, but max_results and sequence_index are undocumented in both the schema and the 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+resource ('Find PDB structures matching a protein, DNA, or RNA sequence') and clarifies direction. It implicitly contrasts with the reverse-direction sibling sequence_from_pdb, but never names it or other related tools like rcsb_entry or detect_sequence_type.

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 workflow described (parses FASTA, maps to BLAST search), but there is no explicit when-to-use guidance or routing against alternatives such as detect_sequence_type, read_fasta, or sequence_from_pdb. The premium/API-key note gives some context but no alternative selection logic.

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 disclose the premium/hosted-relay prerequisite and the returned metrics, which is genuine value. But it never states that this is a read-only operation, whether it has side effects, or any rate/scope limits, so it falls short of full 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?

One tight sentence, front-loaded with the resource and immediately followed by the metric list and prerequisite. Every clause carries information with no filler.

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-value enumeration is somewhat redundant but harmless. The prerequisite is covered, yet the sole parameter is left undocumented and there are no annotations to carry safety/scope information, leaving a gap for an agent deciding how to call it.

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 parameter (db_path) with 0% schema description coverage, and the description says nothing about it — no default behavior, no format, no interaction with the hosted relay. With low coverage the description should compensate, and it does not.

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 resource (corpus-level stats for the PDB-wide metal-site index) and enumerates the content: entry/site counts, per-metal and per-geometry distributions, artifact volume. It implies differentiation from per-structure tools like structure_stats or metal_geometry via 'corpus-level'/'PDB-wide', but does not name a sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'premium: requires the hosted relay' note gives a prerequisite, which is useful usage context. However, there is no explicit when-to-use guidance versus the many sibling stats tools, and no stated conditions under which it should be avoided. Usage is implied by 'corpus-level' but not spelled out.

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 the newest-first ordering, which is genuinely useful, but says nothing about read-only semantics, pagination behavior once limit is reached, or permissions.

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 operation, ordering, and filter stated first, followed by a brief usage note. No filler; the most important information 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?

An output schema exists, so return values need not be described. However, for a tool with 0% parameter documentation and no annotations, the description should at least clarify valid 'kind' values and limit/pagination behavior to let an agent call 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 0% for both parameters. The description explains that 'kind' acts as an optional filter but never states what kind values exist (no enum, default is empty string), and it says nothing about 'limit' or its default of 20, leaving half the parameters undocumented in 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?

The description gives a specific verb and resource ('List recent registry entries') plus a sort order ('newest first') and an optional filter ('by kind'). It is clear what the tool does, though it does not explicitly position itself against siblings like run_details or log_run, which an agent must infer.

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?

'Use this at session start to recall project history' specifies a concrete situation for invoking the tool. There are no exclusions or named alternatives, but the usage context is clear enough for an agent to act on.

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 does disclose genuine behavioral context: the record is persistent across sessions, the tool returns the registry id, and metrics/paths tolerate JSON strings or plain text. It does not say whether a run_id collision overwrites or duplicates an entry, what status values are meaningful, or what authorization is needed for a write.

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?

Four short clauses, front-loaded with the core action and persistence scope, then parameter hints, then the return value. Every sentence carries information, though the format note about JSON strings could be folded more tightly.

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 (mentioning the registry id is a minor redundancy). For a zero-annotation write tool, the main remaining gap is idempotency/uniqueness behavior around run_id and the meaning of status, which an agent would need before logging reliably. Overall it is close to complete for its 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 0%, so the description must compensate, and it partially does: it explains 'kind' with concrete examples and clarifies the accepted format for 'metrics' and 'paths'. The remaining parameters (notes, run_id, status) receive no explanation at all, including the default 'logged' status and the identity semantics of run_id.

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 ('Record a run/event in the persistent project registry') with the cross-session memory intent in parentheses, so an agent knows this writes structured run history. It does not name or differentiate against obvious siblings like list_runs, run_details, or compare_runs, which are the read-side counterparts.

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 by 'persistent project registry (cross-session memory)' and the kind examples such as 'md_report', 'prep', 'hypothesis'. There is no explicit statement of when to call this versus md_run_report or list_runs, and no prerequisites or exclusions 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?

With no annotations at all, the description carries the full disclosure burden. It usefully reveals the composite nature of the checks, the GO/NO-GO verdict, and the blocking-issue semantics, but says nothing about compute cost, whether it touches the filesystem beyond reading, or any side effects of a pre-flight 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?

Three tight sentences, front-loaded with the tool's role, followed by the return contract and the required action. Every clause carries information; nothing is redundant filler.

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 no elaboration, and the gate semantics are conveyed. But for a two-parameter tool with zero schema coverage, the absence of any explanation of ff_dir and of what a NO-GO blocks leaves a real gap in call correctness.

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 does not name or explain either parameter. pdb_path is at least inferrable from "for a structure," but ff_dir is entirely opaque — its purpose (forcing a force-field directory) and the effect of its empty default are documented nowhere.

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+resource (an MD pre-flight gate for a structure) and enumerates the three checks it composes: PDB/mmCIF validation, metal-site detection, and force-field metal parameter check. This clearly differentiates it from siblings like validate_pdb and check_metal_params, which perform only one of those constituent steps.

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?

"Treat NO-GO as a hard stop before any GPU/MD launch" gives a clear usage context and prescribed reaction. However, it never explicitly contrasts itself with validate_pdb, metal_geometry, or check_metal_params, so the agent must infer that this tool supersedes those for a gate decision.

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 the verdict vocabulary (GO/FINISHED/INCOMPLETE/CRASHED) and the side effect of optionally logging to the registry, but never states whether it is read-only, whether it writes report files into the run directory, or what permissions/registry state the log step touches.

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 plus a short clause, with the resource and the output list front-loaded and no filler. The trailing 'Optionally logs to the registry' reads as an afterthought rather than being integrated, a minor structural blemish.

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 restated, and the description covers the report's scope and verdict taxonomy. Given the tool has a side effect (registry logging) and no annotations, more disclosure on mutation/reversibility and run_dir requirements would be needed for a 5.

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%, but with only two parameters the description mostly compensates: it maps the 'log' flag to 'Optionally logs to the registry', clarifying an otherwise opaque boolean, and the enumeration of artifacts implies what 'run_dir' must contain. It never spells out run_dir's structure or the log default, keeping it just short of full coverage.

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 ('Analyze') and resource ('a GROMACS run directory') and enumerates the concrete outputs it produces: RMSD verdicts, .xvg inventory, md.log crash scan, artifact presence, and a verdict. This makes clear it is an aggregate run-level report rather than the single-metric siblings like rmsd_summary or xvg_summary.

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?

Implies usage ('analyze a GROMACS run directory') but names no alternatives or when-not conditions, even though siblings such as rmsd_summary, xvg_summary, and compare_runs overlap with parts of what it computes. The agent can infer it is the whole-run option but gets no explicit routing guidance.

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 computational behavior (fits angles to ideal geometries, flags bidentate carboxylate chelates), but omits the safety profile, resource cost, and any preconditions; an output schema exists so most return detail is already covered elsewhere.

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?

Front-loads the core action in the first sentence, then enumerates the analysis steps compactly. No filler, though the multi-line formatting is slightly verbose for three parameters.

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 read-only nature is implied. The remaining gap is the undocumented cutoff_angstrom parameter and lack of routing against sibling metal tools, which is a real omission for an agent.

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 explains metal_element well with examples (FE, ZN, MN, MG), but says nothing about cutoff_angstrom (the coordination-distance cutoff, default 3) and nothing about the required pdb_path format.

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 ('Analyze') and resource ('metal-binding sites in a PDB file') and elaborates the exact scope: metal atoms, coordinating ligands with distances/donor types, L-M-L angles, and chelate flagging. However, it never distinguishes itself from the very similar sibling 'query_metal_sites' or 'check_metal_params', so an agent cannot route between them from this text alone.

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/when-not-to-use guidance and no mention of alternatives, despite two close siblings (query_metal_sites, check_metal_params). Usage is only implied by the phrase 'in a PDB file'.

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 usefully discloses the local-file check, what is returned (validation, sequence, metal sites), and the premium/API-key gating. However it omits the effect of the 'refresh' flag, caching behavior, and what happens when neither a local file nor an API key is available.

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?

Front-loaded with the core purpose, then supporting detail in two short follow-on sentences. No filler, though the line-broken formatting is slightly awkward.

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, and the description appropriately highlights the main categories anyway. But with no annotations and an undocumented 'refresh' parameter, the definition is only adequately complete for an agent to call it reliably.

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 conveys the 4-character format for pdb_id, but the 'refresh' parameter is entirely undocumented in both schema and description, leaving a real gap for a 2-param 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+resource: 'Get info about a PDB entry by its 4-character PDB ID,' and clarifies it works on local files plus optional RCSB metadata. This is clear, though it does not explicitly differentiate itself from overlapping siblings like rcsb_entry or validate_pdb.

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 when behavior kicks in (local file present, API key set) but gives no explicit when-to-use guidance or named alternatives versus rcsb_entry, validate_pdb, or structure_stats. Usage is inferable rather than 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 are provided, so the description carries the full behavioral burden. It does disclose a genuinely useful guard (refusing experimental B-factors) and the shape of its output (mean, bands, low-confidence regions), but it does not say what 'refuses' looks like operationally, nor any error or permission 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?

Three short sentences, front-loaded with the core action and immediately followed by output content and the key constraint. 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?

For a single-parameter tool with an output schema, the description is nearly sufficient: the output schema covers return values, and the description covers input source and the experimental-structure guard. The one notable omission is any reference to the near-duplicate sibling 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 description coverage is 0% and there is a single required parameter 'pdb_path'. The description implies the input is a PDB structure whose B-factor column holds pLDDT, which adds some meaning, but it does not clarify accepted formats, path expectations, or whether AlphaFold PDB files are 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 names a specific verb and resource ('Summarize AlphaFold-style pLDDT confidence from B-factor columns') and even states the data source, so an agent understands exactly what it produces. However, it never differentiates itself from the sibling tool 'alphafold_plddt', whose near-identical scope could cause mis-selection.

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 refusal clause 'Refuses to interpret experimental-structure B-factors as pLDDT' gives an implicit when-not-to-expect-results condition, which is useful. But there is no explicit when-to-use guidance and no routing to the obvious alternative 'alphafold_plddt' or 'structure_stats', leaving selection to inference.

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 disclose one genuinely useful trait beyond the schema: large series are decimated to <=5000 points, i.e. the plot is downsampled. However, it omits where the PNG is written when out_png is left empty, what happens on malformed or multi-column data, and any 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?

Two tight sentences with the core action front-loaded and the decimation caveat and return value following immediately. No filler and nothing redundant.

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 the returned path, and it still does so helpfully. But for a mutation-free plotting tool with four undocumented parameters and no annotations, it leaves meaningful gaps around output location defaults and the y_from_zero/title parameters.

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 4 parameters, so the description must compensate. It only obliquely covers out_png ('into a PNG') and says nothing about the default output path, what 'title' controls, or what y_from_zero does to the y-axis, leaving three of four parameters semantically 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?

States a specific verb and resource ('Plot every series of a GROMACS .xvg file against column 0 into a PNG'), plus the output artifact, so an agent knows exactly what the tool produces. It implicitly separates itself from siblings like xvg_summary and compare_plot by describing a raw plotting operation, but never names or contrasts those alternatives 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?

There is no when-to-use guidance, no statement of prerequisites (e.g., the file must be a valid .xvg with numeric columns), and no routing to alternatives such as xvg_summary for textual output or compare_plot for multi-run overlays. Usage is only inferable from the verb 'plot'.

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 usefully discloses what gets surfaced from the .pka file (HIS near pH 7, raised acids, CYS 99.99 disulfide markers), which is real context, but says nothing about read-only nature, missing/malformed file handling, or output size.

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 dense, front-loaded sentence that leads with the verb and resource, then layers the extracted content and the downstream rationale. No filler, though the parenthetical list makes it slightly heavy for a single sentence.

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 enumeration is a bonus rather than a necessity, and the description still tells the agent what to expect. With no annotations, a brief note on read-only behavior or file prerequisites would close the remaining gap, but the definition is adequate for a one-parameter parser.

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 one parameter, pka_path, and the schema gives it 0% description coverage. The description references the '.pka output' implicitly but adds no path-format, required-extension, or validity detail, so it neither compensates for the coverage gap nor drops below baseline for a self-evident single file path.

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 (parse) and resource (PROPKA .pka output) and enumerates the exact quantities extracted (pI, residue-type counts, pKa extremes, protonation-state flags). It is clearly distinguishable from the other *_summary siblings by content, though it never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The trailing clause 'exactly the decisions pdb2gmx protonation needs' implies the downstream use case, but there is no explicit when-to-use/when-not statement and no named alternative among the many sibling summary tools. Usage is inferable rather than 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?

With no annotations, the description carries the full behavioral burden and does well: it discloses the premium/auth requirement (relay URL + API key) and the important default behavior that CN-0 and CN-1 rows are excluded unless overridden. It omits rate limits or failure behavior when the relay is unavailable, keeping it shy of a 5.

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?

Front-loaded with purpose, then the auth prerequisite, then filter semantics, then worked examples. Every sentence earns its place and nothing is redundant with the name or title.

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; against the moderate schema complexity the description covers auth, defaults, overrides, and examples. The only residual gaps are the meaning of db_path and the limit parameter, which are minor for an otherwise complete definition.

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 largely does: it explains metal, geometry, min_cn, max_cn, and include_artifacts with defaults and semantics. It leaves limit and db_path (both present in the schema) unexplained, so it does not fully close the 7-parameter 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?

Specific verb (Search) plus a precisely scoped resource (the PDB-wide metal-site index), and the filter dimensions (metal, geometry, coordination number) tell an agent exactly what kind of query this is. It is distinguishable from siblings like metal_geometry and check_metal_params by being an index-level search rather than a single-structure analysis.

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 clearly states when and how to use it: filter by metal/geometry/CN range, and it explains the default filtering behavior and how to override it (min_cn=1, include_artifacts=True). Two concrete examples (Cys4 zinc fingers, catalytic zinc) reinforce the intended usage, though no sibling alternatives are explicitly 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 provided, the description carries the full burden and does well: it discloses the API-key requirement (a real auth constraint), a 24 h disk cache, and the refresh override to bypass it. It stops short of error/throttling or failure behavior, but the key operational traits are present.

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 short sentences, front-loaded with purpose and followed by the two operational facts (auth, caching) in priority order. Every sentence earns its place with no filler.

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 no explanation, and the description covers the auth and caching behavior an agent needs to call it correctly. The only real gap is that it never positions the tool against its many PDB/entry siblings.

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 explains refresh meaningfully ('forces a live fetch'), but pdb_id is left entirely to inference and there is no format guidance for it. Partial compensation only.

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 ('Fetch') and resource ('RCSB PDB entry metadata') and enumerates the returned fields (title, method, resolution, deposit date), so an agent knows exactly what it gets. It does not, however, distinguish itself from sibling tools like pdb_by_id, which an agent could plausibly confuse it with.

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 description signals a premium/authenticated tool and explains that refresh=True forces a live fetch, which is a usable hint. But it never says when to choose this over alternatives such as pdb_by_id, uniprot_entry, or the caching tools, and gives no 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 behavioral burden. It discloses that input can be a path or raw text and that it returns parsed records with sequences/types/metadata, but says nothing about error behavior (e.g. malformed FASTA), how 'normalize' affects parsing, or what happens with sequence_index. For a read-only tool the risk is low, but the disclosure is 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?

Three short sentences with no filler, and the key distinction (file path vs. raw text) is front-loaded. Efficiently sized for the tool's complexity.

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 detail return values, and it sensibly does not. But with 4 parameters at 0% schema coverage and no annotations, the description leaves normalize and sequence_index unexplained, which is a real gap 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?

Schema description coverage is 0%, so the description must compensate for all four parameters. It explains 'source' and 'is_file' (path vs. text), but 'normalize' and 'sequence_index' are never mentioned in the schema or the description, leaving half the parameters semantically opaque.

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 (sequences from a FASTA file or text), and clarifies the two input modes. It does not differentiate itself from related siblings like fasta_stats or detect_sequence_type, but the core purpose 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?

Usage is implied by the is_file=True/False duality, which tells the agent which mode to pick for a path vs. raw text. However, there is no explicit guidance on when to use this tool versus siblings such as fasta_stats, detect_sequence_type, or sequence_from_pdb, and no exclusions 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 exist, so the description carries the full burden. It usefully discloses the exact analysis performed (drift between first/last 10% of frames, plateau detection, binary verdict), but says nothing about error handling for malformed/truncated .xvg files or how the verdict threshold is chosen.

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 where every clause carries information: the input type, the three sub-analyses, and the output verdict. No filler.

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 an output schema present, return values need not be explained, and the description already previews the verdict concept. For a single-parameter analysis tool this is nearly complete, lacking only sibling routing and failure-mode notes.

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 sole parameter has 0% schema description coverage, but the description compensates by naming the expected input as a GROMACS RMSD .xvg file, which is far more meaningful than the bare 'xvg_path' string type. It still omits path conventions or accepted alternatives.

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 ('Assess equilibration from a GROMACS RMSD .xvg file') and enumerates the three analyses it performs (drift, plateau detection, verdict). It does not, however, distinguish itself from the sibling xvg_summary, leaving an agent to guess which of the two 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?

The description implies usage (analyze an RMSD .xvg to judge equilibration) but never states when to use this over xvg_summary, plot_xvg, or rmsf_peaks. 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 exist, so the description carries the full behavioral burden. It usefully discloses the computation criteria (top-N, mean + 1 stdev) and the required input format, but says nothing about failure modes for malformed/non-RMSF files, whether it is a read-only analysis, or units/atom selection 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?

A single front-loaded sentence delivering purpose, input type, and selection criteria with no filler; the parenthetical scoping is terse and 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?

An output schema exists, so return structure need not be explained. For a two-parameter analysis tool the description covers what it extracts and how, leaving only edge-case/error behavior and default handling unstated.

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 prose does compensate: it clarifies that xvg_path must be a GROMACS RMSF .xvg file and that top_n controls the 'top-N highest values' cutoff. It stops short of stating the default (10) or whether top_n=0 means all, but adds real meaning beyond the bare schema titles.

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 (Extract), a specific resource (most flexible residues/atoms), and even the selection algorithm (top-N plus contiguous segments above mean + 1 stdev). This clearly separates it from generic siblings like xvg_summary, rmsd_summary, and plot_xvg.

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 'GROMACS RMSF .xvg' input and the flexible-residue extraction goal, but the description never states when to prefer this over xvg_summary or plot_xvg, nor any prerequisites (e.g. the file must actually be an RMSF profile).

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 implies a read-only fetch but says nothing about what happens with an unknown id, whether the lookup is case-sensitive, or any access 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?

A single tight sentence with the resource front-loaded and the identifier semantics tacked on efficiently. 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 contents need not be described. For a one-parameter read tool this is close to sufficient, but the failure mode for a bad rid and the relationship to list_runs remain unstated.

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% — the rid property has no description at all. The description partially compensates by explaining that rid accepts 'numeric id or run_id', which is genuine added meaning, but it doesn't clarify the expected format or precedence.

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+resource: retrieve the 'full record for one registry entry'. That contrasts implicitly with the sibling list_runs, though it never names the sibling to make the differentiation 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?

No statement of when to use this versus list_runs or any other sibling, and no prerequisites or exclusions. The agent must infer that 'full record' means single-item lookup.

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 does disclose non-obvious traits: it handles MD protonation variants and selects model 1 for multi-model files. That is meaningful edge-case context an agent could not infer. It omits any note on output shape, though an output schema exists to cover that.

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; the parenthetical edge-case handling is compact and earns its place rather than padding the definition.

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 one-parameter extraction tool with an output schema covering return values, the description is nearly complete—purpose plus edge-case behavior. The main residual gap is parameter-level detail, but nothing critical for calling the tool 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?

Schema description coverage is 0%, so the description must compensate for the single undocumented pdb_path parameter. It only indirectly implies a PDB file is the input, adding no format, path, or validity detail beyond that, leaving the parameter largely unspecified.

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: 'Extract one-letter amino-acid sequences per chain from a PDB file.' An agent can immediately tell what it produces. It does not explicitly contrast itself with nearby siblings like aa_composition, read_fasta, or detect_sequence_type, 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?

The scope ('per chain', 'from a PDB file') implies when it applies, but there is no explicit when-to-use or when-not-to-use guidance and no alternative named among the many sequence/FASTA siblings. Usage is inferable but not 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 exist, so the description carries the full burden. It does add real behavioral context — PDB and mmCIF are auto-detected, and the operation is free/local rather than a billed remote call — but says nothing about failure modes (malformed file, unsupported format) or whether it ever mutates or caches anything.

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 lines, the output inventory front-loaded, followed by format and cost facts. No filler, no repetition of the title.

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?

This is a low-complexity, one-input, read-only summary tool and an output schema exists, so return values need not be described. The description covers purpose, accepted formats, and cost profile; only edge-case behavior for bad inputs is unstated.

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% for the single pdb_path parameter, so the schema contributes nothing. The description partially compensates by clarifying that the path may point to either a PDB or mmCIF file, but gives no guidance on relative vs absolute paths or expected file naming.

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+resource (structure summary) and enumerates the computed quantities (atoms, residues, chains, gaps, altLocs), so an agent knows exactly what comes back. It does not explicitly differentiate itself from near-neighbors like aa_composition or index_stats, which also report structural counts.

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: you call it to get a top-level inventory of a structure file. There is no statement of when to prefer it over siblings such as validate_pdb or sequence_from_pdb, and no prerequisites or exclusions 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?

With no annotations, the description carries full burden and it does well: it discloses the auth requirement (API key), the caching behavior (24 h disk cache), and the force-refresh semantics. It omits rate limits and error/failure behavior, keeping it short of a 5.

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: purpose first, then auth, then caching/refresh. Every sentence earns its place and nothing is redundant.

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 needn't be enumerated and the tool avoids that. The essential calling constraints (auth, cache, refresh) are present; only the accession format detail 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?

Schema description coverage is 0%, so the description must compensate. It meaningfully explains the non-obvious `refresh` parameter ('forces a live fetch'), but the required `accession` parameter gets no format or validity guidance beyond its name, leaving a real 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 ('Fetch') and resource ('UniProtKB entry') and enumerates the returned fields (protein name, organism, function, length, sequence, metal-binding annotations). It's clearly distinct from siblings like rcsb_entry or pdb_by_id by resource, though it doesn't explicitly name the alternative it contrasts with.

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 tool versus alternatives such as rcsb_entry or sequence_from_pdb. The only contextual cue is 'Premium tool (API key required)', which informs cost/auth but not selection.

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 substantively discloses what the tool checks and reports—format errors, non-standard residues, altLocs, chain gaps, duplicate atom names, insertion-code residues, and multi-model notes—which is rich behavioral context. It does not explicitly state side effects or error-handling behavior, but for a validation tool the enumerated checks provide strong transparency.

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 front-loaded with the core purpose, followed by a well-structured list of checks, and ends with a clear usage directive. Every sentence earns its place, and there is no wasted verbiage.

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. Given the low complexity (one parameter, no annotations), the description covers purpose, what is validated, and when to use it, making it complete enough for an agent to invoke 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 coverage is 0%, and the single parameter 'pdb_path' has no schema description. The description only implies the input is a PDB or mmCIF file, adding minimal meaning beyond the parameter name and schema title. It does not explain path format, file existence requirements, or other practical 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 and resource: 'Validate a PDB or mmCIF structure file (AlphaFold 3 / RCSB) for downstream use.' It enumerates the validation checks it performs, which helps distinguish it from sibling tools like structure_stats, but it does not explicitly name an alternative sibling, keeping it at 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?

The description provides clear context for when to use the tool: 'Always run this before feeding a structure into a pipeline.' However, it does not name any alternative tools or specify when NOT to use it, so it falls short of the 5-level criteria for explicit when/when-not/alternatives.

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 it does disclose the output shape well (per-column min/max/mean/stdev/first/last plus title and axis labels), which tells the agent what to expect. It omits any mention of error behavior for malformed files or how columns are labeled, but the operation is transparently a read-only summary.

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 a colon-delimited output list) that wastes nothing. The enumeration of output fields is slightly dense but all of it earns its place by previewing the return content.

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 enumerate return values in detail, and the task is a simple single-param read. The scope and output preview make it complete enough for correct invocation, with only the lack of routing guidance against siblings as a minor gap.

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 single parameter (xvg_path) has 0% schema description coverage, so the description must compensate. Saying it accepts 'any GROMACS .xvg file' clarifies the argument's nature but adds no format, path, or resolution detail beyond the self-evident name.

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 (Summarize) and a precise resource (GROMACS .xvg files), and enumerates the input variety (RMSD, energies, temperature, SASA). It is clearly distinguishable from siblings like plot_xvg (visualizes) and rmsd_summary (domain-specific), and it even lists the exact statistics produced.

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: 'Summarize any GROMACS .xvg file' tells the agent this handles generic xvg inputs, but it never states when to prefer this over rmsd_summary or plot_xvg, nor any preconditions. No explicit when/when-not guidance is offered.

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