Market Eyes Live - stock ratings and mortgage-rate context

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

Beyond the readOnlyHint and idempotentHint annotations, the description adds meaningful context: it draws on a daily-refreshed dataset and notes the limitation that out-of-set tickers require a different tool. This gives the agent a solid sense of data freshness and scope.

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 well-structured sentences, front-loaded with the core purpose, followed by usage examples, limitation, and source attribution. Every sentence earns its place with no 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?

Given the single parameter, high schema coverage, and the presence of an output schema, the description covers the necessary ground: usage, limitations, and alternative. It is complete for a straightforward comparison 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 already documents the symbols array with min/max and an example. The description adds valuable semantics: 'U.S. stocks or ETFs' and 'side by side' clarify asset types and the comparative nature of the query, exceeding the schema's basic parameter info.

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 compares 2-5 U.S. stocks/ETFs on specific MELANY rating dimensions. It distinguishes itself from the sibling get_stock_rating by focusing on side-by-side comparison rather than single-ticker scoring.

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 examples ('NVDA vs AMD') and directs users to call get_stock_rating for tickers outside the rated set. This clear when-to-use and when-not-to-use guidance eliminates ambiguity.

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 readOnlyHint, idempotentHint, destructiveHint, so the safety profile is clear. The description adds behavioral context beyond these: the data origin (marketeyeslive.com), the specific metrics included, and the distinction between free public data and the app's personalized signal. This adds value without contradicting 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?

Three sentences, each earning its place: the first states the core function and components, the second gives concrete usage examples, and the third clarifies data availability and scope. No redundancy or fluff.

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-param tool with rich annotations and an output schema, the description is fully sufficient. It covers the source, the data points, use-case framing, and the limitation (free public data, no personal signal). Nothing essential 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 100% and baseline is 4. The description compensates by explaining what data the tool retrieves, which is all that is needed. No param semantics are required.

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: 'Get today's public U.S. mortgage-rate context' and enumerates specific outputs (10-year Treasury yield, MBS momentum, rate environment). It distinguishes itself from siblings (compare_stocks, get_stock_rating) by focusing on mortgage rates rather than stocks, with a specific source (Market Eyes Live's Lock Radar).

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 example questions ('should I lock my mortgage rate today', 'are mortgage rates going up') that clarify when to use the tool. It also notes the limitation 'Free public data; a personalized lock-or-float signal is in the app,' implicitly guiding users away from expecting personalized advice. Does not explicitly name alternative tools for exclusion, but the siblings are clearly stock-focused.

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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds substantial behavioral context beyond these: it explains the rating components, the daily-refreshed core set vs. live on-demand scoring, hourly limits, and the 19-year backtest, all of which help the agent set expectations.

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 a single paragraph but front-loaded with the core purpose and examples, then provides relevant detail on coverage, outputs, and data provenance. It is somewhat dense but every sentence contributes useful information; 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?

Given there is an output schema, the description still provides a thorough overview of return contents (conviction tier, composite score, eight factor scores, risks, theme, as-of date), usage, coverage limits, and data quality context. The tool's complexity is fully addressed for an agent to select and invoke 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?

The input schema fully covers the symbol parameter with examples, so the baseline is 3. The description adds extra semantic value by specifying 'U.S.-listed stock or ETF', covering more than 11,000 tickers, and noting that non-core tickers are scored live on demand, which clarifies what values are acceptable and how they are treated.

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 gets a current data-driven rating for a single U.S. stock or ETF, using the specific verb 'Get' and naming the resource (MELANY's rating). It distinguishes itself from siblings like compare_stocks by explicitly saying 'one U.S. stock or ETF' and listing real example queries.

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 provides explicit usage examples ('is NVDA a buy', 'what is the rating on AAPL') and explains coverage limits with the core vs. on-demand distinction. However, it does not explicitly mention when not to use this tool or name alternatives, though the 'one stock or ETF' phrasing implies it is not for comparisons.

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