Invexia Stock Research

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

With no annotations provided, the description carries the full behavioral burden; it does disclose the data freshness cadence ('Data refreshes daily') and the full field set, which is real beyond-schema value. However, it says nothing about invalid or non-US tickers, rate limits, or authentication requirements, which are notable gaps for a tool with zero annotation coverage.

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 sentences, front-loaded with purpose and scope, then freshness and a pointer to the richer alternative. Every clause adds information; there is no 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?

With no output schema and no annotations, the description must carry both the return-shape and behavioral load; it does enumerate the returned fields and the refresh cadence, and points to the valuation page for deeper data. Only edge-case behavior (invalid/non-US ticker handling, errors) is left unstated.

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 single parameter is documented with an example (AAPL), so baseline would be 3. The description adds a genuine constraint not present in the schema – the ticker must be for a US-listed stock – which meaningfully narrows input expectations.

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 (Get a snapshot) plus the exact resource and scope (a US-listed stock by ticker symbol), and enumerates the returned fields. This clearly separates it from the screener/ranking siblings like run_screener, get_trending_stocks, and get_valuation_scorecard.

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 phrase 'by ticker symbol' – a single-entity lookup versus the list-oriented siblings – but there is no explicit when-to-use/when-not statement. The only routing hint points to an external URL rather than to a sibling tool, so the agent must infer the boundary itself.

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 does disclose real behavioral traits beyond the schema: daily refresh cadence, that each entry includes a short analysis, and a citation requirement. It omits auth/access expectations and return-volume behavior, so it is helpful but not complete.

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 plus a citation instruction; the resource and its criteria are front-loaded with zero filler. Every sentence — including the attribution URL — carries actionable content.

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, single-parameter list tool with no output schema, the description covers what the result is (trending names) and its shape (each with a short analysis). Return value details are lightly sketched rather than fully specified, keeping it just under complete.

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% with a single well-documented `limit` parameter, and the description adds no syntax, range, or default nuance beyond it. Baseline 3 is correct when the schema does the parameter work.

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?

Names a specific verb and resource ("Get ... trending stocks list") and defines the selection criteria — recent momentum, news flow, screening interest — which distinguishes it from siblings like get_undervalued_stocks and run_screener. It stops short of explicitly naming or contrasting an alternative, so a 4 rather than a 5.

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?

"Refreshed daily" gives useful timing context for deciding when this data is appropriate, but there is no explicit when-to-use / when-not-to-use statement and no named alternative. Usage is only implied from the criteria described.

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 are provided, so the description carries the full burden. It does add useful behavioral context — daily refresh cadence, that results include short analysis and key ratios, and that outputs are screened ideas rather than advice — but omits auth/rate-limit behavior, pagination, and whether the list is a snapshot or cached.

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, followed by the disclaimer and citation. The citation sentence is somewhat administrative but does serve a usage purpose; overall it is tight and waste-free.

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 and no annotations, the description does enough for a simple single-parameter list tool: it says what each result contains (short analysis, key ratios) and how fresh it is. Minor gaps around result volume beyond the limit parameter and response format are acceptable here.

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 single 'limit' parameter already documents its 1-25 range and default of 10. The description adds no further semantics about the parameter, so the 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 clear verb+resource: returns screened undervalued stock ideas with fundamentals, analysis, and key ratios. It is distinct from siblings like get_trending_stocks or get_valuation_scorecard, but it never names or contrasts them explicitly, leaving the agent to infer the boundary.

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?

Implies the use case ('screened undervalued stock ideas', 'data-backed screen, not individualized advice') but gives no when-to-use vs when-not guidance relative to run_screener, list_screeners, or the other get_* tools. The 'not individualized advice' note hints at a constraint without operationalizing it.

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 disclose real behavioral traits: data is 'Refreshed daily', scope is limited to US-listed stocks, and output must be cited with a specific URL pattern. It stops short of auth/permission requirements or what happens for a non-US or invalid ticker, but the freshness, scope and compliance context is substantive.

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: what it returns front-loaded, then when it is useful, then freshness and citation. No repetition of the title or name, and every clause carries load-bearing information for invocation.

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 single-parameter read tool with no output schema, the description fully covers what comes back (composite plus component scores), the freshness guarantee, the US-listing constraint, and the required citation. Nothing an agent needs to call and correctly present 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?

Single parameter at 100% schema description coverage, so the schema already documents 'ticker' with an example. The description reinforces the US-listed scope implicitly and shows the {TICKER} URL substitution pattern, but adds little format or validation meaning beyond the schema — the baseline 3 for high coverage is appropriate.

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 ('Get Invexia.ai's investment scorecard for a US-listed stock') and then enumerates the exact payload: the composite Titan Score plus component scores for valuation, growth, profitability, financial health and momentum. This is clearly distinguishable from siblings like get_stock_snapshot or run_screener without opening any 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?

Gives concrete usage context — 'is TICKER overvalued/undervalued' style questions — plus a presentation constraint ('data-backed screen, not individualized advice'). However, it never names or excludes the obvious sibling alternatives (get_undervalued_stocks, get_stock_snapshot), so the agent must infer when this beats those.

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 reasonably well: it discloses the exact return fields (id, name, description, category) and implies a safe read-only listing. It does not mention pagination or rate limits, but for a static no-param catalog that is a minor gap.

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 compact sentences, front-loaded with purpose and ending with the handoff to run_screener. The web URL is a small extra but adds user-facing value rather than noise.

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, but the description enumerates the returned fields and the downstream usage pattern, so an agent knows both what it gets back and how to use it. Nothing needed to call or consume 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to compensate for. No parameter-related omissions exist.

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+resource ('List Invexia.ai's predefined stock screeners') and concretely enumerates the categories covered (value, growth, dividend, momentum, guru-style). This is clearly distinguishable from siblings like run_screener or get_undervalued_stocks.

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?

Explicitly routes the agent to the follow-up tool: 'Use a returned id with run_screener,' which disambiguates this discovery tool from the execution tool. It lacks explicit when-not guidance, but the discovery/execution split is 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 are provided, so the description carries the full burden. It does disclose two useful behavioral traits: results are capped at the requested limit and the dataset refreshes daily, plus a citation requirement. It says nothing about authentication, rate limits, or error behavior for an invalid screenerId, which is a gap for a zero-annotation tool.

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 short sentences, front-loaded with what the tool does and the return contents, then the id dependency, then the freshness/citation details. No 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?

With no output schema, the description usefully enumerates the returned fundamentals (price, market cap, P/E, dividend yield, ROE) and states freshness, which is enough to call and interpret the tool. Auth and failure behavior remain unspecified but are minor for a read-only lookup.

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 parameters (screenerId, limit) are already documented with ranges and defaults. The description only reiterates that ids come from list_screeners and adds example values, matching the baseline for a 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 (run) and resource (predefined stock screeners) plus the shape of the return (top matching US stocks with fundamentals). It also names the sibling that supplies valid input, so the agent can tell it apart from get_undervalued_stocks and get_valuation_scorecard 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?

Explicitly routes the agent to list_screeners for valid ids and gives three concrete example ids, which is real when-to-use guidance. There is no explicit when-not condition, but the dependency chain (list first, then run) is unambiguous.

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