SentimentFX

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

With no annotations provided, the description carries the full burden and does well: it discloses the returned fields (r, p_value, n_days, CI, strength), the 1-credit cost, the minimum data requirement, and the edge-case behavior with a note field. It does not mention authorization or rate limits, but these are not prominent concerns for a read-only analytical endpoint.

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?

Four sentences, each purposeful: the first states the computation, the second lists output fields, the third notes cost and endpoint equivalence, and the fourth covers the data threshold and fallback. It is front-loaded and free of filler.

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?

Given a single-parameter schema, an existing output schema, and no annotations, the description covers the essential invocation context: what it computes, what it returns, the cost, and the required data volume. It does not explicitly describe when to prefer this over sibling analysis tools, but that gap is minor for a tool of this specificity.

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 0%, so the description compensates by referring to `ticker` as the subject of the correlation and by mentioning 'higher-coverage ticker' in the fallback explanation. The parameter is a single, self-explanatory identifier; the description adds just enough context about its role.

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 opens with a specific, concrete statement: '180-day Pearson correlation between daily sentiment shifts and next-day price returns for `ticker`.' This names the exact computation, resource, and variables involved, making it immediately distinguishable from sibling tools like get_prices or get_sentiment.

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 provides clear context for when the tool is viable by requiring ≥30 overlapping day-pairs and explaining the fallback note when that threshold is not met. It does not explicitly contrast with alternative sibling tools, but the uniqueness of the correlation computation makes the usage context sufficiently 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?

With no annotations at all, the description fully carries the behavioral burden. It honestly discloses API credit cost per day returned, reverse-chronological ordering, currency conventions per asset class (crypto in GBP, FX raw exchange rates, everything else USD), and explicitly states there is no currency conversion. This goes well beyond the structured schema.

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?

Every sentence delivers essential information: function, cost, ordering, and currency rules. The primary purpose is front-loaded, and the additional behavioral details are compact and non-redundant. No filler or repetition exists.

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?

An output schema exists, so the description rightly doesn't repeat return-value structure. It covers cost, ordering, and currency nuances, which are the critical non-obvious details. It could add prerequisites like checking list_tickers for valid identifiers or note limitations on data availability, but the description is sufficiently complete for a tool of this complexity.

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 0%, so the description is the only source of parameter meaning. It clearly explains both parameters: `ticker` is the instrument whose prices are returned, and `days` defines the lookback window. It stops short of documenting constraints like valid ticker formats, maximum days, or the default behavior, but the core semantics are present.

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 opens with a specific verb and resource: 'Return daily close prices for ticker over the last days'. It also adds a key distinguishing detail ('in the ticker's native currency') and a reference to the response's `currency` field, making the tool's function unambiguous and distinct from sibling tools like get_summary or get_sentiment.

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 intended use is strongly implied: use this tool when you need historical daily closing prices for a ticker. However, it never explicitly says when to prefer this over sibling tools, nor does it mention exclusions such as needing intraday data or non-price metrics. The guidance is implicit rather than explicit.

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 and does so well: it discloses the scoring model (FinBERT), the score range and formula, categorical labels, billing behavior ('Costs 1 API credit per 25 headlines actually returned'), free empty results, the limit cap, and reverse-chronological ordering. This is substantial behavioral context beyond a simple 'returns data' statement.

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 compact and front-loaded: purpose first, then return semantics, billing, and constraints. Every sentence adds relevant information, with no filler or repetition of obvious schema facts.

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 two-parameter tool with an output schema, the description covers the core call semantics, return fields, ordering, limit behavior, and cost. It falls slightly short by omitting failure/error behavior and any explicit alternative routing, but nothing critical is missing for a basic successful 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?

Schema description coverage is 0%, so the description must compensate. It does: `ticker` is identified as the subject of the headlines, and `limit` is given meaning through the cap of 100 and the per-25 billing note. It could go further by explicitly stating that `limit` controls the maximum number of headlines returned, but the inference is 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 opens with a specific verb and resource: 'Return the most recent FinBERT-scored headlines for `ticker`.' This clearly distinguishes the tool from siblings like get_prices or get_summary by naming the exact resource type and its sentiment focus.

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 first sentence implies when to use the tool: whenever a caller wants sentiment-scored headlines for a ticker. However, it gives no explicit when-not-to-use guidance or contrast with sibling tools, so usage context is implied rather than explicitly routed.

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 transparency burden. It goes beyond a basic summary by specifying the output fields, the ±0.1 label threshold, an identical REST endpoint, and a per-day credit cost including the no-coverage case. It does not address auth or error behavior, but it gives substantial behavioral detail.

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 compact and well front-loaded: purpose first, then output semantics, then cost. Every sentence adds information; there is no repetition of schema titles or boilerplate.

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 two-parameter read-style tool with an output schema, the description explains inputs, output shape, threshold behavior, and cost edge case. There is no missing information an agent would need to decide whether and how to invoke it.

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 0% description coverage, so the description must define both parameters. The first sentence maps ticker to the instrument and days to the trailing window, and the default is visible in the schema. This is sufficient for the two simple parameters, though it leaves numeric constraints like max days unstated.

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: returning daily aggregated sentiment for a ticker over a window. This clearly differentiates it from sibling tools like get_prices and get_sentiment by emphasizing the daily aggregation level.

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 when to use the tool—when daily aggregated sentiment is needed—and the cost rule adds practical context. However, it does not explicitly name sibling get_sentiment or state when to choose raw vs aggregated sentiment, leaving the alternative-selection logic to the agent.

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, and it delivers: 'Free — doesn't hit the billing meter' is a key behavioral disclosure, and 'Mirrors GET /v1/usage (MCP_MIRRORS_V1: change both together)' adds implementation-level transparency. The read-only, cost-free nature is explicitly conveyed.

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 compact, front-loads the core purpose, and every segment earns its place: what it returns, that it's free, the API mirror, and a concrete use case. The MCP_MIRRORS_V1 note is slightly maintainer-oriented but still useful information.

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 zero-parameter, read-only introspection tool with an output schema, the description covers everything an agent needs: what it does, when to call it, cost implications, and behavior. No critical context is missing.

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 tool has zero parameters, so there is no parameter semantics burden on the description. The schema coverage is trivially 100%, and the description adds relevant context about what the API key introspection covers. Baseline 4 is appropriate for a zero-parameter tool.

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 uses a specific verb ('Introspect') and names the exact resource ('your API key') plus the specific data returned: calls used, allowance, remaining credits, and reset time. This clearly distinguishes get_usage from data-analysis siblings like get_sentiment/get_summary.

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 recommends using the tool 'before a large batch of get_sentiment/get_summary calls to check you have credit headroom.' This gives a concrete, actionable usage context. It doesn't state exclusions, but there are no plausible alternative tools to route around among the listed siblings.

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 provided, the description carries the full burden, and it delivers: discloses cost behavior ('doesn't hit the billing meter'), return grouping semantics (primary vs background), and coverage quality ('full sentiment coverage' vs 'thinner but real'). No hidden side effects or surprises remain.

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 compact and front-loaded: purpose first, then cost, then output structure, then usage guidance. Every sentence adds unique value without repetition or filler. It is appropriately sized for a simple list tool.

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 zero-parameter list tool with an output schema, the description covers everything needed to call it correctly and use its output meaningfully. It even clarifies subtle domain distinctions (primary vs background coverage) that would otherwise be opaque. Nothing important is missing.

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 tool has zero parameters, so schema coverage is trivially complete. The description goes beyond schema by explaining how its output will be used as a ticker argument elsewhere. Baseline 4 is appropriate for a no-parameter tool that still clarifies the output's role in the API.

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: 'List every asset SentimentFX tracks.' The description clearly distinguishes this tool from the sibling get_* tools by scope and function. It also adds useful structure about the two ticker groups, making the purpose unmistakable.

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 explicit usage context: use the exact ticker strings from this tool's output as the ticker argument to other tools. This tells the agent when to invoke list_tickers (before calling data tools that need a ticker). It doesn't explicitly name sibling alternates, but the guidance is clear enough for a zero-parameter enumeration tool.

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