netcafe-tasks

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

Beyond the read-only/idempotent annotations, the description discloses that it fetches from a real mainland-China egress and reports three metrics (HTTP status, latency, China DNS resolution). This gives the agent a concrete model of the operation without needing to infer.

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 well-structured sentences, front-loaded with the action and output, and the explanatory value proposition is concise. No wasted words.

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 only one parameter and an output schema present, the description covers the tool's purpose, method, and key return data. Siblings are unrelated, and no additional context is needed for tool selection.

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 covers 100% of the single parameter with a clear description ('Full URL to test'), so the description adds no additional parameter semantics. 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?

Description clearly states it fetches a URL from a real mainland-China network egress and reports HTTP status, latency, and DNS resolution. The purpose—testing China reachability—is specific and distinct from the unrelated sibling task-management 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 frames when to use: to get a measurement-based answer to 'is my site/API usable from China?' and notes why a VPS abroad cannot provide this. It doesn't enumerate explicit 'when not to use' cases, but the context is clear and sufficient for 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?

The description goes well beyond the annotations by explaining that tasks run fully on the cloud with nothing kept running locally, notifications fire only on actual result changes, pipeline runs leave proof-carrying work orders, and a workspace token is required for later management. It also discloses cost and capacity limits. This is rich behavioral context not available from annotations alone and shows no contradictions.

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 dense but efficiently structured: the core purpose is front-loaded, followed by notification behavior, kind definitions, an important auth prerequisite, and cost note. Every sentence contributes useful information, though a slightly more structured layout (e.g., bulleted kinds) would improve scannability.

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 the main purpose, all kinds, input semantics, notification behavior, auth requirements, and pricing/capacity. It leaves return-value details to the output schema, which is appropriate. A small gap is not describing error conditions or what happens on failed runs, but this is not critical for an agent selecting and invoking 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 coverage is 100%, so the baseline is 3. The description adds substantial meaning to the kind parameter by explaining exactly what watch_page, daily_answer, watch_reachability, and pipeline each do, and clarifies that input can be a URL or a question. It does not add further details for notify_url or interval_seconds beyond the schema, but the existing enrichment is valuable.

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: 'Create a task that runs on a schedule in our cloud.' It goes beyond a generic statement by enumerating the four task kinds and their exact use cases, making it clearly distinct from sibling tools like delete_task, list_tasks, and get_task_runs.

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 practical context for when to use this tool: when you want a recurring, server-side scheduled task rather than a one-off operation. It also specifies a prerequisite (workspace token) and references create_pipeline for the pipeline kind. It does not explicitly state when not to use this tool in favor of alternatives like china_reachability, but the kind descriptions provide enough 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 already declare destructiveHint=true and idempotentHint=true. The description adds the behavioral detail that run history is also removed, and that the task is stopped first. This enriches understanding without contradicting 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, concise sentence of 10 words, front-loaded with the action 'Stop and remove' and no unnecessary words. It earns its place entirely.

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 destructive tool, the description, combined with annotations and schema, is sufficient. It covers purpose, side effects, and parameter provenance. The presence of an output schema further reduces the need to explain return values.

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 100% coverage, with task_id described as 'From list_tasks.' The description does not add additional parameter guidance, but the schema already fully informs the agent where to obtain the ID. 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 explicit verbs 'Stop and remove' with the resource 'a scheduled task and its run history', clearly distinguishing this from sibling tools like create_task, list_tasks, and get_task_runs. It states exactly what the tool does without ambiguity.

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 that this tool is for permanently eliminating a task and its history, which implicitly indicates when to use it. However, it does not explicitly mention alternatives or exclusions, 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 cover read-only/idempotent/non-destructive behavior; the description adds useful context about the payload (returned value, change flag, platform cost metadata) and explicitly states the user charge is $0.00. It does not contradict annotations and supplies behavioral details beyond the structured fields.

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?

Description is two sentences, front-loads the core action, and every phrase adds value. It avoids repetition of schema or annotation fields and ends with the cost note that is directly useful for decision-making.

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 a full output schema, complete parameter descriptions, and safety annotations, the description is nearly sufficient. It could be improved by an explicit usage guideline or mention of the need for a valid task_id, but nothing critical for invoking the tool correctly 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%, so the baseline is 3. The description's mention of 'recent runs' and 'one scheduled task' loosely maps to limit and task_id but adds no format, constraints, or semantics beyond what the schema already 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 uses a specific verb phrase 'Recent runs of one scheduled task' and enumerates the returned information (return value, change status, cost metadata), clearly distinguishing it from siblings like list_tasks (which lists tasks) and create_task/delete_task (which mutate tasks). The title reinforces the purpose without ambiguity.

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 the tool is for inspecting a specific task's output, but it does not explicitly state when to prefer this over list_tasks or mention prerequisites such as obtaining a task_id from create_task/list_tasks. The parameter schema provides task_id provenance, but the description itself offers no direct alternatives or exclusions.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat that. It adds useful context beyond annotations by specifying the kind of data returned (run times, run counts, cost metadata) and noting the $0.00 beta charge, which gives the agent practical information about invocation consequences.

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 action is front-loaded, followed by the specific data fields, and the beta cost note is an additional distinct 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?

For a zero-parameter, read-only listing tool with an output schema and safety annotations, the description covers the key details needed to invoke and interpret the result. The only minor gap is the lack of explicit differentiation from get_task_runs, but this is not critical for a standalone list operation.

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 semantics burden. The schema is trivially complete at 100% coverage, and the description appropriately focuses on output rather than inputs.

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

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

The description states a clear verb ('Show') and resource ('scheduled tasks'), and elaborates with specific fields: next run times, run counts, and cost metadata. This distinguishes it from create/delete operations, though it does not explicitly differentiate itself from the sibling get_task_runs.

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 says what the tool does but provides no guidance on when to use it versus siblings like get_task_runs. There are no explicit usage conditions, exclusions, or alternatives mentioned, leaving the agent to infer when this list view is appropriate.

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, idempotentHint, and destructiveHint. The description adds valuable behavioral traits not visible in annotations: deterministic, calls no model, costs nothing, and never runs out of quota. 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?

Four dense sentences, front-loaded with the core purpose in the first sentence and supported by recipes, cost/quota guarantees, and when-to-use guidance. Every sentence earns its place; no filler or repetition.

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 context (single required string parameter, rich annotations, and an output schema), the description is complete. It covers the tool's behavior, return value highlights, performance/cost characteristics, and usage context without leaving important gaps.

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 describes the 'task' parameter with examples, and schema coverage is 100%. The description adds the nuance 'plain language (any language)' and emphasizes that example calls are generated, providing modest additional 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 clearly states the tool's purpose with a specific verb+resource: describe a task and get back exactly which tools on the server do it, with ready-to-run example calls. It explicitly distinguishes itself from sibling tools by positioning itself as the meta-guide that prevents 'reading the whole catalogue and guessing.'

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 explicit when-to-use guidance: 'Call this FIRST when you are not sure what this server offers.' It also clarifies the intended use case (plain-language task discovery) and contrasts with the alternative of scanning the catalogue manually, which is sufficient for a meta-tool.

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