north7-market-intelligence

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

No annotations are present, so the description carries the full burden. It discloses the aggregation behavior (combines multiple endpoints), the detailed output fields, and the access requirement (FREE — no API key needed). It doesn't mention data freshness, latency, or explicit read-only-ness, but for a zero-parameter read aggregator this is strong 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?

The description is front-loaded with purpose and a strong recommendation, and the combined-endpoint note is efficient. The return enumeration is long but each item is specific and valuable given the lack of an output schema.

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 is the sole source of runtime expectations. It fully enumerates the return payload, explains how this tool relates to others, and notes the auth requirement. An agent has everything needed to invoke and interpret the response.

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 accepts zero parameters, so there are no parameter semantics for the description to clarify. The baseline of 4 for no-parameter tools applies, and the description appropriately focuses on output rather than inputs.

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 clear resource (full market awareness), and explicitly differentiates itself as a composite of /risk + /regime + /events, which distinguishes it from sibling tools like get_risk_index or get_events. The return list further clarifies exactly what the tool provides.

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 recommends this as the FIRST tool for any trading agent and explains that it combines three endpoint categories, implying that individual sibling tools are for single-component needs. However, it does not explicitly state when NOT to use this tool (e.g., if only risk index is needed).

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?

Without annotations, the description carries the full behavioral burden. It discloses a read-only intent via 'Get' and 'Returns,' describes the exact output fields, and explicitly states the cost of 2 credits per call. It does not discuss data freshness or update cadence, but no side effects or destructive actions are implied.

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 four sentences with no filler; the first sentence states the core action, followed by scope, output, and cost. The commodity list is long but necessary for disambiguation, and the credit cost is appropriately front-loaded in the final sentence.

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 no-parameter tool with no output schema, the description fully covers what the agent needs: what it does, which commodities it covers, what fields each result contains, and the per-call cost. Nothing required to invoke 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?

The tool has zero parameters and 100% schema coverage by default, so the baseline is 4. The description adds value by enumerating the commodity scope and the precise response fields, which is more than the empty schema provides.

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-resource pair: 'Get AI-scored trading signals for 15 raw material commodities' and enumerates all 15 commodities, leaving no ambiguity about scope. It is clearly distinct from generic siblings like get_trading_signals by explicitly limiting to raw material commodities.

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 clear invocation context: 'Use this tool for commodity-specific intelligence' and notes it is 'particularly useful for supply chain risk assessment and commodity trading decisions.' It stops short of naming alternative tools or saying when not to use it, so no formal exclusions are given.

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 of behavioral disclosure. It mentions that events are sorted by impact score descending, that the tool is free with no API key, and that it returns structured data. While it doesn't cover rate limits or data freshness, the disclosed behaviors are relevant and helpful for an agent.

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 concise—two sentences plus an example—with the core purpose front-loaded. Every sentence contributes value: what it returns, how to use it, sorting behavior, cost/auth status, and a concrete example. 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 the tool's simplicity (two optional parameters, no output schema, no annotations), the description is complete. It covers the data returned, sorting order, filtering logic, and authentication requirements. An agent has all the information needed to call it correctly and interpret results.

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. The description adds meaning beyond the schema by clarifying that min_impact defaults to 0 (all events), recommending 7+ for high-impact only, and explaining the region filter implicitly through the list of regions in the schema. The example ties both parameters together, adding practical value.

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 purpose: 'Get structured geopolitical and market events with impact scores' and enumerates the fields returned (headline, impact_score, affected sectors, etc.). It distinguishes itself from sibling tools like get_impact or get_risk_index by focusing on events with impact scores, and the example further clarifies its behavior.

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 guidance: 'Use this to detect market-moving events and filter by minimum impact or region.' It also gives an example (min_impact=7) that illustrates how to apply filters. However, it does not explicitly state when not to use this tool or mention alternative tools for different scenarios, so it loses a point.

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 discloses the return fields (directional bias, confidence, driver explanation, timeframe), mentions it combines multiple sources, and notes it is free with no API key required. However, it does not explicitly state read-only behavior or any side effects, though that is implied by 'mapping' and 'returns.' The disclosure is adequate but not exhaustive.

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 efficient and front-loaded, starting with the primary purpose and then detailing return fields, filtering, and the free note. It is slightly longer than necessary but every sentence contributes useful information, and there is no fluff 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?

For a simple tool with one optional parameter and no output schema, the description is complete: it fully specifies what is returned (assets affected, bias, confidence, driver, timeframe), how to filter, and the fact that it aggregates multiple signals. An agent has enough to decide whether to call it and interpret the result, without requiring additional documentation.

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 the 'asset' parameter already documented with examples and omission behavior. The description adds 'Filter by specific asset to see all factors affecting it,' which is largely redundant with the schema. As coverage is high, a baseline of 3 is appropriate; the description does not add significant meaning beyond 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?

The description clearly states the specific verb 'map' and resource 'geopolitical events and crises to specific asset impacts,' and distinguishes itself from sibling tools like get_events and get_trading_signals by emphasizing asset-level impact with directional bias, confidence, and timeframe. The mention of combining multiple signals (crisis analysis, news, alpha, commodity) further differentiates its scope.

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 clear context for when to use the tool: to map events to asset impacts, and mentions the optional filter to focus on a specific asset. However, it does not explicitly exclude alternatives or name sibling tools, missing an opportunity to specify when not to use it (e.g., if the user only needs raw news events, get_events might be more appropriate).

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 of behavioral disclosure. It discloses the return payload (headline events with impact scores, affected sectors/assets, risk assessment, actionable implications), generation cadence (daily via Claude AI on 40+ sources), language options, and cost (10 credits per call). This is comprehensive transparency for a read-only briefing 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 sentences pack substantial information with minimal redundancy. Each sentence serves a distinct function: purpose, content/returns, and logistics. 'Daily' appears twice but is not problematic. Well-structured with the core purpose front-loaded. Not maximally concise due to the long list in the second sentence, but earned.

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 no output schema, the description compensates well by listing the main return elements and adding cost, generation frequency, and source count. For a single-parameter tool with straightforward invocation, the description is complete enough for an agent to call it correctly and interpret the result. Minor missing details like pagination or response format aren't critical 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?

The only parameter 'lang' is fully described in the schema (enum en/de, default 'en', description). The description mentions availability in English and German, which adds no semantic value beyond what the schema already provides. With 100% schema coverage, baseline 3 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?

Description clearly identifies the tool as retrieving a daily AI-generated geopolitical briefing and lists the macro-level event types it covers (geopolitical, central bank, trade, sanctions, conflicts, economic data). It distinguishes from siblings like get_events or get_impact by focusing on geopolitical intelligence, though it does not explicitly name alternatives. Clear verb + resource, but sibling differentiation is implicit.

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 states when to use: 'Use this tool to understand macro-level events that could impact markets' and describes the content and return format. It provides clear context for use but does not give when-not-to-use guidance or explicitly name alternative tools. This meets the 'clear context, no exclusions' level.

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 of behavioral disclosure. It fully discloses the output format (regimes, confidence, price vs MA, VIX level, duration), the update frequency (every 30 minutes), and the cost (FREE, no API key). No side effects or destructive actions are relevant, and it explicitly notes the update cadence, which is a key behavioral trait.

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 average but each sentence serves a purpose: purpose, usage, output details, update frequency, and cost. It is front-loaded with the core purpose and structured logically. While it could be tightened, the detail is valuable for a tool that returns complex regime 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 no-parameter tool, the description is fully self-contained. It explains what it does, when to use it, what it returns (including specific regime definitions), how often it updates, and any access requirements. There is no output schema, so the description must cover return values, and it does so thoroughly.

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 the schema is empty. The description doesn't need to explain parameters, and the baseline of 4 is appropriate. It does not add any parameter-related semantics, but none are needed.

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 purpose: 'Detect the current market regime to inform trading strategy.' It specifies the resource (market regime) and the action (detect), and explicitly lists the four possible output regimes (BULL, BEAR, SIDEWAYS, CRISIS) with their definitions, distinguishing it from sibling tools that handle different market data.

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 usage direction: 'Use this tool alongside get_risk_index before making trading decisions.' It also mentions that it's free and requires no API key, which is relevant context. It doesn't explicitly state when not to use it, but the guidance is clear and practical.

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 discloses the 10-credit cost, explicitly states it is a research portfolio and not investment advice, and describes the returned data. This is solid transparency for a read-only view tool, though it could mention whether any auth or rate limits apply.

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 front-loaded with the main purpose, followed by concrete return details and the credit cost. Every sentence adds value; there is no filler or redundant restating of the tool name.

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 parameters and no output schema, the description fully equips an agent to call the tool correctly and interpret results: it lists active position fields, portfolio return, performance history, and the credit cost. The information provided is complete for a simple getter 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?

There are zero parameters, so the schema already provides full coverage. The description adds relevant context about what the portfolio represents and what metrics are returned, which is useful given the absence of an output 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 ('View') and specific resource ('current NORTH7 model portfolio positions and performance metrics'). Clearly distinguishes itself from sibling signal/analysis tools by focusing on the model portfolio rather than market signals or agent context.

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 says when to use it: to see current positions, entry prices, P&L, and portfolio performance. It does not name alternatives or state when not to use it, but the purpose is clear enough that an agent can infer appropriate use versus the listed sibling tools.

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 does so well. It discloses the data source (Yahoo Finance), update frequency (every 2 minutes during market hours), the credit cost (1 credit per call), and the exact return fields (symbol, price, change, changePercent, volume, timestamp).

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 purposeful sentences front-load the core purpose and usage condition, then cover return fields, data source, refresh cadence, and cost. No filler or redundancy; every sentence 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?

For a simple read-only tool with one optional parameter and no output schema, this description is complete. It tells the agent what data is returned, how to filter, how fresh the data is, and what the call costs, leaving no critical gap for correct invocation.

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?

Although schema coverage is 100%, the description adds value beyond the schema by providing a concrete example ('AAPL,MSFT,TSLA,GC=F,EURUSD=X') and clarifying that standard Yahoo Finance ticker format should be used. This helps an agent construct valid symbol lists.

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: 'Fetch real-time price data for 80+ assets across stocks, ETFs, commodities, and forex.' It clearly differentiates from siblings like get_trading_signals and get_commodity_signals by emphasizing raw price data rather than analytical signals or recommendations.

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 states when to use it: 'Use this tool when you need current market prices, daily price changes, or percentage moves.' It also explains how to limit results via symbols, but it does not explicitly name alternative tools or provide when-not-to-use guidance.

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 return shape ('matched entities, connected nodes, and weighted edges with evidence') and the authentication requirement ('FREE — no API key needed'). It does not specify behavior when no parameters are provided, but otherwise is transparent.

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 earning its place: what the tool queries, entity types, examples, and return format. 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?

For a two-parameter tool with no output schema, the description explains what is returned and how to query. It could be more complete by clarifying what happens when no entity or type is supplied, but overall an agent has enough 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 coverage is 100%, so the baseline is 3. The description adds meaningful value by giving concrete entity ID formats and examples for both parameters, which helps an agent populate them correctly.

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 a specific verb ('Query'), a resource ('the NORTH7 knowledge graph of entities and relationships'), and lists supported entity types. This makes it easy to distinguish from sibling market-data tools like get_prices or get_events.

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 concrete instructions and examples for using the entity parameter ('IR', 'CL=F', 'energy'), and implies this tool is for relationship-oriented queries. It does not explicitly name alternatives or state when not to use it, so it stops short of a 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the update frequency (every 30 minutes), data sources (GDELT, VIX, credit spreads, macro indicators), access requirements (no API key required), and the exact return shape including status categories and regional risk 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?

The description is compact yet information-dense, front-loading the core purpose and usage instruction before layering in score interpretation, return fields, data sources, and refresh cadence. Every sentence contributes actionable information without 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?

For a zero-parameter tool with no output schema, the description fully covers how to interpret results, what the returned fields are, how current the data is, and what access is required. An agent can call the tool and understand its output without any additional context.

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 and an empty input schema, so there is nothing to document. The baseline of 4 for zero parameters applies, and the description does not need to add parameter-level 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?

The description uses a specific verb ('Get') and a clearly defined resource ('global market risk index scored 0-100'), and it explains what the tool produces. It is distinct from siblings like get_market_regime by focusing on a numeric risk score, status categories, and active crises.

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 states when to use the tool: 'Use this tool FIRST before any trading decision to assess whether market conditions are favorable.' This gives clear precedence, but it does not name alternative tools or explicitly state when not to use it, so it falls just short of a 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?

No annotations are provided, so the description carries the full burden. It discloses the cost ('Costs 2 credits per call') and enumerates the exact outputs (top/worst sectors, advance/decline ratio, momentum scores, sector technical analysis). This goes beyond a simple action statement and gives the agent a concrete picture of what the tool returns, though it omits details like data freshness or interpretation guidance.

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 well-structured: purpose sentence, usage sentence, returns list, coverage list, and cost. It is front-loaded with the core purpose and each sentence adds value. It is slightly longer than minimal, but every part is relevant, so it earns a 4 rather than a 5 for being concise.

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 tool has no parameters and no output schema, the description adequately explains what it returns and what sectors it covers. It also mentions the credit cost. It does not describe how to interpret the momentum scores or the exact format of results, but for a no-parameter analysis tool, this is reasonably complete. A 4 is fair.

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 the schema is empty (coverage 100%). Per the rubric, a 0-parameter tool receives a baseline of 4. The description adds no parameter details because none exist, and no further compensation is needed.

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 ('Analyze') and resource ('sector rotation and market breadth'), and clearly defines the tool's function: identifying gaining/losing momentum sectors. It distinguishes itself from siblings like get_market_regime or get_risk_index by focusing on sector-level analysis, making its purpose unambiguous.

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 'Use this tool to identify which sectors are gaining or losing momentum, helping with sector allocation and rotation strategies.' This provides a clear when-to-use context. It does not explicitly mention when not to use it or name alternatives, but the use case is well-defined, so a 4 is appropriate.

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 of disclosing behavior. It mentions that the analysis costs 5 credits per call and is generated using Claude AI, which conveys cost and dynamic generation. It does not mention rate limits or side effects, but for a read-only analysis tool, the cost and AI-generated nature are the most important behavioral traits, adequately 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 description is moderately sized, with the core purpose and usage front-loaded in the first two sentences. The subsequent list of return values and cost are each useful, but the description could be tightened slightly without losing information. Overall, it is well-structured and each sentence adds value.

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 covers the tool's purpose, usage context, return content in detail, cost, and parameter requirement. Since there is no output schema, it appropriately lists the returned data types. It does not cover error cases or data freshness, but those are minor for this tool. The description is sufficiently complete for an agent to decide when and how to call 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 already provides a detailed description of the 'ticker' parameter with examples, so coverage is 100%. The description only repeats that the parameter is required, adding no new meaning. This aligns with the baseline score of 3 for high schema coverage.

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: providing a comprehensive AI-generated stock analysis. It lists the specific outputs (fundamental data, technical indicators, AI assessment, rating, confidence score), which distinguishes it from sibling tools like get_prices or get_trading_signals that offer more limited data. This is a specific verb+resource with clear differentiation.

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 states when to use the tool: 'when you need detailed information about a company before making an investment decision.' It implies a use case of in-depth analysis rather than quick price checks, but it does not explicitly mention alternatives or when not to use it. This is clear context but lacks explicit exclusions, so it earns a 4.

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 well: it discloses cost (1 credit per call), the API-key distinction for free endpoints, update cadences, and the exact shape of returned signal objects. It stops short of stating whether get_trading_signals itself requires an API key or how errors/rate limits behave, and the mismatched '6 sources' count slightly undermines trust.

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 dense but mostly efficient: purpose, when-to-use, source descriptions, return format, precondition calls, and cost all earn their place. The formatting is a single dense paragraph rather than cleanly structured, and source details are duplicated between the description and schema, making it slightly less polished.

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 compensates by listing the return fields, source cadences, prerequisites, and cost. It also mentions operational ordering with risk and regime. Missing edge-case details like what happens when no signals exist or whether get_commodity_signals is the better choice for commodity-only needs leaves a small but real 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?

Schema coverage is 100%, but the description adds valuable semantics beyond the enum labels: it explains update frequency, market-hours behavior, and the kind of content each source produces. It does not add much about omitting the parameter, though the schema already covers that, so a score above the 3 baseline is justified.

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 verb and resource ('Retrieve AI-generated trading signals') and lists output fields like direction, confidence, and reasoning. However, it claims '6 independent sources' but then lists exactly 5, creating confusion. It also does not explicitly distinguish itself from sibling get_commodity_signals, which overlaps with the scr_daily commodity source.

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 an explicit when-to-use statement ('Use this tool when you need actionable trade ideas') and tells the agent to call get_risk_index and get_market_regime first. It does not mention when not to use the tool or how to choose get_commodity_signals instead, but the guidance present is clear and actionable.

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