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 claims to 'Create a task' which is a state-changing operation, but the annotations declare readOnlyHint=true and idempotentHint=true. This is a direct contradiction: creating a task modifies server state and is not read-only. The additional behavioral details about notifications and token requirements are undermined by this fundamental inconsistency.

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 dense paragraph, but every sentence introduces distinct information: scheduling nature, change-notification behavior, kind definitions, and workspace token requirement. It is not as tightly structured as a bulleted list, but it is efficient and front-loaded with the core purpose.

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

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

Given that an output schema exists and the tool has only 4 parameters, the description covers the essential behavioral context: scheduling, notification conditions, use cases, and auth requirement. It does not explain failure modes or rate limits, but for this scope it is reasonably 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 coverage is 100%, so baseline is 3, but the description adds meaningful semantics beyond the schema by explaining the 'kind' values (watch_page, daily_answer, watch_reachability) and clarifying that 'input' can be a URL or a question. This enriches the bare schema descriptions and helps the agent construct valid parameter values.

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 creates a scheduled task on cloud servers, lists three concrete kinds with explanations, and distinguishes it from sibling tools like delete_task, list_tasks, and get_task_runs. The verb 'create' plus resource 'task' makes the 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 explains that the user doesn't need to keep anything running, that notifications only fire on actual changes, and that a workspace token is required for later management. This gives clear context for using the tool, though it doesn't explicitly state when not to use it or name alternatives beyond the built-in kinds.

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 states actions that are destructive and read-write ('remove', 'run history'), but the annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. This is a direct contradiction, misrepresenting the tool's behavioral profile. This warrants a score of 1.

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 that front-loads the action and outcome. It contains no filler, making it highly efficient and easy to parse.

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?

Although the tool is simple with one parameter, the description is incomplete because it contradicts annotations and fails to disclose the permanent, state-changing nature of the operation. The existence of an output schema is not enough to compensate for the misleading safety signals. This reduces the contextual 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 includes a single parameter task_id with a description ('From list_tasks.'), giving 100% coverage. However, the description adds no further semantic meaning beyond the schema; it does not clarify the type, format, or constraints beyond what is already stated. Thus, baseline 3 is appropriate.

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

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

The description clearly states the action ('Stop and remove') and the resource ('a scheduled task and its run history'), which is a specific verb+resource combination that distinguishes it from sibling tools like create_task and list_tasks. The purpose is immediately identifiable.

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 explicit guidance on when to use this tool or how it compares to alternatives. While the name and siblings imply its role, there is no mention of prerequisites, context, or when not to use it, leaving the agent to infer usage.

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 tool read-only, idempotent, and non-destructive. The description adds value beyond these by explaining what kind of information is returned (result, change indicator, cost), giving the agent insight into the tool's output behavior without restating annotation 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 that front-loads the core purpose and key output details. Every word adds value, with no redundancy or filler.

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

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

For a read-only, simple two-parameter tool with a rich annotation set and output schema, the description sufficiently covers the essential behavioral context. It names the key output elements without needing to detail the return structure, which is already described in the output schema.

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

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

Schema description coverage is 100%, with parameter descriptions already providing semantics (limit max/default, task_id source). The tool description adds no extra parameter information, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves recent runs of a single scheduled task, specifying the returned data (output, change status, cost). This specific verb+resource combination distinguishes it from siblings like list_tasks, which would list tasks themselves.

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 is for viewing run history of one task, implying use when you need details about a scheduled task's executions. However, it does not explicitly mention alternatives or exclusions, such as using list_tasks to find the task_id or when not to use 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 annotations already declare readOnlyHint=true and idempotentHint=true, and the description does not contradict them. The description adds that the tool returns run counts and costs, but it does not disclose any potential side effects, limitations, or requirements beyond what annotations provide. It lacks context about pagination or data scope beyond 'on this workspace'.

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 states the action and the key output details in a straightforward, front-loaded manner with no unnecessary 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?

The tool is simple (no parameters), annotations cover safety, and an output schema exists, so the description only needs to convey the listing intent. It includes the resource and the types of info returned. It could mention ordering or whether inactive tasks are included, but the output schema likely covers details, so it is fairly 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?

The input schema has zero parameters, so the description has no parameter info to clarify. With 0 params, the baseline is 4, and the description adds no confusion.

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 ('show') and identifies the resource ('scheduled tasks on this workspace') and specifies the details returned (next run, run count, cost). This clearly distinguishes it from siblings like create_task or 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 implies this tool is for viewing a summary of all scheduled tasks, but it does not explicitly mention when to use this over get_task_runs (which likely targets a specific task run) or exclude scenarios. There is no explicit when/not guidance.

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