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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the description only needs to add context beyond that, and it does establish that this is an external submission to EMBL-EBI plus what comes back (InterPro entry, GO terms, coordinates, E-value). However, it omits genuinely important behavioural traits for a remote InterProScan job: expected latency, whether the call blocks or is asynchronous, failure/timeout behaviour, and result-size limits. Those gaps matter more than usual for a tool whose annotations already flag open-world cost.

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 opening sentence with the verb and scope front-loaded, then the payload enumeration in an em-dash clause. Every element earns its place, though the comma-separated database list is longer than strictly necessary and pushes the sentence toward run-on length.

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, the description need not explain return values and wisely only names them in passing. For a 12-parameter tool with nested _subject and an external service dependency, the remaining omission is operational — timing and failure modes — rather than conceptual. That is a real but modest gap, not a disqualifying one.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the individual parameter descriptions are already unusually rich (applications vs visibleLibraries distinction, maxEvalue's never-scored exception, sortBy ordering semantics). The prose adds no parameter meaning beyond that, so the baseline of 3 applies; it does at least name the output fields the caller will filter on.

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 — submits a protein to EMBL-EBI InterProScan and returns every matching member-database signature — and enumerates the databases (Pfam, CATH-Gene3D, SUPERFAMILY, PANTHER, PROSITE, SMART, CDD). The 'every member-database signature' phrasing implicitly separates it from single-database siblings like rps_blast_cdd or rps_blast_smart, but no sibling is named explicitly, which keeps it just 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?

'De-novo' hints that this is for unannotated proteins rather than lookup_protein, but the hint is never spelled out. There is no explicit statement of when to choose this over the per-database scan tools (rps_blast_cdd, rps_blast_smart, protein_profile) or over lookup_protein for an already-annotated accession. Usage is implied, not stated.

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