Ouro Tools

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

The description discloses return artifacts ('SVG and PNG files') and the temporary hosting duration ('hosted result for 24 hours'), which goes beyond the annotations (readOnlyHint, destructiveHint). It adds behavioral context that an agent would not otherwise know. 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?

The description is a single, information-dense sentence with no filler. It front-loads the action and chart types, then adds the key output detail. Every word 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 tool with 9 parameters and no schema descriptions, this description is too sparse. It lacks instructions on how to structure datasets and labels, allowed value ranges, or how the output files are delivered. An agent would need to guess critical input formatting, making the tool difficult to invoke correctly without additional knowledge.

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 schema provides no parameter explanations. The description only mentions 'numbers' as input, but does not explain key parameters like 'labels', 'datasets', 'type', 'theme', or constraints. An agent would have to infer dataset structure and enum meanings without any guidance. This is a significant 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?

The description opens with a specific verb ('Create'), names the resource ('chart'), and enumerates the supported chart types ('bar, line, or stacked bar'). It also implies the input ('from numbers') and distinguishes itself from the sibling chartlink_get_chart (retrieve) by focusing on creation. This is clear and 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?

No explicit when-to-use guidance is given. The description does not mention alternatives or conditions (e.g., 'Use this when you need a chart; use chartlink_get_chart to retrieve an existing one'). The purpose implies creation vs. retrieval, but the tool does not help the agent decide between this and other tools beyond what the name already conveys.

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 the operation read-only and non-destructive. The description adds meaningful behavioral context beyond that: results expire in 24 hours and download URLs are returned. No contradiction exists, and the time-bound nature is a valuable 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?

The description is a single sentence that immediately states the action, the resource, and the key behavioral constraint. There is no wasted wording and 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?

For a simple one-parameter, read-only tool with annotations covering safety, the description covers the purpose, the return content (download URLs), and the central expiry limitation. It falls short only in not specifying the return structure or behavior after expiry, but it is adequate for most call scenarios.

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 carries the full burden for explaining the 'id' parameter. It only implies that 'id' identifies the chart, giving no format, example, or additional constraints. The compensation is insufficient for an undocumented 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?

The description uses a specific verb and resource: 'Retrieve a chart and download URLs'. It clearly names the object and distinguishes the tool from its sibling chartlink_create_chart, which obviously creates charts. The 24-hour expiry detail adds a precise 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?

The expiry hint implies the tool is for fetching chart URLs before they become invalid, and the name contrasts with chartlink_create_chart. However, there is no explicit guidance on when to use this tool versus alternatives, nor any 'when not to use' instruction, leaving usage mostly implicit.

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=false, openWorldHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond annotations: it does not execute JavaScript and does not bypass access restrictions. This is important for an agent to predict failure modes. It could go further by mentioning rate limits or response size, but the key behavioral constraints are disclosed.

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 with no wasted words. The first sentence front-loads the tool's purpose and output types, and the second sentence states critical limitations. Every word 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 single-parameter tool with a simple input schema and no output schema, the description is largely complete. It covers what the tool extracts, the access constraints, and the JavaScript limitation. The only minor gap is that it doesn't describe the return format or error behavior, but with one parameter and no output schema, the description carries the burden well.

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 the 'url' parameter as a public HTTP or HTTPS URL. The description adds the context that the URL must be 'accessible' and 'public', which reinforces the schema. However, it does not add new syntax or format details beyond what the schema provides, so the 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 states a specific verb ('Extract') and resource ('readable text, Markdown, headings, HTTP links, and tables from one accessible public webpage'). It clearly distinguishes itself from siblings like tablelift_extract_tables by covering multiple content types, not just tables. The phrase 'one accessible public webpage' also sets a clear scope.

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 this tool: for public webpages that need readable text/Markdown extraction. It explicitly states what it does NOT do ('Does not execute JavaScript or bypass access restrictions'), which helps an agent avoid using it for dynamic or restricted pages. However, it does not explicitly name alternative tools for those cases, so it stops short of a 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?

Annotations already signal this is not read-only and not destructive. The description adds useful behavioral context: responses are not lost and remain privately accessible until expiry. This goes beyond the annotations and clarifies the side effects of closing the form.

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 with no filler. The primary action is front-loaded, and the retention/accessibility consequence is stated economically. Every word 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 simple two-parameter tool with no output schema, the description conveys the core action and an important side effect. However, it leaves parameter semantics entirely unexplained and does not clarify what 'expiry' refers to, so the definition is adequate but not fully complete.

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 explain what 'id' or 'token' mean or how they should be supplied. Since the schema provides no property descriptions, the tool description carries the full burden, and it does not compensate.

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 ('Stop accepting responses') and identifies the resource (a form's responses), and the retained-accessibility clause distinguishes it from delete_form. The name collect_close_form reinforces the resource, so an agent can confidently separate it from siblings like collect_delete_form or collect_read_responses.

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 the tool (when no more responses should be accepted) but provides no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The agent is left to infer the decision boundary between closing a form and deleting it.

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 declare the tool is not read-only and not destructive, and the description goes beyond them by disclosing the $1 credit cost after trial, the 30-day lifetime, the 100-response cap, and the return of a public link and private owner token. This adds meaningful behavioral context not present in annotations, though it does not describe potential side effects like credit depletion during trial.

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, compact sentence that front-loads the core action and constraints. It is free of unnecessary words and clearly structured, though it could be slightly enhanced by separating the cost and return info into distinct sentences for readability. Still, it is appropriately concise.

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 tool has 3 parameters (2 required) and a nested question schema, the description provides only high-level context: lifetime, response limit, cost, and return types. It does not explain how to structure questions or what constitutes valid input, leaning entirely on the schema. It also lacks guidance on when to create a form versus other operations. The description is adequate but leaves several important decision points 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%, and the description does not mention any of the three parameters (title, questions, description). It fails to compensate for the low schema coverage, leaving the agent entirely dependent on the schema to understand parameter meaning, which is a significant gap for a tool with nested objects and required fields.

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 identifies the tool as creating a form with specific constraints (30 days, 100 responses, cost, return values). It is unambiguously distinct from sibling tools like collect_read_form or collect_delete_form, and the verb 'create' plus resource 'form' defines its purpose precisely.

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 guidance on when to use this tool over alternatives. It does not mention scenarios that would favor creating a form, nor does it state exclusions (e.g., 'use collect_read_form instead'). The agent is left to infer usage from the tool name and sibling context.

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 indicate destructiveHint=true, so the description adds no new behavioral context beyond that. It does not disclose the permanence of deletion, side effects on related data, or any irreversibility, which is significant for a destructive operation with no annotations covering those details.

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 concise sentence, front-loaded with the verb and object. It is efficient with no wasted words, but the brevity sacrifices critical detail.

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 minimal annotations, the description is too sparse. It omits confirmation of deletion, error handling, and the requirement for the token, making it inadequate for a destructive tool with two 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?

The input schema has 0% description coverage, so the description must explain the parameters. It merely lists 'id' and 'owner token' without elaboration, failing to clarify what 'id' refers to (form ID?) or the token's role, leaving the agent without essential parameter 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 the verb 'delete' and the resources 'form and its responses', which is clear. However, it does not differentiate from the sibling 'collect_close_form' or other delete tools like 'droplink_delete_document', leaving the agent to infer the distinct use case.

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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites like needing the owner token or when deletion is appropriate, leaving the agent without context for 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?

Annotations already cover read-only and non-destructive behavior. The description adds meaningful behavioral context beyond those annotations: the tool only accesses public data and deliberately avoids exposing answers or owner credentials. This helps an agent reason about privacy and data scope.

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 two short sentences with no filler. The primary verb and resource are front-loaded, and the additional sentence earns its place by clarifying a critical boundary.

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 one-parameter read tool with no output schema, the description states what will be returned (questions and availability) and what will not be returned (answers, owner credentials). The only notable gap is not explicitly linking the 'id' parameter to the form, but the overall context is sufficient for a competent 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?

The schema has 0% description coverage and the sole parameter 'id' is undocumented. The description never explicitly says that 'id' refers to the form being read; it only implies this through the word 'form' in the description. With low schema coverage, the description should compensate but does not directly address the 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?

The description uses a specific verb ('Read') and a clear resource ('public form questions and availability'), and it names the key boundary that distinguishes it from collect_read_responses: it does not expose answers or owner credentials. This makes the tool's purpose immediately identifiable 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?

The description gives clear context for when to use the tool: when public form questions and availability are needed. It also states an exclusion—'Does not expose answers or owner credentials'—so an agent understands that answer-related needs should go elsewhere, though it does not explicitly name the alternative sibling.

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 and destructiveHint=false, establishing this as a safe read operation. The description adds meaningful context that retrieval is private and requires the owner token, but it does not disclose behavior on invalid tokens or describe the return shape.

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. Every word contributes: the action, the resource, the privacy aspect, and the authentication requirement.

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-parameter read-only tool, the description provides the essential context: what is retrieved (form and answers), how it is accessed (owner token), and the privacy level. It omits response structure or error behavior, but this is not critical given the simplicity of the 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%, so the description must compensate. It maps id to the form being retrieved and token to the owner token, giving both parameters meaningful semantics despite not explicitly stating formats.

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 the core operation with a specific verb (retrieve), a clear resource (a form and its answers), and an explicit access condition (owner token). It differentiates itself from siblings like collect_read_form by focusing on answers, though it does not name the 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?

Provides clear context: use this tool when you need to retrieve a form and its answers and you have the owner token. It does not explicitly mention alternatives or when not to use it.

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 indicate this is not read-only and not destructive, so the write nature is covered. The description adds useful constraints: per-answer text limit of 2,000 characters, 32 KB total, and the requirement that the form be open. It does not, however, disclose whether submissions are idempotent, whether duplicates are allowed, or what error behavior occurs for closed forms.

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 filler, with the core action and key limitation front-loaded. Every clause adds useful 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 write operation with no output schema and minimal annotations, the description gives the essential input shape and constraints, but it omits success/failure behavior and the consequences of submitting to a closed or previously submitted form. An agent could invoke it correctly but would be surprised by some error 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 0%, so the description carries the burden. It adds meaning by explaining that the keys of the answers object are question IDs and that answers are limited to 2,000 characters/32 KB total. It does not explicitly identify the top-level id parameter as the form ID, nor explain when array values are 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 names a specific action ('Submit answers') and a specific resource ('an open form'), and clarifies the keying mechanism: answers are keyed by question ID. This makes it easy to distinguish from sibling tools like collect_read_form and collect_read_responses, which are clearly not submission 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?

The phrase 'to an open form' implies the main precondition (the form must be open), but the description does not explicitly say when to prefer this tool over alternatives or what to do if the form is closed. No alternative tools are named, so the guidance remains implied rather than explicit.

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?

Given that destructiveHint=true is already present, the description adds useful behavioral context beyond the annotations: the deletion is immediate, acts on a published DropLink, and requires a private deletion token. It does not overstate or contradict the annotation.

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, front-loaded sentence that communicates the action, the target state, immediacy, and the required credential with no wasted words. It is concise without being under-specified.

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 destructive tool, the description covers the core operation and the sensitive token requirement. However, with no output schema and no parameter descriptions, it leaves the id parameter ambiguous and does not clarify what a successful deletion returns or how the token is obtained.

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 both parameters. The token's role is clarified as a private deletion token, but the id parameter is left entirely implicit, with no indication that it identifies the target DropLink. This is a meaningful gap for a required 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?

The description states a specific action ('Delete'), a clear resource ('published DropLink'), and a distinguishing mechanism ('using its private deletion token'). It is immediately distinguishable from sibling tools like droplink_read_document and droplink_publish_document.

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 context by specifying that deletion applies to published DropLinks and requires a private deletion token. It does not explicitly enumerate when-not-to-use or name alternatives, but the scope is clear enough for an agent to route to this tool for deletion.

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 description adds substantial behavioral context beyond the annotations: the page is publicly shareable, expires after 24 hours, the deletion token is returned only once, and scripts, images, and embeds are stripped. This is critical for an agent to set expectations about privacy and formatting.

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 cover the main action, the return token behavior, sanitization, and limits. No filler or redundancy exists, and key 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?

The description covers purpose, return contract, sanitization, expiration, and size limits, which is strong for a tool with no output schema. A minor gap is not explicitly describing the full response shape (e.g., whether a URL is returned along with the token), though the phrasing strongly implies 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?

Since schema description coverage is 0%, the description compensates by explaining that format accepts markdown or csv within an 80,000-byte limit)Skip and mentioning CSV-specific limits (500 rows, 30 columns). It does not explicitly detail the optional title parameter, but the core parameters are well 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 (Publish) and resource (Markdown report or CSV table), and specifies the outcome: a readable, publicly shareable page for 24 hours. This clearly distinguishes it from sibling tools like droplink_read_document and droplink_delete_document.

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 makes the intended use implicit: publish temporary documents for sharing. However, it does not explicitly state when to choose this over sibling tools or mention exclusions such as 'use droplink_read_document to view the page' or 'use droplink_delete_document to remove it.'

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 and destructiveHint=false, so the safe read profile is established. The description adds valuable behavior beyond that: the document must be published, expired links return 404, and the result includes the document and its expiry. It does not cover authentication or output shape, but the annotation coverage lowers the bar.

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 with no filler. The main action, the scope, and the relevant 404 failure mode are all front-loaded. 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 single-id read tool with no output schema, the description covers the operation, the precondition that the document must be published, the expected failure signal, and that expiry is part of the result. It does not describe the response structure or auth requirements, but the annotations already establish the safety profile and the complexity is low.

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 schema has one required string parameter, id, with 0% description coverage, and the tool description never explicitly explains that id must be the DropLink document ID. The tool name and 'Read a published DropLink document' make the parameter inferable, but the description adds no parameter-specific meaning beyond what the schema field name already implies. With low schema coverage, this is a clear 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?

The description names a specific action and resource: 'Read a published DropLink document' and its expiry. It also gives the observable edge case of expired links returning 404, which sharply distinguishes this read tool from the droplink_delete_document and droplink_publish_document siblings. There is no ambiguity about what the tool does.

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 clearly frames this as the tool for reading already-published DropLink documents and warns that expired links will return 404, which helps an agent anticipate failure. It does not explicitly name alternatives, but the close Droplink siblings are delete and publish, so the read role is unambiguous. Slight lack of an explicit when-not-to-use statement keeps it from being a 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?

Beyond the sparse annotations, the description discloses concrete behavioral traits: the service is free, input is capped at 1 MiB, output is capped at 100 items, and it neither fetches URLs nor retains feed content. This meaningfully informs the agent about limits, privacy, and external interaction. It adds substantial value over the boolean hints.

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 convey purpose, accepted formats, service limits, and behavioral constraints with zero filler. The core action is front-loaded, and every clause adds useful 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 simple two-parameter tool with no output schema, the description is nearly complete: it states the input format, output format ('stable JSON'), limits, and side-effect behavior. It does not detail the JSON output structure or error handling, but those are not required to invoke the tool 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%, so the description must compensate. It does by specifying that the input is an RSS 2.0 or Atom XML feed, and that returned items are capped at 100, which maps to the 'limit' parameter. It does not explicitly mention the 'limit' name or its default of 50, but the parameter names are self-explanatory and the description adds format-level meaning.

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 ('Normalize one RSS 2.0 or Atom XML feed to stable JSON'.) It clearly identifies the input format, the action, and the output. The name and siblings do not blur the purpose; this is distinct from all listed 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?

The description implies when to use the tool: when you have RSS 2.0 or Atom XML and want stable JSON. It also gives useful 'not-for' context ('Does not fetch URLs'), which tells the agent this tool is not for retrieving feeds. However, it does not explicitly name alternatives or provide when-not-to-use guidance beyond that.

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 indicate this is a mutating tool (readOnlyHint false) with no destructiveness. The description adds valuable behavioral details beyond annotations: the 24-hour duration, the 100-event capacity, and the 16 KB per-event constraint. It also hints at the separate incoming and reading channels, which is useful for understanding how the tool behaves.

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 two sentences, front-loaded with the primary purpose ('Create a 24-hour webhook inbox') and followed by a single concise constraint (limits). Every word adds value; no filler or redundant qualifiers.

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 creation tool with one optional parameter, the description covers the core purpose and constraints. However, it omits the meaning of the 'title' parameter, and since there is no output schema, it does not hint at what the return value might be (e.g., an inbox ID). The description is adequate but leaves the title parameter unexplained, which limits completeness.

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 schema has one optional 'title' parameter with 0% description coverage, and the tool description does not mention the title at all. The agent is left guessing what role 'title' plays—whether it is a label, a display name, or something else. Since the description fails to compensate for the schema's lack of documentation, this is a clear 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?

The description states a clear verb 'Create' and a specific resource '24-hour webhook inbox', and differentiates it from siblings like hookbox_delete_inbox and hookbox_read_inbox by its action. It also adds capability details (independent incoming, private reading) that make its purpose 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 provides clear context (24-hour lifetime, event limits) that helps decide when to use it, but does not explicitly compare it to sibling tools or state when not to use it. Since it is the only create tool among siblings, the use case is strongly 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?

Annotations already declare destructiveHint=true, and the description adds meaningful scope by stating that stored events are deleted along with the inbox. This goes slightly beyond the structured annotation by clarifying the cascade effect, though it does not mention irreversibility or authorization requirements.

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, front-loaded sentence with no filler. It states the primary action first and then the additional consequence, which is exactly the information an agent needs in minimal space.

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 delete operation, the core effect is covered, and the destructive annotation plus cascade note provide useful context. However, with no output schema and zero parameter documentation, the description leaves the agent without clarity on required authentication, response behavior, or potential failure 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 0%, so the description carries the full burden of explaining parameters. It provides no explanation of what 'id' or 'token' mean, what formats or constraints apply, or how they relate to the inbox being deleted. The parameter names are weakly self-explanatory, but the description does not compensate for the schema 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?

The description uses a specific verb ('Delete') and resource ('webhook inbox'), and further clarifies that all stored events are also removed. This makes it clearly distinguishable from the sibling tools hookbox_create_inbox and hookbox_read_inbox.

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 intended use is implied by the action itself: use this when a webhook inbox should be removed. However, there is no explicit when-to-use or when-not-to-use guidance, no mention of alternatives, and no caution about prerequisites such as needing a valid token.

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 and destructiveHint=false, so the safety profile is provided structurally. The description adds meaningful behavioral context by specifying that access relies on a private read token, which is important authentication information not covered by 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, front-loaded sentence with no filler. It conveys the operation, the resource, and the auth requirement in twelve words, which is appropriately concise for a simple read tool.

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 operation with safety annotations and only two required parameters, this is minimally viable. The main missing piece is explicit meaning for the id parameterasi; an agent would likely infer it refers to the inbox id, but the description does not state that directly. No output schema exists, so return values are also unspecified, though 'read' implies the inbox content.

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 schema has 0% description coverage for its parameters不可, so the description must compensate. It clarifies that 'token' is the 'private read token', but it does not explain that 'id' identifies the webhook inbox or describe the expected format of either parameter. This is only partial compensation for the schema 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?

The description states a clear verb ('Read') and resource ('webhook inbox'), and the mention of the private read token hints at the auth mechanism. This distinguishes it from hookbox_create_inbox and hookbox_delete_inbox at a glance, though it does not explicitly name the sibling alternatives.

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 guidance is given on when to use this tool versus the other hookbox read/create/delete tools or other read tools like cleanread_read_page. The only hint is the read-only action itself, with no exclusions, preconditions, or alternative routing.

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 set readOnlyHint false, destructiveHint false, and openWorldHint false, offering little safety context. The description adds significant behavioral traits: maximum page count, file expiration, and a pricing model (trial then 10 cents from prepaid credit). These go beyond the annotations and inform the agent about side effects and resource costs.

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 three concise sentences with no filler. It front-loads the core action, then lists key constraints and costs. Every sentence contributes useful information, making it easy to scan.

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 6 parameters, a oneOf requirement, and no output schema, the description covers the main function and constraints but leaves gaps. It does not mention that title is required, that markdown and sections are mutually exclusive, or what the output looks like (e.g., URL or file path). These are important for correct invocation, so the description is only partially complete.

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 explain the parameters. It mentions Markdown or structured sections and layout options, which map to markdown, sections, and template. However, it does not explain title, author, subtitle, or the oneOf constraint that exactly one content type must be provided. The required title parameter is omitted, leaving the agent to infer it from 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 clearly states it creates a PDF and specifies the layout options (report, proposal, briefing) and input types (Markdown or structured sections). This distinguishes it from sibling tools like chartlink_create_chart or collect_create_form, which target different artifacts.

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 does not provide explicit guidance on when to use this tool versus alternatives. It mentions constraints (max 10 pages, 24-hour expiry, cost) but does not say 'use this when...' or point to a sibling tool for other cases. The cost and page limit imply trade-offs, but that is not explicit usage 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?

Annotations declare openWorldHint=true but offer little detail, so the description carries useful additional weight. It discloses that the tool reports blocked and unreadable sources honestly and explicitly says it does not verify factual truth. This goes beyond the annotations by setting expectations for reliability and limits. It does not mention network-side effects or privacy implications, but these are reasonably implicit for a URL-checking 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?

The description is three short sentences, front-loads the main action and outputs, and each sentence adds meaningful information. The limitation about factual truth is valuable and not repetitive. There is no filler or unnecessary restating 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 the tool's low parameter count and lack of output schema, the description covers the essential behavior, input constraints, output data points, and honest failure reporting. It could be slightly more complete by describing the result shape or matching semantics, but it is sufficient for an agent to select and invoke the tool correctly 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 0%, so the description must compensate for the property definitions. It does refer to 'URLs' and 'optional quotation matches', which maps to the sources.url and sources.quote fields, and it mentions the ten-item maximum. However, it does not clarify how quotation matching works (e.g., exact, case-sensitive, substring) or how blocked/unreadable results are represented, leaving some ambiguity for an agent.

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-resource pair: 'Check up to ten public source URLs'. It enumerates concrete outputs (successful HTTP responses, final URLs, titles, quotation matches) and adds an explicit limitation ('Does not verify factual truth'). This clearly distinguishes the tool from siblings like cleanread_read_page or tablelift_extract_tables, which serve different purposes.

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: it is for verifying public source URLs, checking their availability, and testing quotation matches. It also states the count limit (up to ten) and the honesty guarantee for blocked or unreadable sources. It does not explicitly name alternative tools or state when not to use it, so it falls short of a 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?

Annotations provide no hints (all false), so the description carries the burden. It discloses cost, size/page limits, and that no charge applies when no useful tables are found. It does not explicitly state that the operation is read-only, but given the extraction nature and lack of destructive intent, the key behavioral traits are sufficiently covered.

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 compact and front-loaded: the core action and output come first, followed by constraints and cost. Every sentence adds essential information without fluff 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?

The description explains the output format (CSV/JSON with page numbers) and covers constraints and cost. It does not specify the exact structure of the output or how multiple tables are handled, but given the lack of an output schema, this level of detail is reasonable and sufficient for an agent to decide to use the 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 50% (only pdfBase64 has a description). The description repeats the 3MB limit but does not add meaning for the filename parameter, which remains undocumented. It reinforces the main parameter's purpose but does not fully compensate for the missing filename 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 clearly states the action ('Extract bordered tables from a text-based PDF') and the output format ('CSV and JSON with source page numbers'). It also distinguishes itself by specifying limitations ('Scans and borderless tables are unsupported'), making it distinct from sibling tools like page readers or chart creators.

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 when the tool is applicable (text-based PDFs with bordered tables) and gives constraints (max 3MB, 10 pages). It also mentions unsupported inputs, which reinforces usage boundaries. However, it does not explicitly name alternative tools, though the unsupported conditions imply when not to use it.

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