Lists CAPTCHA tasks for the current user and team, filters records by productCode keyword, and shows original charges after refunds; verify refunds via billing records.
List CAPTCHA tasks of the current user and team; keyword matches productCode. price stays the original charge after refunds; check billing for refunds.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| size | No | ||
| keyword | No |
Changes observed during successful MCP inspections.
v2026.10.24Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered; the description adds genuine context beyond that: the result scope is user plus team, keyword matching is by productCode rather than a free-text search, and 'price stays the original charge after refunds' clarifies a returned field. It does not mention the paging behavior implied by page/size, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact clauses, front-loaded with the resource and scope, with the caveat about refunds trailing as secondary detail. Every phrase carries information; only the billing aside borders on tangential.
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 three-parameter list tool with no output schema and no annotation detail beyond read-only, the definition covers scope and one return-field nuance but leaves pagination and the other two parameters unexplained. Adequate to call correctly for a simple listing, but not 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 carries the full burden, yet it only clarifies one of three parameters (keyword matches productCode). The page and size parameters, including size's 1–1000 bound and default of 20, are left entirely to the schema with no description support.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List CAPTCHA tasks') plus the ownership scope ('of the current user and team'), which is what an agent needs to distinguish it from a single-task fetch. It does not explicitly name how it differs from siblings like nex_captcha_product_list or nex_captcha_query, so differentiation is left implicit.
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?
Usage is implied by the ownership scope — this lists your own and your team's tasks — but there is no explicit when-to-use or when-not, and no pointer to nex_captcha_query for single-task detail. The keyword note ('keyword matches productCode') is the only concrete usage hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.