China News Feed

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

With no annotations, the description carries the full burden, and it does disclose two valuable traits: the $8/1,000-row cost on the Apify account and that query/language filtering happens client-side after billing (i.e., filtering does not reduce cost). It remains silent on auth requirements, return shape, and how sources/sourceTypes are resolved.

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 tight sentences, front-loaded with the purpose and immediately followed by the cost implication. No filler, though it is quite terse for a five-parameter 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?

No output schema and low schema coverage mean the description should do more. Billing and filtering semantics are covered, but the meaning and valid values of sources (vs the enum-constrained sourceTypes) are never addressed.

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

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

Schema coverage is only 20% (just maxItems), so the description must compensate. It clarifies that query and language are applied locally post-billing, which is real semantic value, but sources and sourceTypes are left entirely undocumented in both schema and description.

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 ('Fetch') and resource ('China news'), which is distinct from the sibling resources (hot lists, deletions) without needing to name them. No explicit sibling differentiation, but the resource itself is 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 indication of when to use this versus get_hot_lists or get_deletions, and no prerequisites or exclusions. The only contextual guidance is billing mechanics, which is not a use-case signal.

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?

With no annotations, the description carries full behavioral burden. It usefully discloses billing cost ($8 per 1,000 fetched dataset rows, including unflagged rows) and status coverage, but omits auth requirements, rate limits, and return format.

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 zero waste: the purpose is front-loaded and the billing nuance is a crucial second sentence. 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?

Given a 3-parameter tool with no output schema and no annotations, the description is missing too much: parameter semantics, return value structure, auth, and usage alternatives are all absent. Only billing and status scope are covered.

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 only 33%, so the description should compensate for undocumented parameters. It mentions 'dataset rows' loosely aligning with maxItems but does not explain highRank or platforms, nor the enum choices for platforms.

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 gives a specific verb (Fetch) and resource (deletion-watch flags), and adds scope detail ('including provisional and returned statuses'). It does not explicitly distinguish itself from the sibling tools get_china_news and get_hot_lists, but the resource is self-evidently different.

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?

There is no guidance on when to use this tool versus alternatives, nor are prerequisites or exclusions stated. The agent must infer usage from the tool name alone.

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?

With no annotations, the description carries the full burden, and it does disclose a genuinely useful behavioral fact: cost of $8 per 1,000 dataset rows billed to the caller's own Apify account, which implies the user must supply Apify credentials. It stops short of describing whether rows are deduplicated, how filtering interacts with billing, or what the response contains.

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 capability statement front-loaded and the cost caveat immediately after. 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 4-parameter tool with 25% schema coverage, no annotations, and no output schema, the description is far too thin. An agent cannot tell what platforms are returned by default, how language filtering works, or what distinguishes the two count-style 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?

Schema description coverage is only 25% (just maxItems), and the description adds nothing about maxRank, language, or platforms. The billing note tangentially relates to maxItems but does not explain the important distinction that maxRank and maxItems govern different things (ranking depth vs. billed rows).

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 ('Fetch Chinese platform hot lists'), so the core action is unambiguous. However, it never distinguishes itself from siblings get_china_news and get_deletions, nor does it name which platforms qualify as 'hot list' sources, leaving overlap with news-fetching unaddressed.

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?

There is no statement of when to use this tool versus get_china_news or get_deletions, and no prerequisites or exclusions. The only contextual sentence concerns billing, not usage 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?

No annotations are provided, so the description carries the full behavioral burden. It does usefully disclose the auth profile ('no Apify token needed'), but omits return format, sample size, rate limits, or whether results are static/cached — meaningful gaps for a tool with zero annotation coverage.

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 short sentence with no wasted words, and the key value proposition (free, no token) is placed at the end as a clear qualifier. It is perhaps over-sparse for the tool's behavior, but nothing is redundant.

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-only sample endpoint with no annotations and no output schema, the description covers the basics but leaves the sample's size and contents unspecified. An agent can invoke it correctly, but would not know what to expect in return.

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%, but there is only one optional parameter whose bounds (min 1, max 3, default 3) are already self-documenting in the schema. The description adds no syntax or meaning beyond that, so this sits at the adequate baseline rather than compensating for the coverage 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 resource ('English China news feed') and states the deliverable ('free sample'), so the agent knows it returns feed items. The parenthetical 'no Apify token needed' implicitly contrasts with get_china_news, but the differentiation is left for the agent to infer rather than stated directly.

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 only implied: an agent can reason that this is the no-credential fallback to get_china_news when a token is unavailable. There is no explicit statement of when to prefer it over get_china_news, nor any note on limits of the sample (e.g., capped at 3 items).

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