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

Annotations already mark this as read-only and idempotent, lowering the bar. The description adds valuable behavioral details: the default model is free Workers AI Llama-3.3-70b, passing `_apiKey` enables Anthropic probing with a BYO key (and direct payment), and the return shape includes per-model {score, confidence, signals, raw_response} plus a combined view. This goes beyond what annotations provide, though it does not cover rate limits or failure modes.

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 three sentences, front-loaded with the core action and output, then defaults, then return format, then use cases. Every sentence earns its place with no fluff or repetition of schema details, making it highly efficient and well-structured.

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?

Despite lacking an output schema, the description compensates by explicitly listing the return structure (per-model fields + combined view). It also covers when to use the tool and the key configuration nuance. It is reasonably complete for a probe tool, though it does not detail the meaning of 'signals' or handle edge cases like invalid keys.

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 baseline is 3. The description enriches parameter understanding by explaining default behavior (omit models for free workers-ai), the conditionality of `_apiKey` (required only if 'anthropic' is in models, passed through to Anthropic), and the cost implication of using the key. This adds meaning beyond the schema field descriptions.

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 starts with a specific verb and resource: 'Probe one or more LLMs for what they know about a business / brand / product / topic and score visibility (0-100) per model.' It clearly distinguishes from siblings like ask_pipeworx (asking questions) and scan_competitor_ai_presence (competitor-specific), making 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 provides clear context with 'Useful for AI-marketing audits, pre-launch brand checks, competitive monitoring,' but it does not explicitly mention when not to use this tool or point to alternatives among the siblings. It gives clear usage scenarios without exclusions, so it earns a 4 rather than a 5.

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