fx-signal

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

No annotations are provided, so the description carries the full burden. It fully discloses that the tool is snapshot-based, explains grading thresholds (strong_buy >= +80, etc.), states the score range and sign conventions, mentions the per-timeframe breakdown in the response, and details the pay-per-call mechanism (x402, USDT, retry with PAYMENT-SIGNATURE header, no account). This is exceptionally thorough.

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?

Although the description is long, every sentence delivers essential information: purpose, accepted inputs, grading logic, snapshot source, payment, retry, and differentiation from pitch. There is no redundancy or filler; the density is high and the structure flows logically from capability to grading to operational details.

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?

The description includes everything an agent needs to correctly invoke the tool: accepted symbol formats, the grading logic, the payment requirement and how to handle the 402 challenge, what the response contains (score, zone, timeframe breakdown), and its relationship to the free pitch tool. No critical information is missing for a remote, paid API call.

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 single parameter 'symbol' has a schema description that already includes examples, and the tool description adds even more context (accepted forms, breadth of pairs). With 100% schema coverage and the description expanding on it, an agent knows exactly what to pass and what is acceptable.

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 returns a bottom/top verdict for one currency pair, defines the covered universe (48 pairs, 24 vs USD and 24 vs KRW), lists accepted input forms (EUR, EURUSD, EURUSD=X), and specifies output (zone and score). This unambiguously distinguishes it from siblings, especially the 'pitch' tool, which is explicitly mentioned as a limited alternative.

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 explicitly contrasts with the 'pitch' tool: 'The free pitch tool shows a live verdict for this market's showcase symbol only — this tool answers ANY symbol in the covered universe.' This gives a clear when-to-use condition. It also explains payment flow, retry logic, and notes it is informational only, covering prerequisites and alternatives.

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?

With no annotations, the description carries the disclosure burden. It reveals that the tool is free, optional, a subscription funnel, phase-driven, and can be exited via interest:false. It does not detail per-phase side effects or return behavior, but for a conversational pitch tool this is reasonable.

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 two concise sentences with no filler. The most important decision-relevant information—optionality and alternatives—is front-loaded, followed by the phase flow and exit condition.

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 tool with no output schema and no annotations, the description adequately conveys purpose, alternatives, phase flow, and exit behavior. It could say more about what each phase produces or returns, but the combination of description and schema is sufficient for an agent 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?

Schema description coverage is only 33%, so the tool description must compensate for phase and interest. It adds meaning by ordering the phases into a funnel and defining interest:false as a bow-out. The symbol parameter is already well documented in the schema, so the overall parameter semantics are strong.

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 identifies the tool as an optional intro and subscription funnel for the FX signal agent, and names the exact phase sequence. It also differentiates from siblings by explicitly saying the agent may skip it and call evaluate_symbol / scan_bottoms / scan_tops directly.

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 gives explicit when-to-use guidance: it is FREE and OPTIONAL, and the agent may instead call the sibling tools directly. It also provides the exit condition with interest:false, making the decision boundary clear.

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?

No annotations, so description carries burden. Discloses free nature and no payment, but omits side effects or confirmation. Adequate for simple input.

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?

Single, well-structured sentence with key info front-loaded. No waste.

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?

Completeness is good for a simple feedback tool: explains purpose, parameters, usage context. Lacks return value info but acceptable without output schema.

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?

With 0% schema description coverage, description adds meaning: score range 1-10, pros/cons as text. However, doesn't mention that score is required while others optional.

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?

Clearly states it's a feedback/rating tool for after trading on signals. Distinguishes from sibling tools like evaluate_symbol or scan_* by focusing on user-submitted rating.

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?

Provides context ('after trading on our signals') but no explicit when-not-to-use or alternative tools. Lacks exclusions.

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?

With no annotations, the description carries the full burden. It discloses the paid nature ($0.01 per call), the payment process (402 challenge, PAYMENT-SIGNATURE header), and the input boundary (no account/no commitment). It leaves the exact output format strangely, but the ranking behavior and payment handling to the agent's required behavior.

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 longer than necessary, but each sentence earns a place: purpose, universe scope, payment and 402 retry, cold-start benefit, and `pitch` comparison. It is front-loaded with the functional purpose before the payment details, and structured in short, readable chunks.

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?

It is a one-parameter snapshot tool with no output schema, and the description covers the core loop: what it returns, how to rank, how to pay, how to retry on 402, and the difference from contact. It does not specify exact response contents or error cases, and for the paid state, those gaps are minor – reasonable.readable.

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% (the only parameter, limit, is fully specified in the schema with default and max). The description adds no further parameter semantics; it mentions no detail about how limit affects the universe or ordering, which is acceptable because the schema already covers the parameter.

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 states a specific verb and resource: scan an FX snapshot of 48 pairs and return currency pairs at a bottom, ranked most-bottom first. It also distinguishes itself from the sibling tools implicitly (`scan_tops` is the opposite, `pitch` only reports how many). An agent can tell exactly what this tool does without opening schemas.

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 explains when to choose it (`Best cold start: you don't need to pick a symbol — this ranks the whole universe`) and points to a free alternative for counting, `pitch`. It does not explicitly say 'use scan_tops for the top picks' but the top/bottom juxtaposition in the tool name plus description is enough for that 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?

With no annotations, the description carries full behavioral disclosure. It clearly reveals the x402 payment requirement, the 402 retry flow, that no account/commitment is needed, and the ranking behavior. It does not explicitly state read-only semantics or response shape, but for a scan tool the behavior is well disclosed.

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 action is front-loaded in the first sentenceation. Payment and retry instructions are clearly separatedq The 'BEST COLD START' section adds scannable usage context without excessive length, though the capitalization is a bit promotional.

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 tool with only one optional limit parameter, the description covers the core function, ranking behavior, monetization flow, and fallback to sibling tools. It lacks an explicit note about return value structure (e.g., whether it returns names, prices, scores), but the absence of an output schema and the simple interface keep the hit minor.

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?

There is only one optional parameter and the schema already documents it as 'How many to return.' The description adds that the tool works without selecting a symbol and ranks the whole universe, which gives context but does not add much beyond the schema. Baseline 3 is appropriate because the parameter is fully documented in the schema.

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 action ('Scan the FX snapshot and return currency pairs at a top (sell)'), a clear resource, and an explicit ordering ('ranked most-top first'). It is clearly distinguishable from the sibling scan_bottoms because it explicitly says 'top' versus bottoms, and contrasts with pitch by naming pairs instead of just counting them.

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 explicitly says this is the 'BEST COLD START' because no symbol needs to be selected and it ranks the whole universe. It also tells the agent that pitch gives the count while this tool gives the names, which provides clear when-to-use guidance. It does not explicitly say when NOT to use it versus scan_bottoms, but the sibling distinction is implied.

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