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

Annotations already declare destructiveHint=true, but the description goes beyond by specifying 'Behavior: DESTRUCTIVE... Can open/close positions.' It also details auth requirements ('X-Api-Key required'), cost ($0.01 USDC per call), rate limit (30/min), and tier. It clarifies that billing is not a side effect, and describes return values. This is rich behavioral context that significantly supplements the annotations.

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 well-structured with labeled sections (Purpose, Behavior, Auth, Cost, Rate limit, Returns, Guidelines, Tags), but it starts with the core purpose and then repeats the identical phrase in the 'Purpose:' field, creating redundancy. This duplication makes it longer than necessary, though the structure helps navigation. It earns a 3 due to the unnecessary repetition.

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 destructive execution tool with payment requirements, the description is extremely complete. It covers behavior, auth, cost, rate limits, return values, and usage guidelines. It also clarifies billing as separate from side effects and warns against inventing fills. Given the tool's complexity and the presence of an output schema, this description provides all essential context for safe invocation.

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 schema has 100% description coverage for all 5 parameters, each with explanatory text. The description mentions flexible symbol formats which is also in the schema. However, the description adds no additional meaning beyond the schema—it does not elaborate on semantics of 'side', 'size', 'leverage', or payment parameters. Thus the baseline of 3 is appropriate since the schema does the heavy lifting.

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 clearly states the tool's function: 'Unified signal ingestion endpoint that normalizes symbols from any exchange format to executable format and routes to execution.' It explicitly mentions the ability to 'open/close positions', which distinguishes it from research-only sibling tools. The verb 'Call' plus resource 'cc.central_signal' is specific and 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 includes a 'Guidelines' section: 'Use for research / signal context. Pair with cc.agent_strategy (paper) before any live order. Do not invent fills from this data alone.' This provides explicit context and a caution, though it does not name alternative tools or explicitly state when not to use it. The pairing with paper trading suggests a workflow but falls short of a full when-to-use vs. alternatives comparison.

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