Server Quality Checklist

Tool Scores

• get_scanB
  3.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden and does add some behavior: sorting order, validation of tickers, and public access. However, it omits important traits like default filtering behavior (includeFiltered=false), response format, and any rate limits or errors.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, using two short sentences with no wasted words. It front-loads the core function and sorting detail, though the phrase 'One scan' is slightly vague.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple retrieval tool with well-documented schema, the description is adequate but not complete. It leaves out what 'validated' means, the structure of the response, and any special behavior around FILTERED tickers, which is a gap given no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both scanId and includeFiltered fully described. The description adds no extra meaning beyond the schema; it implies filtering via 'validated' but does not directly connect to includeFiltered.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly indicates this tool retrieves a single scan's tickers, with sorting by aiScore and opportunityScore. It distinguishes from list_scans by specifying 'One scan' and from get_ticker by focusing on a scan's validated results.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given for when to use this tool versus alternatives like list_scans or get_ticker. The 'Public' note hints at accessibility but does not clarify conditions, prerequisites, or exclusions.

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

• add_positionB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It only states the action and API key requirement, omitting any details about side effects, duplicate handling, or response behavior. This is minimal for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, no unnecessary words, front-loaded with the core action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no output schema and no annotations, the description is underspecified. It lacks details on return values, duplicate position handling, and whether the API key is required for authentication (which it states but doesn't elaborate). This is a clear gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All four parameters are already described in the schema (100% coverage), so the description adds no additional parameter semantics beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('add a new position') and the resource ('portfolio'), distinguishing it from sibling tools like 'update_position' and 'delete_position'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for adding new positions but provides no explicit guidance on when to use it over alternatives, nor any exclusion criteria. The 'Requires API key' note is a prerequisite, not a usage guideline.

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

• list_scansB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full transparency burden. It discloses auth behavior ('Public') and pagination, but doesn't clarify what a 'harvest scan' is, the return format, or any error/edge conditions. This is some helpful context but not rich behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very short and front-loaded with the core action ('List harvest scans'). It includes a fragment ('Public.') and a tangential note about paid ticker routes, which could be clearer, but the one-sentence primary info is efficient. It's appropriately sized for a simple list tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema and no annotations, so the description must stand on its own. It covers the basic operation and auth, but lacks a definition of 'harvest scans', expected return structure, or any pagination details beyond 'paginated'. This leaves minor gaps for an agent unfamiliar with the domain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides full descriptions for both 'page' and 'limit' (100% coverage). The description adds no additional parameter-level detail, so it doesn't go beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('harvest scans'), making the core purpose clear. It doesn't explicitly differentiate from sibling 'get_scan' but the plural form and 'list' verb imply a collection operation. Additional detail includes pagination, which adds scope clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for listing scans and notes that it is public, but it doesn't explicitly state when to use this vs alternatives like 'get_scan' or 'get_signals'. No exclusions or alternative recommendations are provided, leaving usage guidance largely implied.

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

• remove_from_watchlistA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the disclosure burden. It discloses the authentication requirement ('Requires API key') and implies a mutating action via 'Remove', but it does not describe potential side effects, irreversibility, or response/error behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence followed by a necessary authentication note. It is front-loaded with the action and contains no extraneous words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter mutation tool with no output schema, the description provides the core purpose and an important prerequisite (API key). It lacks details about edge cases (e.g., symbol not found, idempotency), but the low complexity makes this acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% because the 'symbol' parameter already includes a description 'Ticker symbol to remove'. The tool description repeats the term 'ticker symbol' without adding new semantic details, so it adds minimal value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Remove') with a clear resource ('ticker symbol from the watchlist'), making the tool's purpose unambiguous and distinguishing it from sibling tools like add_to_watchlist and list_watchlist.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description only mentions the prerequisite of an API key and gives no explicit guidance on when to use this tool versus alternatives. It does not state any exclusions or mention that list_watchlist could be used to view current symbols before removal.

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

• delete_positionA
  3.8/5.0
  Behavior4/5

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

  The description explicitly discloses that the action is permanent and irreversible, and requires authentication. This is important behavioral context, especially with no annotations to indicate destructive intent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded, with each sentence adding value: purpose, irreversibility, auth requirement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter deletion tool, the description covers the critical aspects—what it deletes, permanence, and auth. It doesn't address error cases or return behavior, but the simplicity and lack of output schema keep this from being a major gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the single 'id' parameter with a helpful description. The tool description adds no additional parameter semantics, which is acceptable given 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb 'delete' and a clear resource 'portfolio position', distinguishing it from sibling tools like add_position and update_position.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives is provided. It states a requirement (API key) but not contextual usage or exclusions.

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

• generate_reportA
  3.8/5.0
  Behavior4/5

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

  Without annotations, the description carries the burden of behavioral disclosure. It discloses a 403 error with x-api-key, a $0.05 cost via x402, the Pro requirement for generating new reports, potential caching when signed in, and the HTTP method POST. These details add meaningful context beyond the input schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely compact, using four short clauses to convey purpose, auth constraints, cost, and method. Every sentence provides distinct value with no repetition or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description covers the main purpose, authentication nuances, cost, and caching behavior. It does not detail the structure of the report or trade setup, but this is acceptable given the tool's simplicity and the absence of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, symbol, is fully described in the schema as 'Ticker symbol' with 100% coverage. The description adds no additional parameter-specific meaning, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'AI report + trade setup,' which clearly indicates the tool produces a report and trade setup. It is distinct from the sibling get_* tools, but the lack of an explicit verb like 'generates' makes it slightly less direct. The name and parameter provide additional clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides important usage context by stating it is not available via x-api-key (403) and suggests using x402 or the website, with Pro required for new reports and cached versions when signed in. However, it does not explicitly compare this tool to alternatives like get_ticker or get_signals, so guidance on when to prefer it is limited.

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

• get_pricesA
  3.8/5.0
  Behavior3/5

  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 mentions a '5-minute cache' (important for data freshness) and 'Auth optional' (a prerequisite), but does not disclose behaviors like handling of invalid symbols, rate limits, or response format. While these are relevant, the description only partially covers the behavioral surface.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the core purpose, then appends two useful qualifiers (cache and auth). There is zero waste or redundancy, and every piece of information serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, no output schema), the description covers essential aspects: scope, cache, and authentication. It is sufficiently complete for the complexity level, though it could mention what the response contains (e.g., price data) or error behavior. However, the absence of an output schema means description doesn't need to explain return values.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the only parameter ('symbols') with a description that includes examples, min/max lengths, and max items. The description adds no parameter-specific meaning beyond the schema, and the 'up to 50 symbols' note merely echoes the schema's maxItems constraint. With full schema coverage, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'Current prices for up to 50 symbols', establishing a specific verb (get), resource (prices), and scope (up to 50 symbols). This distinguishes it from sibling tools like get_ticker which handles a single symbol, and get_ticker_history/performance which target historical data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for batch price queries (up to 50 symbols) and notes that authentication is optional, but it does not explicitly state when to use this tool over alternatives such as get_ticker. There is no 'use this for X, use other for Y' guidance, leaving the agent to infer the context.

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

• get_signalsA
  3.8/5.0
  Behavior4/5

  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 adds useful context: the 200-item cap, the ordering (by source count then velocity), and public access. It does not mention error behavior or rate limits, but for a simple read operation, the disclosed traits are valuable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence with no redundant words. Each clause adds value: the resource ('signals'), scope ('for a scan'), limit ('max 200'), ordering, and access level ('Public'). It is front-loaded with the core purpose and remains highly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple 2-parameter schema and absence of output schema, the description is mostly complete. It covers the key return constraints and access level. A minor gap is not explaining what 'signals' are or how they relate to scan results, but sibling context and schema descriptions mitigate this.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 does not elaborate on scanId or stage beyond what the schema already provides, such as scanning being from list_scans and stage being a filter. No additional semantic value is added.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Raw signals for a scan' with specific limitations (max 200, ordering). This distinguishes it from sibling tools like list_scans or get_scan, though it doesn't explicitly name them. The verb is implied rather than stated (e.g., 'Retrieve'), but the resource and scope are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: use this when you need raw signals for a scan. It mentions 'Public' and ordering, but provides no explicit guidance on when to prefer this over alternatives like get_scan or get_trending. There are no exclusions or alternative tool references.

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

• get_platform_statsA
  3.9/5.0
  Behavior4/5

  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 explicitly states access level ('Public') and a rate limit, and it describes the output contents (three specific stat types). While it does not detail response structure or side effects, it provides meaningful behavioral context beyond the schema alone.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the core concept ('Platform stats') and lists specific data points. Every word adds value, and there is no redundancy or filler. This is an example of efficient, well-structured documentation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only stats tool, the description covers the essential facets: what data is returned (three metrics), access level (public), and a limitation (rate-limited). It omits response format and aggregation period, but given the low complexity and absence of an output schema, it is reasonably complete for an agent to invoke and interpret the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema is fully comprehensive (100% coverage). The description adds no parameter details because none exist, which is appropriate. With 0 params, the baseline is 4, and the description does not detract from parameter clarity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning platform-level stats, enumerating the specific metrics included (completed scans, summed signal counts, distinct validated tickers). Though it uses a noun phrase instead of a verb, the resource and scope are specific and differentiate it from sibling tools that focus on individual tickers or user data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description mentions 'Public (rate-limited)', which provides context on access and constraints, but it does not explicitly state when to use this tool versus alternatives. There is no mention of alternative tools or exclusion criteria, leaving the usage context mainly implicit from the tool's name and stats-oriented content.

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

• get_tickerA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden and does a good job: it discloses that access is paid (API key or x402), clarifies that aiScore is evidence confidence rather than expected returns, and notes that cached report fields are included only if present. It does not cover rate limits or error behavior, but provides meaningful operational context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core action, followed by a concise field list and a clear pricing note. Every sentence adds value without redundancy, making it an efficient and well-structured description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the single parameter and absence of an output schema, the description explains the return payload, clarifies an important score semantics, and discloses pricing. Minor gaps remain (e.g., unexplained 'P&D fields' and 'raw signals'), but the description is largely sufficient for an agent to select and invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for the sole parameter, including a clear example and case-insensitivity note. The description adds no parameter-specific information beyond the tool's overall purpose, so the schema-baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get the latest validated ticker row plus raw signals.' It clearly differentiates from sibling tools like get_ticker_history (historical data) and get_signals (raw signals), and it enumerates the included fields.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving a current, validated ticker snapshot with signals, and notes the paid access requirement, but it does not explicitly state when to use this tool over alternatives or provide exclusions. No sibling-to-sibling differentiation is given.

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

• get_ticker_performanceA
  4/5.0
  Behavior3/5

  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 adds important context: the data is tracked from the time of signal detection, and the tool requires an API key or x402 payment ($0.005). However, it does not mention return format, error handling, or rate limits, so it is only partially transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the primary purpose, lists the specific return windows, and ends with the payment requirement. Every piece of information earns its place with no redundant or filler wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema or annotations, the description sufficiently covers the tool's function and key behavior (return periods and access requirements). It lacks explicit return format details, but for a simple single-parameter read tool, the provided information is largely adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the only parameter 'symbol' described as 'Ticker symbol'. The description reinforces that the symbol is a ticker but adds no new meaning beyond the schema. Baseline of 3 is appropriate since the schema already fully documents the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets price performance data for a ticker, listing specific return periods (1-day, 3-day, 7-day, 30-day). It uses a specific verb ('Get') and resource ('price performance data'), distinguishing it from siblings like get_ticker_history or get_prices which likely serve different data purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use this tool: when you need performance returns over specific windows. It does not explicitly mention alternatives or when-not-to-use scenarios, but the context is unambiguous enough for an agent to select it appropriately.

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

• get_ticker_networkA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral burden. It discloses authorization and cost (API key or x402, $0.01), a key operational detail. It also explains the edge threshold and node source behavior. However, it does not explicitly state that this is a read-only operation or describe rate limits or output format, so it is not 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise—two sentences plus a cost note—and front-loads the core concept. Every word adds value: graph type, node source, edge threshold, and a key use instruction. No redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the description explains the core logic and the symbol omission case, it does not describe the return format or structure of the graph (e.g., list of nodes/edges, adjacency matrix), and there is no output schema to fill that gap. Given the tool's complexity and the absence of annotations, the description is adequate but leaves significant ambiguity about the exact response shape.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the description mostly rephrases existing parameter descriptions (e.g., 'edges above minCorrelation (0–1)' mirrors the schema's 'Minimum absolute correlation (0–1) for an edge'). It ties the parameters together conceptually but adds little new parameter-level information beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly explains the tool produces a price-correlation graph, with nodes derived from co-occurrence or trending data and edges filtered by a correlation threshold. This distinguishes it from sibling tools like get_ticker_related or get_trending by specifying the graph structure and threshold-based edge construction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete usage guidance: 'Omit symbol for trending-based graph' tells when to omit the symbol parameter and implies two usage modes. However, it does not explicitly name alternative tools or state when not to use this tool, so it is not a full 5.

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

• get_portfolio_performanceA
  4.2/5.0
  Behavior4/5

  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 explicitly notes 'Requires API key,' covering authentication needs. The verb 'Get' implies a read-only, non-destructive operation, but the description does not explicitly confirm the absence of side effects or describe behavior for empty/unavailable data, so it is slightly incomplete.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, information-dense sentence that front-loads the action and resource, then efficiently lists the metrics, breakdowns, and authentication requirement. Every phrase adds value with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 covers the core information: what it returns (three metrics), how it groups them (three breakdown dimensions), and the auth prerequisite. It does not specify the exact response shape, but the described data elements are sufficient for basic invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The sole parameter (days) is fully described in the schema with its enum values and default, yielding 100% schema coverage. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves platform-wide portfolio performance statistics, enumerates the specific metrics (win rate, average return, median return), and describes the breakdown dimensions (AI score range, opportunity score range, weekly cohorts). It distinguishes itself from ticker-specific performance tools like get_ticker_performance by emphasizing 'platform-wide' scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description establishes unambiguous context: this is the tool for aggregate portfolio-level performance stats, implying use when cross-position or platform-wide metrics are needed. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of a full 5.

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

• get_trendingA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of disclosing behavioral traits. It transparently notes the paid access requirement (API key or x402) and clarifies a specific output field nuance (summary.avgScore). It does not cover potential rate limits or error behavior, but the key operational quirks are addressed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (three sentences), front-loaded with the primary action, and every sentence contributes critical information (definition, payment, field clarification). There is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (12 parameters, no output schema, no annotations), the description provides a reasonable overview of purpose and key metrics. It even clarifies a response field (summary.avgScore), which helps compensate for the missing output schema. However, it could be more complete by explicitly describing the paginated response structure or indicating that it returns a list.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides detailed descriptions for every parameter (100% coverage), so the description adds minimal parameter-specific value. The brief mention of 'trend (rising/falling/stable from score history)' reinforces but does not extend what the schema already states. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 trending breakout tickers' with specific criteria (2+ scans in last 30 days) and the returned metrics (aiScore, opportunityScore, performance, trend). It effectively distinguishes itself from sibling tools like get_signals or get_ticker by defining a distinct aggregation concept.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 by defining what constitutes a trending ticker (2+ scans in 30 days) and the required payment method. However, it does not explicitly name alternative tools for different use cases, so it stops short of full 'when vs. alternatives' guidance.

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

• list_watchlistA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It states the API key requirement and the enrichment of results, which is useful. However, it does not explicitly confirm this is a read-only operation, nor does it mention pagination, error behavior, or whether results are sorted. This is adequate but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no redundancy. The first sentence front-loads the core purpose and enrichment details, while the second sentence efficiently notes the authentication requirement. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that there are no parameters and no output schema, the description covers the essential aspects: what the tool does, for whom, and what the response contains. It also notes the API key requirement. It lacks details like pagination or sorting, but these are not critical for a simple list endpoint with no input parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema is trivially 100% covered. The description adds context by explaining what the list contains and that it is for the authenticated user, which indirectly clarifies the implicit parameter (the API key). Baseline for zero parameters is 4, and the description does not introduce any ambiguity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('List') and resource ('watchlist items'), scoped to the authenticated user. It also specifies the enriched data (ticker data, signal stage, AI score, performance metrics), making it distinct from sibling tools like add_to_watchlist or get_ticker.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when you need the authenticated user's watchlist with enriched data. It provides clear context but does not explicitly mention alternatives or exclusions, such as using search_tickers for broader searches or get_ticker for individual tickers.

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

• add_to_watchlistA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly states idempotency ('safe to call even if already on watchlist') and the auth requirement ('Requires API key'), which are valuable traits beyond what the schema reveals. It does not mention rate limits or error behavior, but for a simple add operation, this is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences and every word adds value: the action, idempotency note, and API key requirement are all non-redundant. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a low-complexity tool with one well-documented parameter and no output schema. The description covers the core operation, a key behavioral trait (idempotency), and a prerequisite. There are no missing aspects that would prevent an agent from using it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes the only parameter (symbol) with a good example. The description adds minimal additional meaning beyond restating that it is a ticker symbol, so it neither helps nor hurts. 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Add a ticker symbol') and clearly identifies the resource ('the watchlist'). It distinguishes itself from sibling tools like remove_from_watchlist and list_watchlist by conveying the write operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool (to add a symbol) and notes a prerequisite (API key). It does not explicitly list alternatives or when not to use it, but the operation is well-scoped enough that no exclusions are necessary.

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

• list_portfolioA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavioral traits. It covers the API key requirement, the scope (authenticated user), and the contents (open/closed positions, fields). However, it does not mention potential pitfalls like empty portfolios, pagination, or that it is a read-only operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that front-loads the action and resource. Every phrase adds value: scope, included position types, specific data fields, and auth requirement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with no parameters and no output schema, the description sufficiently covers return contents (open/closed, entry price, shares, notes, P&L), scope, and authentication. It provides enough context for an agent to select and call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description adds no parameter-specific meaning. Per the rubric, a baseline of 4 applies when there are no parameters to clarify.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and names the resource 'portfolio positions', scoped to 'the authenticated user'. It also enumerates returned fields (entry price, shares, notes, P&L) and distinguishes from siblings like list_watchlist and get_portfolio_performance.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates this is for viewing the authenticated user's positions, but does not explicitly name alternatives or when-not-to-use scenarios. It does state the authentication prerequisite, which helps with setup.

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

• get_ticker_relatedA
  4.4/5.0
  Behavior5/5

  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 reveals the ranking method, the meaning of latestAiScore, that opportunityScore is not available here, and the cost/authentication requirement. This is substantial, honest disclosure beyond a simple 'returns related tickers'.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, no filler. The first sentence front-loads the core function, and the second adds essential distinctions and cost info. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with six parameters and no output schema, the description is fairly complete: it explains ranking, scoring, the alternative for opportunityScore, and authentication. It doesn't elaborate on 'co-occurring scan symbols' or pagination behavior, but the schema covers pagination and the main use case is clear. Slight gap is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters are already fully described. The description adds only the context that results are ranked by correlationScore, which indirectly clarifies the purpose of parameters like days and symbol, but it does not add new parameter-specific meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: it returns co-occurring scan symbols ranked by Pearson price correlation vs a target. It also distinguishes itself from siblings by specifying the ranking metric (correlationScore) and explicitly pointing to get_ticker for opportunityScore.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear alternative: 'use get_ticker for opportunityScore', which tells the agent when not to use this tool. It also mentions authentication requirements (API key or x402). However, it does not explicitly contrast with get_ticker_network or other related-ticker tools, so it lacks full exclusion guidance.

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

• update_positionA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries full behavioral burden. It discloses the required API key, the partial-update nature of listed fields, and the closing behavior (status CLOSED + closePrice). It does not cover idempotency or response format, but the core mutation semantics are clearly stated.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence efficiently packs verb, resource, key updatable fields, close behavior, and auth requirement with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the moderate complexity, full schema coverage, and no output schema, the description adequately covers purpose, key parameter relationships, and authentication. It could mention expected response or error conditions, but the essential decision-making information is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 meaningful grouping and semantic context by explicitly tying 'close' to 'status CLOSED + closePrice', reinforcing the relationship already in the schema and highlighting the practical field combinations.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Update' with the resource 'position' and enumerates the updatable fields (notes, entryPrice, shares, or close), clearly distinguishing it from sibling tools like add_position, delete_position, and list_portfolio.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys when to use the tool (updating an existing position's fields or closing it) and implicitly differentiates from add/delete/list by naming update-specific actions. However, it does not explicitly state exclusions or explicitly point to alternatives for creation/deletion.

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

• get_methodologyA
  4.5/5.0
  Behavior4/5

  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 discloses that the endpoint is free and requires no API key, which is key operational behavior. The 'Get' verb implies read-only, and the description explains what content will be returned (methodology details). While it does not mention rate limits or response format, the provided traits are sufficient for this simple endpoint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary action ('Get the SignalScope platform methodology') and followed by a brief elaboration on content and access requirements. Every word adds value, with no fluff or redundancy. It is appropriately sized for a simple no-parameter tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 what the tool does, what it returns, and any access constraints. The mention of 'free endpoint — no API key required' covers operational context, and the elaboration on signal handling completes the functional picture. No gaps are apparent given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema coverage is 100% (empty schema). Per calibration guidelines, '0 params = baseline 4'. The description does not need to add parameter details, and no additional semantic explanation is required beyond what the schema already conveys.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 the SignalScope platform methodology' with a specific verb and resource. It elaborates on what the methodology covers (harvested, scored, filtered, staged) and distinguishes it from sibling tools like get_signals or get_platform_stats, which serve different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by noting 'Free endpoint — no API key required,' which tells the agent when this tool can be used without authentication. It does not explicitly name alternatives or exclusions, but given the unique subject matter, this is not necessary. The guidance is clear for a low-risk informational endpoint.

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

• get_ticker_historyA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and excels: it discloses the ~90 scan limit, ordering by scan time, exact columns returned, absence of server-side pagination, and the payment requirement (API key or x402 cost). This is comprehensive behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately sized and front-loaded with the core purpose. Every sentence adds valuable details (leading with purpose, then expected data, then pagination, then cost), with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, the description is remarkably complete: it explains the return columns, limit, ordering, pagination behavior, and cost. It covers all aspects an agent needs to invoke and interpret results correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single parameter 'symbol' ('Ticker symbol'). The description adds no new parameter semantics beyond what the schema already states, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('historical scan appearances for a ticker'), clearly distinguishing it from sibling tools like get_ticker (current data) or list_scans (all scans). It also specifies ordering and limit, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool (when historical scan appearances are needed) but does not explicitly name alternatives or state when not to use it. It provides clear context but no exclusions, aligning with a 4.

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

• search_tickersA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden. It discloses that the endpoint is free, requires no API key, returns up to 8 matches, and specifies the fields returned, including the null behavior for opportunityScore. This is rich behavioral detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, no filler. The first sentence states purpose, the second gives key behavioral details and return fields. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, the description covers the essential behavior, return format, and authentication requirements. It's complete for an agent to understand the tool's functionality.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already defines the query parameter. The description repeats 'by symbol or partial name' but doesn't add new semantic detail beyond the schema's examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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: 'Search SignalScope tickers by symbol or partial name.' This clearly distinguishes it from sibling tools like get_ticker, which likely retrieves a specific ticker.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states the tool searches by symbol or partial name, implying it's for when the exact symbol is unknown. However, it doesn't explicitly say when not to use it or mention alternatives, so it stops short of full guidance.

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