Qovia

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

Adds context the annotations do not carry: invocation incurs cost only when data is returned, so empty results and failures are free, and an account link is required. Annotations do declare readOnlyHint=true, so the description rightly focuses on the billing side effect rather than safety, but it says nothing about rate limits or error behavior beyond the free-on-failure rule.

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 action and return payload, followed by the account requirement and cost rule. No filler or restatement 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?

With no output schema, the description usefully names the billing fields returned alongside data and covers the prerequisite and cost model. It omits what a caller should expect on invalid endpoint_id or what 'data' looks like, but is otherwise sufficient to invoke 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 100%, so the schema already documents both endpoint_id (with an example) and params. The description adds no parameter-level meaning beyond what the schema provides, which is the expected baseline when the schema does the work.

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?

Uses a specific verb and resource ('Run an endpoint and return its data plus billing info') and names the concrete return fields charged_usd and remaining credit. It does not explicitly say how it differs from the sibling get_endpoint (which only reads metadata without executing), leaving the run-vs-inspect distinction to be inferred.

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?

States one real precondition — a Qovia account must be connected to this server — and implies usage by mentioning get_endpoint for parameter discovery. It does not say when to choose this over get_endpoint or search_endpoints, nor when to avoid calling it given the billing cost.

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 safety is covered. The description adds real behavioral context the annotations do not: the call is free but still consumes rate-limit budget, which matters for agents deciding whether to poll it.

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: the first states what is returned, the second the cost model. Nothing is padded and the most decision-relevant clause (free, rate-limited) is not buried.

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 parameters and no output schema, the description carries return-value burden and does name the three things returned (credit, plan, rate limit), plus a cost caveat. It could say slightly more about the shape of that response, but an agent has enough to call it 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?

The tool takes zero parameters, which is the baseline-4 case. Nothing in the description is needed to explain inputs, and it adds no misleading input claims.

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?

Specific verb-plus-resource: it returns the connected Qovia account's credit, plan, and rate limit, which an agent can distinguish from the endpoint-oriented siblings (get_endpoint, search_endpoints). It stops short of naming a sibling or explicitly stating it is the only account-level tool.

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?

'Free; counts toward the rate limit' gives a cost signal that implies when it is cheap to call, but there is no explicit when-to-use or when-not-to-use guidance and no alternative is named. Eligibility is inferable (any time account standing is relevant) rather than stated.

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, and the description adds genuinely new behavioral context: the operation is free and requires no authentication, and it discloses the full content of the returned payload. It does not mention rate limits, caching, or error behavior for unknown IDs, keeping it below 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?

A single front-loaded sentence naming the resource first, then the payoff, then the cost/auth note. The enumerated list of returned artifacts is dense but every clause carries information; nothing is wasted.

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?

One required string parameter, no output schema — and the description compensates by listing the return contents and the cost/auth conditions. An agent has everything needed to decide and invoke 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?

Only one parameter exists with 100% schema coverage and an inline example (raw.douyin.video), so the schema carries the burden. The description's phrase "its parameters (JSON Schema)" refers to the endpoint's own parameter spec, not the endpoint_id argument, so it adds no semantics beyond the schema — baseline 3.

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?

Specific verb + resource ("Show one endpoint") plus an enumeration of exactly what the response contains (return shape, parameters, examples, price). It differentiates itself from the read-only siblings implicitly by covering a single endpoint in full, though it never names search_endpoints or call_endpoint.

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?

"Free; no sign-in required" gives a useful precondition, and the detail-heavy output description implies this is the 'inspect before you call' tool. However, there is no explicit guidance such as 'use search_endpoints to find an endpoint_id' or when to prefer call_endpoint, so routing is left to inference.

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/non-destructive, so the bar is lower; the description still adds real context by disclosing the response shape (ids, titles, price per call, live status) and the free/no-auth access condition. It doesn't mention pagination or result limits, so not 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 sentences, zero filler, with capability and filter axes front-loaded before the return/auth details. Every clause carries 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 3-parameter, all-optional search tool with no output schema, the description covers filters, return fields, cost and auth. Nothing an agent needs in order to invoke it 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 coverage is 100%, so baseline is 3, but the description goes further: it enumerates the valid platform slugs the schema only calls 'Platform slug', explains the keyword can be Chinese or English, and ties include_unavailable to the 'live' flag being returned.

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 (search) plus resource (Qovia data endpoints) and the two filter axes, and names the platform slugs in scope. It is clearly distinguishable from get_endpoint/call_endpoint by implication, but never explicitly routes away from those siblings.

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?

Gives clear context for use: keyword can be Chinese or English, filters can be combined with 'and/or', and the call is free with no sign-in. It stops short of naming alternatives (e.g. get_endpoint for fetching a known id), so no exclusions are stated.

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