space-intelligence

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds genuinely new traits: the call is free, it returns counts only, no content is returned, and the response includes match counts, newest date, and matched names. It stops short of auth or rate-limit detail, but the return-shape disclosure is the important gap-filler given no output schema.

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 'Free.' qualifier, then what it checks, then what it returns and what to use instead. No sentence is redundant and the negative constraint (no content) is stated exactly once.

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 carries the return-value burden and does so explicitly (counts, newest date, matched names). Annotations cover the safety profile, so nothing an agent needs to decide or call this 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 100% and the single parameter is fully documented with examples and length bounds, so the schema does the heavy lifting. The description only restates 'a space company or topic' with no additional syntax or matching semantics 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?

States a specific verb and resource: check whether SNTL holds verified material on a company or topic. It explicitly contrasts itself with the content-retrieval sibling (submit_research_interest), so an agent can place it without opening a schema.

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 trigger ('before asking a question') and routes the agent to the correct alternative for getting actual research. It does not address the other siblings (check_research_status, respond_to_research_offer), so exclusions are incomplete but the primary use context is unambiguous.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds value beyond them: the receipt should be kept private (a privacy/auth constraint) and results may not be immediately available, requiring retry polling. That is real behavioral context not encoded in 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?

Three sentences, front-loaded with the retrieval scope followed by the alternative-tool routing and the polling caveat. Every sentence carries information, though the privacy restatement of receipt_id mildly duplicates the schema description.

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 compensates by enumerating the possible return contents (scope, price, payment, decision, response). Combined with annotations covering the safety profile and the schema covering the input, an agent has enough to invoke it correctly; only the absence of explicit exclusion criteria keeps it below 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 coverage is 100% and the single receipt_id parameter is fully documented in the schema, including its pattern and origin. The description only repeats 'using your receipt_id' without adding format or validation detail beyond the schema, 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?

The description uses a specific verb (retrieve) and enumerates the resource types returned: proposed scope, price offer, payment details, operator decision, or research response. This is far more informative than the tautological title, though it does not explicitly name check_coverage or submit_research_interest as contrasting siblings.

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 routes the agent to respond_to_research_offer for confirming/correcting scope or accepting/declining a quote, which is genuine alternative-tool guidance. The polling hint ('if no response is available, try again later') adds useful timing context, but there is no explicit statement of when NOT to call this tool.

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

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

Annotations already mark this as a non-read-only, non-destructive, non-idempotent action, and the description adds real behavioral context: acceptance only records a choice, no work starts and nothing is owed until payment, and quote actions require an unexpired quote. It omits what a repeat submission does (relevant given idempotentHint=false), keeping it from 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?

Four dense sentences with no filler; the privacy/identity constraint (private receipt_id) is front-loaded and each action rule earns its place. The middle sentences are packed tightly enough that a reader must parse carefully, so not a 5.

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 4-parameter, nested-schema mutation tool with no output schema, the description covers prerequisites, per-action requirements, the financial consequence of acceptance, and a privacy constraint. The main residual gap is the return value/next-step after responding, which is not addressed.

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 the baseline is 3, but the description adds binding semantics the schema cannot express: which actions require a proposed scope, that correct_scope for an Answer also needs correction text, and that decline_quote may carry a budget counter-offer. The Brief/Map exception ('send a changed question as a new request') is genuinely 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 names the resource (SNTL's offer) and enumerates the four response actions with their distinct conditions, so an agent knows exactly what the tool does. It does not sharply position itself against its siblings beyond naming check_research_status, so it falls short of 5.

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

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

It explicitly states the prerequisite ('Use check_research_status before responding') and gives per-action selection rules: confirm_scope/correct_scope answer a proposed scope, accept_quote/decline_quote answer an unexpired quote. It also routes a divergent case (Brief or Map corrections) to a new request rather than this tool.

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

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

Annotations only say readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false. The description goes well beyond them: it discloses the approval flow (answer is auto accept/decline, brief/map are scope-reviewed by SNTL), that a fixed-price quote follows acceptance, delivery windows of 7/14 days from payment, that nothing is owed until payment, that the request is stored, and that contact/personal data must be excluded. For a non-idempotent submission this is exactly the missing context an agent needs.

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 purpose and the return-to-check_research_status instruction are front-loaded, which is good, but the body is one long run-on sentence with parenthetical pricing and dates that is hard to parse. Pricing tiers and delivery windows earn their place, yet the packaging is denser than it needs to be.

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 10-parameter tool with a nested budget object, a conditional companyName requirement and no output schema, the description covers the workflow end to end: submission, accept/decline, quote, payment, delivery, receipt, privacy. The main gap is that it never describes the immediate return value (an identifier or receipt object) that check_research_status presumably needs, though 'keep the receipt' hints at 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?

Schema description coverage is 100%, so a 3 is the floor. The description adds real meaning beyond the schema for the 'product' enum by attaching price and scope to each value (answer €12.50, brief €250 two-to-five pages, map €999) and noting the acceptance rule per product. It does not explain subjectType, outputFormat, topics, maximumAgeDays or budget semantics, which remain schema-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?

The description opens with a concrete verb and resource: 'Ask SNTL one research question about a space company or market, and choose the product.' It also enumerates the three products (answer/brief/map) with their scope and price, so an agent can tell it is a request-submission tool rather than a status or offer-response tool. It stops short of naming the siblings it is distinct from, so it is clear but not fully differentiated.

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 instructs the agent to submit exactly one question, tells it to pick a product, and explicitly routes the follow-up step ('Keep the receipt and return with check_research_status'), which points at a sibling tool. It does not state when to use respond_to_research_offer or check_coverage instead, so there is clear context but no explicit exclusions.

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