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 return contract (status values plus a results URL) and implicitly that this is a non-destructive read. It omits whether polling is rate-limited, whether it is safe to call repeatedly, and how it differs behaviorally from the blocking wait_for_job, so the disclosure is only partial.

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

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

Two tight sentences with the action front-loaded and the return value second — no filler. Slightly more could be trimmed, but it earns its place and is well ordered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read tool with no output schema, the description supplies the necessary return-value detail (statuses and results URL). It nonetheless leaves the sibling-routing question unresolved, which matters here because wait_for_job and get_job_details overlap semantically.

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

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

Schema description coverage is 100%, so job_id and the server_type enum are fully documented in the schema itself, establishing the baseline of 3. The description adds no further parameter meaning (e.g., why server_type must match the original submission endpoint), which is acceptable given the schema already does the work.

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 ('Check the status of a submitted antiSMASH job') and even enumerates the possible status values, so the purpose is unambiguous. However, it never differentiates itself from close siblings like wait_for_job, get_job_details, or get_job_results, leaving the agent to infer the boundary.

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 the phrase 'submitted job' — the agent can infer this is a polling call for a job it already created. There is no explicit when-to-use guidance and no mention of the obvious alternatives (wait_for_job for blocking, get_job_results for finished output), which is a real gap given the crowded sibling set.

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

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

No annotations exist, so the description carries the full burden. It helpfully discloses the archive contents (GenBank files, HTML reports, JSON data) and the completed-job prerequisite, but says nothing about authentication, overwrite behavior, size/rate limits, or failure modes for an invalid job_id.

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

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

Two sentences, front-loaded with the action and scope; the second sentence earns its place by telling the agent what the downloaded artifact actually contains.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly explains the return artifact (a ZIP of analysis results), and the required params are schema-covered. Minor gaps remain around preconditions and error handling, but an agent has enough 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 description coverage is 100%, so all three parameters are already documented. The description reinforces that output_path is a local save location and what the payload contains, but adds no syntax or format detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (Download), resource (antiSMASH results archive ZIP), and scope (completed job), and the phrase 'save it to a local path' distinguishes it from siblings like get_job_results that presumably return data inline. It stops short of explicitly naming which sibling to use instead, but the action is unambiguous.

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

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

The description implies a precondition ('for a completed job') and hints that check_job_status/wait_for_job should precede it, but never states when to prefer this over get_job_results or get_job_details, nor what to do if the job is still running.

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 that calling it does not submit a job, but says nothing about permission requirements, whether the returned URL is static or expires, or whether the resource is hosted externally.

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

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

One sentence, front-loaded with the action and resource, with the purpose clause earning its place by justifying why the tool exists. 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 zero-required-parameter read tool with full schema coverage and no output schema, the description covers what the tool returns (a URL) and why to use it. Minor gaps around URL lifetime/access are not critical 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 100% and the single parameter (server_type) has a documented enum and default, so the schema fully specifies the input. The description adds no meaning about server_type or how the choice affects the returned sample, matching the baseline of 3.

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 ('Get the URL for the example antiSMASH output') and adds scope that separates it from the job-oriented siblings: it exists to explore format/content 'without submitting a job.' An agent can tell immediately this is a static sample-fetch, not a computation request.

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

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

Gives a clear use case ('explore the format and content of antiSMASH results without submitting a job'), which implicitly routes the agent away from submit_sequence/submit_ncbi. It does not explicitly name an alternative tool or state when-not to use it, so it stops short of full 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?

With no annotations, the description carries the full behavioral burden. It does disclose one real trait — that the call is valid for in-progress as well as finished jobs, unlike a status-only or results-only endpoint. It says nothing about permissions, behavior on an unknown job_id, or whether the payload is truncated for large jobs, leaving meaningful 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?

Two sentences, no boilerplate, and the payload contents are front-loaded before the lifecycle caveat. Every clause carries information an agent can act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by naming the return contents (regions, cluster types, download links, statistics) and covering the running/completed distinction. It is close to complete for a two-parameter read tool, with only error and permission behavior left 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 description coverage is 100%, with job_id documented and server_type carrying a three-value enum plus a default, so the schema already does the heavy lifting. The description adds no format, validation, or lookup guidance beyond that, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get detailed information about an antiSMASH job') and enumerates the content surfaced: detected regions, cluster types, download links, summary statistics. The added 'Works for both running and completed jobs' meaningfully separates it from the status/lifecycle siblings, though it never names check_job_status or get_job_results to make the boundary explicit.

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

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

The phrase 'Works for both running and completed jobs' implies when the tool is applicable across the job lifecycle, which is useful context. However, no sibling is named and there is no when-not guidance, so an agent must infer on its own how this differs from check_job_status, get_job_results, or download_results.

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 return content and the completion precondition, which is genuinely helpful, but says nothing about what happens if the job is not finished, whether the call is safe to repeat, or any size/rate constraints.

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

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

Three short sentences with no filler; purpose leads, return content follows, precondition closes. It is appropriately sized for a two-parameter read tool, with only minor overlap between the first and second sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description partially compensates by summarizing the return payload and the precondition. However, it omits the not-yet-complete/error case and the relationship to download_results, leaving real gaps for a results-retrieval 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 100%: job_id and the server_type enum (bacteria/fungi/plant) are already fully documented in the schema. The description adds no format, default, or matching guidance beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get the results of a completed antiSMASH job') and even enumerates what comes back (gene clusters, regions, cluster types). It is clear and concrete, but it never distinguishes itself from siblings like get_job_details or download_results, so an agent must guess which of the three returns what.

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

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

The description gives one precondition: 'The job should be completed before calling this tool.' That is useful implied workflow guidance, but it does not name the sibling that verifies completion (check_job_status / wait_for_job) or explain when to prefer this over download_results for raw output.

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

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

With no annotations, the description must carry behavioral disclosure. It does disclose the return payload (running/queued/processed job counts) and implies a read-only operation via 'Get,' but says nothing about permissions, rate limits, latency, or whether the call fails when the server is down. Useful but not rich.

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: the first front-loads what the tool returns, the second front-loads when to reach for it. No filler, no repetition of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, parameterless-in-practice status read with no annotations and no output schema, the description covers the essentials by naming the returned job counts and the motivating use case. It stops short of describing failure/down behavior, but nothing blocks 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 100% and the single server_type parameter is fully documented in the schema with an enum and default, so the description does not need to compensate. It adds no extra semantics beyond what the schema already provides, making the baseline 3 correct.

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 ('Get the current status of the antiSMASH server') and enumerates the returned metrics (running, queued, total jobs), which makes the tool's scope concrete. It does not explicitly name or contrast with any sibling like check_job_status or get_job_details, so it stops short of full differentiation.

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

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

Gives a clear usage context: 'Useful to check if the server is available before submitting new jobs,' which tells the agent the pre-flight scenario that selects this tool. It provides no explicit exclusions or alternative-selection rules, so it lands at clear-context-without-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?

With no annotations, the description carries the full burden. 'List' and the absence of parameters imply a harmless read-only operation with no side effects, and it discloses that feature descriptions are returned. It does not state the response shape, stability of the list, or whether the feature names are exact strings to pass to submit tools.

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

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

Two short sentences, front-loaded with the action and resource, with the second sentence adding genuine usage context rather than filler. 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?

For a zero-parameter, read-only listing tool this is nearly sufficient, but with no output schema the description should say more about what comes back — e.g., whether it returns feature identifiers that match the values accepted by submit_sequence/submit_ncbi. That link is the whole reason an agent would call this before submitting.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly does not invent or describe any inputs.

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: listing available extra features for antiSMASH analysis, including that descriptions are returned. It is clearly distinct from the job-management siblings (submit_sequence, check_job_status, etc.), though it never names a sibling to differentiate itself 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?

'These features can be specified when submitting a job' implies this is a discovery/discovery-before-submit tool, which is a useful hint. However, there is no explicit when-to-use statement, no ordering guidance, and no named alternative, so usage remains inferred.

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 usefully discloses that antiSMASH fetches the sequence automatically and that the call is asynchronous (returns a job ID for later status/results), but it omits submission-side traits such as rate limits, external dependency handling, or whether email notification changes 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 sentences, each earning its place: purpose, automatic retrieval behavior, and async return contract. It is front-loaded and has 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 5-parameter async submission tool with no output schema and no annotations, the description is largely complete: it explains the automatic sequence retrieval and the job-ID return that links to the check/retrieve siblings. It would be stronger if it named the polling/workflow siblings or noted external-service caveats.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema, including enums and defaults. The description adds no syntax, format, or constraint guidance beyond 'NCBI accession number,' so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (submit), resource (NCBI accession number), target service (antiSMASH), and domain (secondary metabolite BGC analysis). It is clear what the tool does, though it never explicitly contrasts itself with the sibling submit_sequence, which is the obvious alternative.

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 framing: use this when you have an NCBI accession rather than a raw sequence, and the last sentence gestures at the downstream workflow (check status, retrieve results). However, it gives no explicit when-to-use rule, no exclusion, and never names the alternative submit_sequence.

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 present, the description carries the full disclosure burden. It does add real value by explaining the async contract ('Returns a job ID that can be used to check status and retrieve results'), which tells the agent this is a long-running job requiring polling via check_job_status/wait_for_job. However, it says nothing about execution time, antiSMASH version, network/rate-limit behavior, or what happens on failure.

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 action and resource, then the input constraint, then the return contract. No filler or restatement of the name/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?

No output schema exists, but the description compensates by stating that a job ID is returned, which is the key thing an agent needs to chain into check_job_status. Missing only secondary operational detail (expected runtime, failure modes) for a job-submission tool with a fully covered schema.

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

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

Schema description coverage is 100%, so every parameter (email, gff3_file, strictness, server_type, sequence_file, sideload_file, extra_features) is already documented in the schema, including enum semantics. The description's file-format mention duplicates the sequence_file schema text and adds no new parameter-level meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Submit a nucleotide sequence file to antiSMASH') and names the analysis domain (secondary metabolite biosynthetic gene clusters). It is clearly distinguishable from list_extra_features, check_job_status, or download_results, but it never names submit_ncbi, the closest sibling, so the file-vs-accession distinction is left implicit.

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 explicit when-to-use or when-not guidance. Given a sibling submit_ncbi exists, the agent gets no statement like 'use this when you have a local file; use submit_ncbi when you have an accession.' The format note (GenBank/EMBL/FASTA) is a constraint, not 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?

With no annotations, the description carries the full burden and does well: it discloses that the call is blocking, polls at regular intervals, terminates on completion or error, and can run 10+ minutes. It omits what happens on hitting max_wait (timeout behavior) and permissions, which keeps 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 sentences, each earning its place: purpose first, blocking/mechanism second, cost warning third. No filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should say what the tool returns on success (final job status only, or results), and it does not. The behavioral narrative is adequate for a single blocking call, but the return contract is left undefined.

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

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

Schema description coverage is 100%, so the schema already documents job_id, max_wait, server_type, and poll_interval with defaults and an enum. The description only adds the vague notion of 'regular intervals' for polling, which the schema covers better, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Wait for an antiSMASH job to complete by polling its status'), which is clear and actionable. However, it does not distinguish itself from the sibling check_job_status, which by name performs an analogous status check, so the agent must infer the blocking vs. non-blocking difference.

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 with caution as antiSMASH analysis can take 10+ minutes' gives implicit guidance about when the blocking cost is justified, but no alternative (e.g., check_job_status for non-blocking polling) is named. Usage is implied rather than explicitly routed.

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