Quantral Stock Sentiment

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower. The description still adds real value beyond them: ordering (newest first), pagination mechanics ('nextCursor for older months, null when there are none'), and a scope disclaimer that recaps describe conversation, not stock predictions.

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?

Three tight sentences: payload and ordering first, pagination second, scope disclaimer last. No redundancy with the title, and every sentence carries distinct 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?

There is no output schema, so the description carries the burden of describing returns, and it does: per-month summary, score, tier, post count, plus the pagination token. Nothing an agent needs to call or interpret this tool 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?

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining that the cursor token returns 'older months' and by tying the returned nextCursor to the cursor input, which clarifies the pagination contract the schema only describes in isolation.

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 ('Returns month-by-month recaps of the tracked conversation around one company') and enumerates the payload (summary, score, tier, post count). The resource is clearly distinct from siblings like get_company_score and get_company_signals, so an agent can route without opening the schema.

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?

Usage is implied by the content ('month-by-month recaps... newest first') rather than stated. It never says when to prefer this over get_company_score or get_company_signals, nor any exclusions, so the agent must infer the choice from the payload description.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description focuses on semantics and adds genuinely useful context: the exact tier vocabulary, the fact that the score is conversation strength and not a price prediction, and that a null score means no tracked mentions rather than a low score. That null-vs-low distinction is a real behavioral trait an agent could otherwise misread.

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?

Three sentences, no filler, and the return payload is front-loaded before the disclaimers. The final null-vs-low sentence is longer than the others but carries non-obvious meaning, so it earns its place.

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?

With no output schema, the description must carry the return contract, and it does: both time windows, tier words, explanation and price fields, plus the null case. Nothing an agent needs to call and interpret this single-parameter read tool 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?

There is only one parameter, ticker, and the schema documents it at 100% coverage with an example ('AAPL'). The description adds nothing about the parameter, so the baseline of 3 applies.

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 ('Returns one company's Quantral social-conversation signal score') and enumerates the payload: 24h and 7d windows, tier words, latest explanation and price. It does not explicitly distinguish itself from the nearby siblings get_company_signals or get_company_recaps, so an agent must infer the split from the word 'score'.

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?

Usage is implied rather than stated: the tool clearly suits 'how strong is conversation around company X right now', and the disclaimer clarifies what the score is not (a price prediction or recommendation). There is no explicit when-to-use/when-not guidance and no named alternative among the 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?

Annotations already cover readOnly/idempotent/non-destructive, yet the description adds substantial context beyond them: a 50-item cap, newest-first ordering, how Reddit threads nest replies with commentCount, what threadOnly means, that telegram broker notes do not feed the score, and that excerpts are opinions not advice. These are real behavioral traits an agent could not get from the structured fields.

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?

Dense but front-loaded: the core return shape comes first, then edge-case semantics (threadOnly, telegram) follow. Most sentences carry information, though the broker-note caveat is a minor tangent relative to the primary purpose.

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?

With no output schema, the description carries the burden of describing the return payload, and it does so thoroughly: fields per mention (sentiment, excerpt, source, author track record), ordering, thread structure, and the threadOnly edge case. An agent has everything needed to interpret results 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 coverage is 100% and both parameters are already documented in the schema, so baseline is 3. The description's note that month 'scopes results to one calendar month' largely restates the schema's own YYYY-MM description rather than adding new syntax or format detail.

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 ('returns the individual posts and filings behind a company's score') and implicitly differentiates from the get_company_score sibling by positioning itself as the underlying detail rather than the score. It does not explicitly name any sibling, so an agent must infer the routing from the phrase 'behind a company's score'.

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 usage ('behind a company's score') and explains the month scoping, but never states when to pick this over get_top_signals, get_company_recaps or get_company_score. No explicit alternatives or exclusions are given, leaving routing to 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?

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds substantial context beyond that: two-hour refresh cadence, the exact fields each story carries, the ordering rules for both branches, and the semantic caveat that stories are not news or investment advice.

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?

Front-loaded with what the tool returns, then parameter behavior, then a caveat. The enumeration of story fields is dense but earns its place since there is no output schema. A slightly tighter phrasing of the kind definitions could trim a few words without losing meaning.

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?

With no output schema, the description compensates well by listing the returned fields, the kind taxonomy, and the ordering semantics. It is complete enough to invoke correctly; only the relationship to the singular get_story sibling is left unaddressed.

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 is 3, but the description goes further by defining the week boundary (Monday to Sunday), stating that any date within the week is acceptable, and specifying the sort order for each case. That meaning is not present in the schema's one-line parameter note.

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 ('Returns the stories Quantral wrote about what people are posting') and defines what a story is, including its composition and refresh cadence. It does not explicitly distinguish itself from the sibling get_story (singular), leaving the batch-vs-single relationship to be inferred from the plural name.

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 clearly explains how the optional 'week' parameter selects a result set, which is effectively usage guidance for the one input. However, it never says when to reach for this tool versus get_story or get_company_recaps, and gives no exclusions or prerequisites.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description nonetheless adds real behavioral detail beyond them: newest-first ordering, a 20-item page size, and the null-when-exhausted semantics of nextCursor. It does not mention auth or rate limits, keeping it short of a 5.

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?

Purpose and payload are front-loaded in the first clause, then pagination, then the disclaimer. The opening sentence is long and densely packed with clauses, but each clause carries information an agent needs; the closing disclaimer sentence is arguably optional but short.

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?

With no output schema, the description carries the full burden of describing the return value and does so: posts with sentiment, excerpt, source, author track record, ordering, page size, and nextCursor semantics. Nothing needed to call it correctly 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?

Schema coverage is 100%, so both 'id' and 'cursor' are already documented in the schema with the same meaning. The description reinforces that cursor retrieves older posts and that nextCursor is its source, but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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 ('Returns one story by its id') plus the payload it carries ('the posts and filings behind it'). The singular 'one story by its id' cleanly distinguishes it from the sibling get_stories list tool without the agent needing to open either schema.

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 phrase 'by its id' implies this is the lookup path once you already have a story id, and the cursor sentence implies the follow-up call for older posts. However, it never explicitly contrasts with get_stories or states when not to use it, so the routing is left to 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?

Annotations already establish readOnly/idempotent/non-destructive, but the description adds real interpretive context: strategies are rule-built model portfolios, not advice, live and backtest records are reported separately, and returns exclude trading costs. Those caveats materially affect how an agent should present the data and are not derivable from 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?

Front-loaded with the return-value enumeration in the first sentence, followed by two short caveat sentences that each carry distinct information (what the product is, how live/backtest are split, cost basis). No filler or 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?

With no output schema, the description carries the burden of describing return content, and it does so thoroughly (summary, caveats, basis, holdings with join dates and moves, dropped names, next update date, key stats). Only minor gaps remain, such as behavior for an unknown or expired slug.

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% and the single 'slug' parameter already carries examples (insider-buying, finx-stars, capitol, deep-dives), so the schema does the work. The description adds nothing about slug format or lookup behavior, which is the expected baseline-3 outcome for a one-parameter, fully documented 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 verb and resource ('Returns one Quantral strategy in detail') and enumerates exactly what the payload contains, so the agent knows this is the single-strategy detail fetch. It does not explicitly distinguish itself from the sibling get_strategy_changes, even though its 'names dropped in the latest update' / 'which are new this update' content clearly overlaps with that tool.

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?

Usage is only implied: the tool needs a slug and returns detail for one strategy, which suggests it follows list_strategies. There is no explicit when-to-use, no when-not-to-use, and no pointer to get_strategy_changes for the change-only case, which is the nearest alternative.

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?

Beyond the readOnly/idempotent annotations, it discloses real behavioral nuance: net-difference semantics mean a name added then dropped again does not appear, added names carry performance since joining, dropped names show results while in the list and are 'pending until their last week is scored'. It also clarifies strategies are rule-built model portfolios, not recommendations, and these are list changes, not trades.

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?

Dense but front-loaded — the core purpose and both parameter modes come first, followed by return-value and domain caveats. Every sentence carries information, though the closing disclaimer sentence is slightly longer than strictly needed.

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?

With no output schema, the description carries the burden of describing returns, and it does so: what added and dropped entries carry, plus the pending-scoring caveat. Only the concrete response shape/format is left unspecified, which is a minor gap for a read tool.

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 is 3, but the description adds genuine semantic depth beyond the schema: without 'since' it compares against the list before the latest update, with 'since' it returns a net difference that skips add-and-drop round trips. That meaning is not derivable from the parameter definitions alone.

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: returns which stocks were added to and dropped from a strategy's list. It clearly distinguishes the returned data (list changes) from siblings like get_strategy (the list itself) and get_company_recaps, so an agent can differentiate 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?

The description explains the two invocation modes (with vs without 'since') clearly, which helps the agent pick the right call form. However, it never states when to use this tool versus siblings such as get_strategy for the current list — that routing judgement is left to 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the hit rates are backward-looking and explicitly 'not a forecast', the 50-graded-position threshold governs ranking eligibility, and the default/ceiling return size is stated.

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?

Front-loaded with the core action and each subsequent sentence carries distinct information (entry fields, thresholds, disclaimer, size). It is dense but every clause earns its place; slightly long, with the tier and field enumeration bordering on output-shape detail.

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?

With no output schema, the description compensates by enumerating the returned fields (handle, platform, tier, graded positions, verified hit rate, recent activity, link) and by stating the ranking caveat and list semantics. Nothing an agent needs to call and interpret this read-only list tool 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?

Schema description coverage is 100%, so sort, limit and section are already fully documented in the schema, including the 'spy' explanation the description never mentions. The description restates the 10-default/50-cap and adds the 50-position threshold for the trusted section, but does not enrich the parameters beyond the schema, so baseline 3 applies.

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: it 'ranks the voices with the best verified track record' and enumerates exactly what a voice is (individual authors across X, Reddit, Substack, YouTube, plus crowd sources like a subreddit). This is clearly distinct from the company/strategy/signal siblings, so an agent can route to it without opening a schema.

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 explains the two list concepts (trusted requires 50 graded positions; earning holds voices still building a record), which implicitly tells the agent when each section applies. However, it never states when to reach for this tool versus its siblings, nor any explicit exclusions, so usage is inferred rather than directed.

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?

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the bar is low, yet the description still adds real context: what the score measures, its 0-100 scale, its tier vocabulary, and an explicit disclaimer that it is not a price prediction or investment recommendation. It omits freshness/staleness of the conversation window and any rate-limit behavior, so 4 rather than 5.

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?

Front-loaded with the ranking rule, then entry contents, then the disclaimer and the limit, in a logical order with no filler sentences. The closing limit sentence largely duplicates the schema default/max, a minor redundancy.

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?

With no output schema, the description usefully enumerates what each entry contains (score, tier word, explanation, latest price, link), which is exactly the missing structured information. It leaves edge cases such as empty results or tie-breaking unstated, keeping it just under 5.

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 restates the default (5) and maximum (50) and the two window values rather than adding syntax or semantics the schema lacks, so it does not earn above baseline.

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 ('Ranks the companies... by Quantral's social-conversation signal score') with the window, ordering, and score range all named. It clearly contrasts with the company-scoped siblings (get_company_signals, get_company_score) by implication, but never names an alternative, so it stops short of the 5 bar.

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?

Usage is only implied: a ranked list implies discovery/screening, and the sibling set implies per-company lookups exist elsewhere. There is no explicit when-to-use, when-not-to-use, or named alternative, which is the gap between 3 and 5.

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?

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the description's job is to add domain context. It does: live and backtest records are reported as separate records, and returns are before trading costs — both are meaningful behavioral facts an agent cannot infer from 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?

Front-loaded with the verb and resource, then a dense enumeration of returned fields followed by two clarifying sentences. The field list is a long run-on clause that could be broken up, but every clause carries information and nothing is redundant.

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?

With no output schema, the description compensates by enumerating the returned fields and separating live from backtest records, which is the key semantic an agent needs. A brief note on ordering, pagination, or whether the list is exhaustive would close the remaining gap.

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 takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description instead spends its words on the shape of the result, which 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?

States a specific verb (lists) and resource (strategies/model portfolios) and enumerates exactly what each entry contains: slug, update cadence, holdings, live vs backtest records, latest list date, next update. It is clearly distinguishable from the singular sibling get_strategy by being a collection-level listing, though it never explicitly names that sibling.

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?

There is no statement of when to call this versus get_strategy or get_strategy_changes, nor any prerequisite or exclusion. The disclaimer that strategies are 'not recommendations or investment advice' is a legal caveat, not usage guidance for an agent selecting a tool.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely useful behavior beyond them: a hard cap of 10 results, the returned fields, that empty means uncovered, and that results carry no scores.

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?

Two tight sentences, front-loaded with the match semantics and result cap; the trailing clause about empty results and absent scores is high-value and earns its place.

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?

No output schema exists, and the description compensates by enumerating the returned fields (primary ticker, name, country, description, link) and the 10-item cap. Nothing needed to call this single-parameter tool correctly 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?

Schema coverage is 100% and the description's 'name or ticker prefix' restates the schema's own parameter description almost verbatim, adding no new syntax, length, or matching-rule detail. Baseline 3 is appropriate for a single fully-documented 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?

States a specific verb (matches) and resource (companies Quantral covers), plus the matching key (name or ticker prefix) and the result shape. An agent can distinguish this from siblings like get_company_score or get_company_signals, which operate on an already-resolved company.

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?

Usage is implied rather than stated: the empty-result note ('the company is not covered') tells the agent how to interpret a miss, but there is no explicit when-to-use guidance or routing to siblings such as using this to resolve a ticker before calling get_company_score.

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