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

Beyond the annotations, it discloses the async contract (returns 202), that a human generates and QA's the artifact against the live surface, that nothing is published on the caller's behalf, and that the score only moves on commit. It also states the pricing model (included in Influence, else $49 one-off with its own receipt, never from prepaid balance), which is exactly the sort of behavioral context annotations cannot carry.

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?

Information-dense but written as a run-on of em-dash fragments with a marketing lead-in ("you are being marked down for not having") that does not help the agent. Pricing and the apis://prices pointer are relevant but placed late, so the critical call mechanics are not front-loaded.

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, no-output-schema tool it covers the async flow, cost, and publication policy well. It leaves unclear what the 202 response body contains, how/when the finished artifact is delivered, and its omit-artifact instruction contradicts the schema, leaving the agent with an unresolved ambiguity.

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 the baseline would be 3, but the description actively conflicts with the schema on the key enum parameter: it says "Omit `artifact` to list what can be made," while the schema says omitting it requests the full set. That contradiction can cause a wrong invocation and outweighs the redundant enumeration of artifact values.

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 verb+resource is explicit ("REQUEST an artifact") and the enumerated artifact types with the 202/human-generated flow make the operation understandable. However, the leading "INFLUENCE — ... you are being marked down for not having" framing buries the actual purpose and the description never distinguishes this from siblings like find_artifacts, get_api_artifacts, or submit_artifact.

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?

It offers one useful routing hint — "if this is your own company and our data about it is wrong, report_correction is free" — and explains the omit-artifact path. But it gives no guidance on when to request an artifact versus looking one up with find_artifacts or submitting one with submit_artifact, so the agent must infer the choice.

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