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

Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint=false), it discloses that lookups consume credits and that repeated calls may re-purchase data — genuinely useful billing and idempotency context. But the cost statements conflict ('at least 10 Nexscope credits' vs '1 credit per request'), so the agent cannot determine the real charge.

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 core sentence is repeated nearly verbatim, and the text is polluted with scraped UI artifacts ('API View Pricing', 'Actual supplier units are reported per request', 'Examples are not guaranteed prices'). The useful information is buried rather than front-loaded, and pricing lines contradict each other.

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 one-parameter read-only lookup, the description conveys input intent and output shape (coordinates for the Search endpoint). It is missing what a result set looks like (single best match vs. list of candidate cities) and leaves the credit cost ambiguous, which matters for a paid 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?

Schema coverage is 100% for the single 'query' parameter, so the schema already carries the burden. The description adds only marginal meaning by clarifying that queries are location/city names; it gives no format examples or matching behavior (partial names, country qualifiers).

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: searches Facebook Marketplace locations/cities and returns coordinates. It also distinguishes itself from the sibling that consumes its output by naming the Marketplace Search endpoint. The doubled 'Facebook Marketplace Marketplace' wording and appended marketing boilerplate muddy the otherwise clear statement.

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 intended workflow (call this first, then feed the coordinates into the Marketplace Search endpoint), which is real usage context. However, it never states when NOT to use it, gives no alternative for direct keyword searches, and doesn't name the sibling tool explicitly.

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