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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context that the presets are built-in and intended as a preliminary step, but it does not disclose additional behavioral details such as output shape or ordering.

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 a single, well-structured sentence with no wasted words. It front-loads the core action ('List built-in TAP service presets') and then adds the practical sequencing context.

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 with an output schema and comprehensive annotations, the description is complete. It explains what the tool does and when it should be used, which is all an agent needs to invoke 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?

This tool has zero parameters, so there is no parameter burden for the description to carry. The baseline of 4 is appropriate because there is nothing about parameters that could be clarified.

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 ('List') and a specific resource ('built-in TAP service presets'), making the tool's purpose immediately clear. It also distinguishes this tool from the sibling TAP tools, which focus on availability, capabilities, tables, columns, queries, and jobs rather than presets.

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 timing guidance: use this tool 'before selecting an explicit target for metadata inspection.' It does not explicitly name alternatives or state when not to use it, but the intended workflow context is evident.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the workflow context of inspecting a service before querying, but does not disclose details like possible registry inconsistency, incomplete metadata, or response variability beyond what openWorldHint implies.

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 sentence that is front-loaded with the main action and resource, then states the usage condition and the recommended follow-up. There is no filler or redundant restatement of the tool name.

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

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

Given that the output schema is present and annotations already convey the read-only, idempotent, and open-world behavior, the description covers the essential decision point: use when no preset fits and inspect before querying. It is slightly light on what 'inspect' should include, but the sibling tools and output schema fill most of the 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 input schema has 100% description coverage for all three parameters, so the schema already explains query, maxrec, and registryUrl. The description adds no parameter-level guidance beyond the general registry-search context, which is acceptable given the high schema 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?

The description states a specific verb ('Search'), a specific resource ('VO registry metadata'), and the triggering condition ('when no built-in preset fits'). It also signals a follow-up workflow step ('inspect the selected service before querying it'), which distinguishes it from direct querying tools like starfetch_tap_query.

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 explicitly says when to use the tool ('when no built-in preset fits') and instructs to inspect the selected service before querying it. It does not name sibling alternatives directly, but the condition is clear enough for an agent to route between the registry search and the preset list.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the description adds useful context rather than repeating annotations. The caveat that an unavailable service is not an empty catalog result provides meaningful behavioral guidance beyond what annotations convey.

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 states the action and then adds one important caveat. There is no redundancy or filler; every part of the description adds value.

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 read-only availability check with an output schema present and annotations covering safety and idempotency, the description is complete. It tells the agent what to check and the key interpretive caveat; no additional operational details seem necessary.

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 both url and service parameters documented as alternatives. The description does not add significant parameter-level detail, but it does not need to because the schema already explains the parameters and their relationship. Baseline 3 is appropriate.

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 clearly states a specific action and resource: checking whether the selected TAP service reports itself as available. It also distinguishes itself from sibling catalog/query tools by clarifying that an unavailable service should not be interpreted as an empty catalog result.

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 conveys the clear context that this tool is for checking availability of the selected TAP service before interpreting results. It does not explicitly name alternative tools or state when-not-to-use, but the context is unambiguous enough for selection among the sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is fully covered. The description adds useful context about what is inspected (languages, formats, auth), but does not disclose additional behavioral details such as error conditions or rate limits. No annotation contradiction exists.

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, tightly worded sentence that front-loads the action, the target, the inspected details, and the intended timing. No filler or repetition of schema 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?

For a read-only capability inspection tool with an output schema and strong annotations, the description is adequate. It explains why and when to call it without needing to describe return values. It does not explicitly state that exactly one of url/service must be supplied, though the schema descriptions already communicate the either-or relationship.

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 both 'url' and 'service' parameters have clear descriptions including the 'use this or the other' relationship. The tool description adds no new parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Inspect') and names concrete resources: languages, formats, and authentication requirements of the selected TAP service. The phrase 'before using service-specific features' also distinguishes this from sibling tools like starfetch_tap_query or starfetch_tap_submit_job, which execute operations rather than introspect capabilities.

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 clear usage timing: use this before service-specific features. It does not explicitly name alternatives or exclusion conditions, but the sibling list and the 'before' phrasing make the intended workflow evident.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the key constraint that the table must be an exact metadata-discovered table and clarifies that the operation returns column metadata instead of data. There is no contradiction with annotations.

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 sentence that front-loads the verb and object, states what is inspected, and situates the call in its workflow. There is no filler and no repetition of schema 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?

For a read-only metadata-listing tool, the description, full parameter schema, output schema, and annotations together cover workflow context, safety, and expected inputs. The phrase 'exact metadata-discovered table before constructing ADQL' supplies the important contextual cue.

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 input schema has 100% description coverage, so all three parameters are already documented. The description reinforces that 'table' must be the exact name from prior metadata inspection, but it adds no new syntax or format details beyond what the schema provides.

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 (Inspect) and resource (columns for a table), lists the returned facets (names, datatypes, units, descriptions), and ties the action to a workflow stage (before constructing ADQL). This clearly separates it from sibling tools like starfetch_tap_tables, which list tables rather than one table's columns.

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

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

It explicitly says when to use it: after metadata discovery, before constructing ADQL, on an exact table name. It does not explicitly enumerate alternatives or state when not to use it, but the workflow context is clear enough to guide tool selection among siblings.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description only restates the deletion concept. It does not explain whether the job is cancelled if running, whether deletion is permanent, or what happens on repeated deletion attempts, so it adds no behavior beyond the annotations.

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 a single short sentence with the verb 'Delete' front-loaded and no wasted words. It is concise, though it largely repeats the title and could have used the space to include behavioral or usage context.

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

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

The schema fully covers parameters and annotations cover the destructive profile, so basic invocation is sufficiently supported. However, the description is thin on when to use the tool and what deletion actually entails, leaving the agent to infer important selection context from the tool name and sibling names alone.

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 input schema fully documents all three parameters, including the url/service alternatives and jobIdOrUrl format, with 100% coverage. The description adds no parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb, 'Delete', names the exact resource, 'TAP async job', and notes the remote scope. This clearly differentiates it from sibling tools that submit, query, wait, or fetch jobs.

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 no explicit guidance on when to use deletion versus alternatives like job_status, job_wait, or job_fetch, and no preconditions are stated. The appropriate usage is only implied by the verb 'Delete'.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context about format conversion, going beyond what annotations provide. It does not cover error behavior or whether the fetch blocks on completion, but the annotation coverage lowers the burden.

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

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

Two concise sentences with the primary action front-loaded. The second sentence adds a meaningful capability without unnecessary detail. 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?

Rich input schema, output schema, and annotations cover most invocation concerns. The main gap is explicit sequencing guidance—mentioning that the job should be finished before fetching, or pointing to job_status/job_wait—but the tool is still adequately usable as described.

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 baseline applies. The description's conversion sentence vaguely relates to format and sourceFormat, but it does not add parameter-specific meaning beyond what the schema already documents.

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

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

The description uses a specific verb and resource ('Fetch a TAP async job result') and adds a distinguishing capability: JSON/JSONL conversion from VOTable, CSV, and TSV rows. This clearly separates it from siblings like job_status, job_wait, and job_delete.

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 it should be used to retrieve the output of an already-submitted async TAP job, but it does not explicitly say to call it only after the job is complete, nor does it contrast with job_status or job_wait. Usage context is present but largely 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the useful behavioral fact that it exposes the current phase and links, which clarifies what the read operation returns. No contradiction exists, and no additional side-effect or auth context is needed beyond the annotations.

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 one short, front-loaded sentence with no filler. Every word contributes to the tool's purpose, and it is appropriately minimal for a simple read operation.

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 simple read-only nature, full parameter schema coverage, rich annotations, and presence of an output schema, the description is nearly complete. It lacks explicit workflow context about when to poll status versus wait or fetch results, but the sibling names partially compensate for that.

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 input schema already documents all three parameters with clear descriptions, and schema coverage is 100%, so the baseline is 3. The description does not add extra semantics for jobIdOrUrl, url, or service beyond what the schema provides, but it does not need to because coverage is complete.

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

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

The description states a specific verb ('Read'), a clear resource ('TAP async job'), and the exact information returned ('current phase and links'). It is clear and unlikely to be confused with submit/wait/fetch/delete operations, though it does not explicitly name a sibling or state how it differs from job_fetch.

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 starfetch_tap_job_wait, starfetch_tap_job_fetch, or starfetch_tap_job_delete. The sibling names imply a workflow, but the description does not state conditions like 'after submitting a job' or 'to check progress without fetching 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?

The annotations already signal read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond those annotations: it polls until completion/timeout/failure, is an explicit wait, and never creates a background job. No contradiction with annotations.

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 concise sentences with no filler. The core polling behavior is front-loaded, and the second sentence earns its place by ruling out the common misconception that this tool starts background work.

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

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

For a tool with an output schema, full parameter coverage, and strong safety annotations, the description covers the essential operational contract: blocking wait, exit conditions, and no job creation. The only small gap is lack of explicit guidance on when to prefer job_status over this tool, but that is not critical to 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%, so the schema already documents all 7 parameters, including jobIdOrUrl, timeoutMs, intervalMs, and backoff. The description does not add parameter-level detail, but it is not required because coverage is complete; 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: 'Poll a TAP async job' until three explicit terminal conditions. The sentence also differentiates from the submit sibling by asserting it 'never starts a background job', so an agent can place it among the sibling tools.

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?

Provides clear context: use this when you need an explicit, blocking wait on an existing async job, and it explicitly says this tool is not for launching work. It does not name sibling alternatives like job_status, so it falls just short of the 'explicit when/when-not/alternatives' bar.

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

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

Annotations already provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond annotations by stating the query is synchronous and by explicitly warning that tool errors should be treated as failures rather than empty scientific results. This helps the agent avoid misinterpreting an error as a legitimate empty result.

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 only two sentences and every clause earns its place. It front-loads the core action and scope, then gives the two most important execution rules: boundedness via TOP/maxrec and error interpretation. There is 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?

Given the rich input schema, presence of an output schema, and annotations, the description covers the key operational guidance: query scope, boundedness, prior inspection of tables/columns, and error handling. It does not explicitly mention the async job submission alternative for larger queries, but 'small bounded synchronous' sufficiently implies that boundary in most cases.

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 explains every parameter in detail. The description reinforces the query parameter guidance with 'Use TOP in ADQL and/or maxrec,' but this largely repeats what the schema already states. It adds little new parameter-level meaning 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?

The description opens with a specific verb and resource: 'Run a small bounded synchronous TAP ADQL query.' It clearly distinguishes this tool from sibling starfetch_tap_submit_job by emphasizing 'synchronous' and 'small bounded', and it also signals the correct workflow by saying 'after inspecting the exact table and columns.' This is a precise, non-tautological purpose statement.

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 clear usage context: use this tool for small, bounded, synchronous queries after verifying table and column names, and use TOP/maxrec to keep the query bounded. It does not explicitly name the async alternative starfetch_tap_submit_job or state when not to use this tool, so it misses the highest level of guidance, but the implied workflow is still clear.

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

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

Annotations already cover read-only, idempotence, and destructive hints, and the description adds useful behavioral context: the job is asynchronous, the exact query text is preserved, and the ADQL should be bounded. It does not contradict the annotations and respects the open-world hint.

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 compact sentences with the core purpose and trigger condition front-loaded, followed by a necessary preservation warning. There is no redundant 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?

The description, rich schema, output schema, and sibling job tools (job_status, job_wait, job_fetch, job_delete) together cover the async job lifecycle without bloating this definition. It could explicitly mention that submission returns a job identifier for follow-up, but the output schema and sibling names make that discoverable.

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 100%, so all seven parameters are already documented, including the query guidance 'Use TOP for a query-level bound; do not use LIMIT.' The description reinforces that the query should be bounded and exact but adds little beyond what the schema provides.

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 identifies the specific action (submit), the resource (TAP async job), and the scope (metadata-backed bounded ADQL). It explicitly distinguishes this tool from starfetch_tap_query, making its role immediately recognizable.

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 states the trigger condition 'when synchronous querying is insufficient' and names the alternative for small work: 'use starfetch_tap_query.' This gives an agent explicit decision criteria before opening the schema.

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

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

Annotations already declare readOnly, openWorld, idempotent, and nondestructive hints, so the description does not need to restate safety behavior. It adds the workflow reason for listing tables, but it does not disclose additional behavioral traits such as pagination, limits, or completeness of the table list beyond what annotations and output schema already cover.

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 a single sentence that front-loads the action and outcome with no filler. It is appropriately compact for a simple list tool and includes the important workflow-stage context.

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, rich annotations, and two optional parameters with full descriptions, the definition is functionally complete for invoking the tool. It captures the purpose and the stage in the ADQL workflow; a minor gap is not explicitly saying that exactly one of url/service should be provided, but the schema already conveys that.

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 both url and service parameters already explain that one should be used and that they are workflow-selected. The description adds no further meaning to the parameters, so it earns the baseline score for schema-covered parameters.

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

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

Description uses a specific verb and resource ('List tables on the selected TAP service') and adds workflow context ('before choosing an exact table for ADQL'). This clearly distinguishes it from sibling tools like starfetch_tap_columns, though it does not explicitly name the 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?

The description implies when to use it: before selecting an exact table for ADQL on an already-chosen TAP service. However, it does not explicitly state when not to use it or direct the agent to related tools such as starfetch_tap_columns or starfetch_tap_capabilities, leaving the guidance implied rather than fully explicit.

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