Signal8 MCP Server

Official

by signal8ai

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation4/5
Most tools have distinct, well-described purposes, but the large number of tools (86) introduces some overlap, especially among insider trading tools (e.g., get_insiders, get_insider_transactions, get_insider_positions) and SEC filing tools (e.g., search_sec_filings, screen_sec_filings). The detailed descriptions help, but agents might occasionally misselect between similar-sounding tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., get_quote, search_companies, screen_must_raise). There are no deviations or mixed conventions, making the naming predictable and easy to navigate.
Tool Count3/5
The server has 86 tools, which is very large for a single MCP server. While the breadth of financial data domains (stocks, institutions, politicians, filings, etc.) partly justifies the count, it borders on excessive and could overwhelm agents. A more focused scope or splitting into multiple servers might improve coherence.
Completeness5/5
The tool surface is remarkably comprehensive, covering almost every aspect of financial data: company profiles, financials, insider trading, institutional holdings, political trades, SEC filings, clinical trials, market metrics, and more. There are no obvious dead ends or missing critical operations for the stated domains.
Average 4.2/5 across 86 of 86 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation by stating 'Reads'. It adds minimal behavioral context beyond the annotation and schema, such as the number of trailing periods. No contradictions.
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 concise sentences that front-load the main action with no unnecessary words. Every sentence contributes value.
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?
The tool is simple with 2 parameters and an output schema; the description adequately covers the purpose and parameter scope. It could mention the output schema but is not necessary for completeness.
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 descriptions for both parameters. The description mentions CIK and trailing periods but does not add significant meaning beyond what the schema provides.
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 retrieves an institution's position changes over recent 13F periods by CIK, using a specific verb and resource. However, it does not distinguish from the sibling tool get_institution_position_changes, which could be similar.
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 on when to use this tool versus alternatives like get_institution_position_changes. The description implies usage for recent 13F periods but does not state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds context on what data is returned (buy/sell metrics, top tickers, etc.) but does not disclose additional behavioral traits like rate limits or authentication. No contradictions with annotations.
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 core action and periods, then enumerates data included. No fluff or redundancy; every sentence adds value.
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 read-only tool with a single parameter and output schema available, the description covers the returned data adequately. However, it lacks usage guidelines, which is a gap given the number of sibling tools that could be confused.
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 input parameter 'slug' is already well-documented in the schema. The tool description does not add any additional meaning or clarification about the parameter beyond what the schema provides.
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 activity metrics for a politician broken down by specific periods (30d, 90d, 1y, all-time) and lists included data (buy/sell counts, values, top tickers, transaction type breakdown). This distinguishes it from sibling tools like get_politician_pnl or get_politician_recent_trades which focus on different aspects.
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 provides no explicit guidance on when to use this tool versus alternatives. It only notes it's 'useful for analyzing trading patterns', but does not compare with other politician tools or specify prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description carries less burden. The description adds that the tool returns recent actions but does not disclose additional behavioral traits such as pagination, response size constraints, or data freshness. It is adequate but not enriched.
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 conveys all necessary information without any redundant or extraneous content. It is perfectly concise for the tool's simplicity.
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 low complexity (2 parameters, no nested objects, output schema exists), the description provides sufficient context for an agent to understand the tool's purpose and what is returned. It does not mention sorting or ordering, but the output schema likely covers that. Nearly complete.
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?
With 100% schema description coverage, the baseline is 3. The description adds overall context about the return type but does not elaborate on parameter specifics beyond what the schema already provides. No additional semantic value for parameters.
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 verb 'Get', the resource 'analyst grade actions', and specifies types (upgrades, downgrades, initiations) and included details (grading firm, grades). It effectively distinguishes from sibling tools like get_analyst_consensus or get_analyst_estimates.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention exclusions or context. Without explicit usage direction, the agent must rely on context signals alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation, indicating a read-only operation. It adds some detail about the data returned but does not cover all behavioral aspects like pagination or rate limits.
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, front-loaded with the purpose, no unnecessary words. Every sentence serves a function.
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?
The description mentions the key data fields (phase, status, conditions, interventions) and the context of use. With an output schema available, this is largely complete, though it could mention the limit parameter's effect.
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 input schema already documents both parameters. The description does not add additional parameter semantics beyond what the schema provides.
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 it retrieves clinical trial data for a biotech/pharma company, specifying the included data types. However, it does not differentiate from the sibling tool 'search_clinical_trials', which might have a broader scope.
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?
Provides a context for use ('when analyzing a biotech company's pipeline or upcoming catalyst events'), but does not mention when not to use or alternatives like 'search_clinical_trials'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description contributes minimally. It mentions 'pagination and sorting', but these are fully defined in the schema. No additional behavioral details (e.g., auth requirements, rate limits, or data freshness) are provided.
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?
Single concise sentence with all key elements: action, resource, filter, scope, and features (pagination/sorting). No unnecessary words, front-loaded.
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 output schema exists, description does not need to detail return values. It covers the essential purpose and input (CIK, pagination, sorting) adequately. Minor gap: no mention of what derivative data exactly (e.g., put/call positions, values), but the name and title fill that in.
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 baseline is 3. The description adds context ('PUT/CALL', '13F options') but does not elaborate on parameter usage (e.g., CIK format, period format, sortBy options). It adds marginal 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?
Description clearly states 'Get an institution's reported PUT/CALL derivative positions by CIK (13F options)', specifying the action, resource, and scope. This distinctly separates it from sibling tools like get_institution_holdings (general holdings) or get_institution_portfolio_analytics.
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?
No explicit when-to-use or alternatives are mentioned. The description implies usage for derivative positions via CIK but lacks guidance on when not to use it (e.g., for standard holdings) or comparisons with similar tools like get_institution_holdings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no additional safety disclosure is needed. The description adds pagination behavior but does not discuss rate limits, authentication, or error handling, which is acceptable for a read 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?
A single, well-structured sentence conveys all necessary information without wasted words. It is front-loaded and easy to parse.
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?
With an existing output schema, the description need not detail return fields. The description covers the core functionality and pagination, which is sufficient for a straightforward list tool. However, it could optionally mention the filing type (13F) more prominently.
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 all parameters described. The description adds 'by CIK' and 'pagination,' but these are already implied by the schema. No new meaning is added beyond the structured fields.
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 a list of 13F filings for an institution by CIK, with pagination. It uses a specific verb and resource, differentiating it from sibling tools like get_institution_holdings or get_institution_detail.
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 provides no guidance on when to use this tool versus alternatives, such as get_institution_holdings. Given the large number of sibling tools, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds little beyond stating it's for analytics. It does not disclose authentication needs, rate limits, or error handling for invalid CIK, but with annotations covering the read-only nature, a 3 is appropriate.
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?
Single sentence of 12 words, front-loaded with action and output. Every word earns its place; no fluff.
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?
Tool has only one required parameter and an output schema (not shown but exists). The description sufficiently covers what the tool does without needing to explain return values. Complete for a straightforward read-only analytics 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?
Schema coverage is 100% with one parameter 'cik' fully described. The description mentions 'by CIK' but adds no extra semantic detail beyond the schema. Baseline of 3 is correct.
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 sector allocation and top holdings analytics for an institution's portfolio by CIK. This specific verb-resource combination distinguishes it from sibling tools like get_institution_holdings (raw holdings) and get_institution_detail (general info).
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 among the many institution-related siblings. Does not specify prerequisites, when not to use, or which scenarios are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, and the description does not contradict this. However, beyond being read-only, the description lacks additional behavioral context such as data freshness, pagination, or whether it requires specific permissions. Given the annotations cover safety, a score of 3 is appropriate.
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, front-loaded sentence that conveys all essential information without any wasted words. It is efficient and easy to parse.
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 low parameter count (1), existence of an output schema, and the description's mention of the return contents (grades, targets, coverage breadth), the tool is well-covered. Minor gap: no mention of the output schema's structure, but the output schema exists to provide that. A score of 4 reflects good completeness for a simple 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 input schema has only one parameter (ticker) with a complete description in the schema. The tool description does not add any additional parameter-level information beyond what the schema already provides. With 100% schema coverage, baseline is 3.
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 it returns aggregated analyst coverage for a ticker, including grades, targets, and coverage breadth. It distinguishes itself from sibling analyst tools like get_analyst_consensus and get_analyst_estimates by specifying a consolidated view.
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 a broad overview of analyst coverage, but does not explicitly state when to use this tool versus alternatives like get_analyst_grades or get_analyst_estimates. No exclusion criteria or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read-only nature is covered. The description adds behavioral context: date range, optional country filter with default to US. It does not discuss pagination, rate limits, or data format, but this is acceptable for a simple retrieval 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?
The description is two sentences, front-loading the core function. Every sentence provides valuable information with no redundancy. Highly concise and well-structured.
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?
With an output schema and complete annotations, the description covers the essential behavior: purpose, parameters, defaults. It lacks explicit mention of return format, but the output schema fills that gap. For a tool with moderate complexity, it is sufficiently complete.
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 parameters are already documented in the schema. The description adds context about country being ISO-3166 alpha-2 and the default behavior, but does not provide significant additional 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 retrieves scheduled macro/economic events (CPI, FOMC, etc.) between two dates. This verb+resource combination is specific and distinguishes it from sibling tools like get_earnings_calendar or get_filing_calendar. The examples further clarify the scope.
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 indicates use for macro events and optional country filtering with a default. However, it does not explicitly state when to choose this tool over alternatives (e.g., get_earnings_calendar for earnings events). No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with read operation. Description adds significant behavioral context: cluster buying detection, entity-centric model, Form 4 cross-referencing, transaction breakdown by SEC code, netSharesSold12m calculation, and isPrimarilyTaxWithholding flag. Exceeds basic annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is moderately long but each sentence adds value. Starts with main purpose, then details features and transaction breakdown specifics. Could be slightly more concise but well-organized.
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?
Given complexity of insider data and existence of output schema, description provides comprehensive overview of data content and flags. Covers transaction codes, net shares, tax withholding distinction, and pagination, making it complete for agent decision-making.
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 descriptions for ticker, limit, and offset. Description mentions pagination via limit/offset but adds no new semantics beyond 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?
Description clearly states verb 'Get' and resource 'insider trading discovery data' with specific features like cluster buying detection and Form 4 cross-referencing, distinguishing it from sibling tools like get_insider_transactions or get_insider_cluster_buys.
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 on when to use this tool versus alternatives such as get_insider_transactions, get_insider_positions, or get_insider_cluster_buys. Agent must infer from feature list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description aligns with ('Get','Returns'). The description adds return field details (shares, weight, dates) beyond annotations, but no additional behavioral traits like pagination limits or data freshness. Acceptable but not extensive.
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 succinct sentences with no wasted words. The first sentence clearly defines purpose and resource, the second adds return details. Perfectly front-loaded.
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 a simple retrieval tool with 3 parameters and an output schema, the description adequately covers purpose and return values. It lacks mention of pagination or data freshness, but the schema covers parameters and output schema covers returns, so overall complete.
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 baseline is 3. The description does not add additional meaning to the parameters (ticker, limit, offset) beyond what the schema provides. No extra context on formatting or behavior.
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 institutional holders (13F filers) for a company, specifying the resource, action, and returned data (shares held, portfolio weight, filing dates). It distinguishes from siblings by focusing on holders for a specific ticker and mentioning 13F filings.
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 'useful for understanding institutional ownership concentration,' which implies usage context, but does not explicitly guide when to use this tool versus similar siblings like get_institution_holdings or get_institution_activity. No direct comparisons or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds value by disclosing the data source (GovTrack), current bias ('currently Senate-heavy'), and the content of each vote (member, bill info, position, result). This provides behavioral context beyond the annotation.
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 long, with the first sentence clearly stating the main purpose and the second detailing the output. Every word is necessary, and it is front-loaded with key information.
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 presence of an output schema, the description adequately covers what the tool returns. It mentions the data source and a caveat (Senate-heavy). However, it could be slightly more complete by explicitly noting that only recent votes are returned and that House votes may be limited.
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 two parameters (limit, offset), so they are already documented. The description does not add further meaning about parameters, so it meets the baseline expectation.
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 the tool gets 'recent congressional roll-call votes across all members', specifying the verb 'get' and the resource 'recent congressional roll-call votes'. It distinguishes from siblings like 'get_politician_votes' by noting 'across all members' and mentioning the source GovTrack and both chambers.
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 provides no guidance on when to use this tool versus alternatives, such as 'get_politician_votes' for a specific politician or 'get_legislative_calendar' for calendar data. No when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which is consistent. Description adds significant detail on estimation methodology (historical price estimation, FIFO, mark-to-market) and accuracy range (±25-40%), providing transparency beyond annotations.
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?
Description is front-loaded with purpose and then provides necessary methodology details. Slightly longer than necessary but well-structured and every sentence adds value.
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 complex leaderboard with estimation methodology, the description adequately explains the calculation approach and accuracy. With an output schema likely present, return values need not be described, and the description covers the key behavioral aspects.
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 schema fully documents parameters. Description adds no extra meaning beyond listing sort options, which are already in schema enums.
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?
Clearly states it ranks politicians by estimated trading P&L, distinguishing it from siblings like get_politician_pnl (individual) and get_policy_trade_leaderboard (policy trades). The verb 'rank' and resource 'politicians P&L leaderboard' are specific.
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?
Does not explicitly state when to use vs alternatives or provide exclusions. The purpose is clear from context, but no guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds value by listing specific output fields (cash anchor, burn rate, capital raises, runway scenarios) and the error condition (404), providing clear behavioral expectations beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four focused sentences. It is front-loaded with the purpose. No content is wasted, but it could be slightly more compact. A score of 4 reflects good efficiency without being the absolute minimum.
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?
Given the tool's simplicity (single parameter, existing output schema, annotations present), the description covers the purpose, usage, return values, and error condition comprehensively. There are no missing critical details for an agent to invoke this tool 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 has 100% coverage for the single parameter 'ticker', with a clear description. The tool description does not add any additional parameter semantics beyond what the schema already provides, so a 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 clearly states the verb 'Get' and the resource 'Signal8 AI cash position model', and enumerates return data. However, it does not explicitly distinguish itself from sibling tools like get_cash_history or get_cash_runway_calendar, so it falls short of a 5.
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 explicit usage context: 'Use when analyzing a company's current cash situation, runway, or capital raise activity.' It also notes the 404 condition. However, it does not mention when not to use the tool or suggest alternative tools, so it does not achieve a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint annotation already indicates safety. Description adds specificity about trading halt status fields (halted/haltCode/haltedAt) and behavior for halted-but-listed tickers, going beyond annotations.
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 plus a clarifying line about halt status. Front-loaded with key information, no redundant content.
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 presence of output schema, description adequately covers return fields (CIK, exchange, etc.) and highlights special status fields. Lacks mention of error conditions or prerequisites, but sufficient for a simple lookup.
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 covers 100% of parameters with description. The description reiterates ticker symbol usage but adds no new semantics beyond schema.
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?
Clear verb+resource ('Get enriched company profile by ticker symbol'). Distinguishes itself as a lightweight lookup compared to a 'full bundle', though doesn't name the alternative tool explicitly.
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?
Explicit guidance: 'use this when you only need basic company info rather than the full bundle' and mentions credit cost (1 credit). Does not list when not to use but implies scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds useful context that data is derived from Form 4 filings, which explains the data source and reliability, adding value beyond annotations.
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 redundant words. Front-loaded with the core purpose, then additional detail. Highly efficient.
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 one parameter, readOnly annotation, and an output schema (not shown but exists), the description is largely complete. However, it could mention if data is real-time or delayed, or note any limitations.
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 schema describing 'ticker' as the stock symbol. The description adds minimal extra meaning beyond that, such as 'lifetime position aggregates', but does not clarify parameter format or constraints.
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 returns per-insider lifetime position aggregates for a given ticker, specifying it's derived from Form 4 filings. It distinguishes from siblings like get_insider_positions (which likely has different scope) and get_insider_transactions.
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 use when needing insider position aggregates but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true. Description adds the extended-hours behavior constraint (only with resolution 1) and lists returned fields, but doesn't discuss other behavioral aspects like authentication, rate limits, or data adjustment. Adequate given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: first states action and options, second gives use case, third explains extended-hours nuance. No wasted words, front-loaded with essential information.
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?
Covers purpose, parameters (via schema), and a key behavioral nuance. Output schema exists and can detail return format. A mention of timezone or data source could improve completeness, but not strictly necessary.
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 parameters are already well-documented. The description reiterates the extended-hours condition but adds minimal extra meaning beyond summarizing 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 specifies it retrieves intraday OHLCV candles at discrete resolutions (1,5,15,30,60 min). It distinguishes from sibling tools like get_historical_prices (likely daily) and get_quote (current) by explicitly mentioning 'intraday' and the resolution options.
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?
States use for 'intraday price action analysis, volume patterns, and short-term technical analysis,' providing clear context. Does not explicitly exclude other uses or name alternatives, but the context is sufficient given many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds that it returns computed metrics like volume averages, volatility, SMAs, and trend direction, providing useful behavioral context beyond the annotation.
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 concise sentences with front-loaded purpose. Every part earns its place, and there is no waste.
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?
With a simple single-parameter tool, clear purpose, output schema present, and annotations, the description is fairly complete. It mentions the metrics included and usage context, though it could briefly mention data freshness or response format, but not required.
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 'ticker' parameter. The description does not add extra meaning beyond the schema, so 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 clearly states it computes market metrics (volume averages, volatility, SMAs, trend direction) and distinguishes from the basic quote. However, among many sibling tools like get_volume_profile or get_accumulation_snapshot, it does not explicitly differentiate, so it's not fully distinct.
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 says 'Use when analyzing trading patterns or technical indicators beyond the basic quote,' providing clear usage context. It does not specify when not to use or name alternatives, but the guidance is sufficient for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds context about the meaning of flaggedTradeCount, matchBasis, and matchCount, along with a caution that sector matches are not evidence of foreknowledge. This goes beyond annotations, though pagination behavior is not explicitly described.
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 front-loaded with the core purpose, followed by filter details and important interpretation notes. It is efficient, though slightly lengthy; every sentence adds value.
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?
Given the complexity of policy-event data with trade co-occurrence, the description is complete: it specifies filter options, response fields, and critical interpretation caveats. The output schema exists, but the description provides necessary context beyond it.
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 parameters are well-documented in the schema. The description adds context about the response fields but does not significantly enhance parameter semantics beyond what is already provided.
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 verb 'List', the resource 'mirrored executive orders (policy events)', and the source 'Federal Register feed'. It distinguishes from sibling tools like get_policy_trade_leaderboard by focusing on the policy events themselves rather than trades or overlaps.
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 does not explicitly state when to use this tool versus alternatives, such as other policy-related tools among siblings. It provides important caveats about sector matches but lacks guidance on when not to use it or which alternative to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true, so the read-only nature is clear. Description adds the specific data returned but no additional behavioral traits like rate limits or data freshness. No contradiction with annotations.
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 fluff. Immediately states the data returned and its purpose. Every word serves a function.
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 output schema exists and annotations cover safety, the description is sufficient for a simple data retrieval tool. No mention of limits or pagination, but the tool is simple enough that the description is 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?
Only parameter is 'ticker' with schema description 'Stock ticker symbol.' Schema coverage is 100%, so the description adds no new meaning beyond what the schema provides. Baseline 3.
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?
Description clearly states the tool gets short interest data and lists specific metrics (short volume, short ratio, days to cover, short percent of float). This is distinct from siblings like get_float or get_ownership, which are also stock data tools.
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?
Provides explicit use cases: 'analyzing bearish sentiment or potential short squeeze setups.' Lacks explicit when-not-to-use, but the context is clear enough given the specificity of the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate safety. The description adds context about market-wide scope and filtering, but does not disclose additional behavioral traits like authentication requirements, rate limits, or response behavior. Given the annotation coverage, this is adequate but not outstanding.
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 with zero fluff. The first sentence states the primary action and scope, the second lists filters and operations. Front-loaded with the most critical information (market-wide vs single ticker). 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 11 parameters, an output schema, and annotations declaring read-only, the description covers the essential context: scope, differentiation from sibling, and filter capabilities. Pagination details (offset, limit) are in the schema. The description could mention the output schema or result format, but it's not required. Overall, complete enough for this 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?
Schema description coverage is 100%, with each parameter having a description in the input schema. The description lists filter categories (phase, indication, sponsor, etc.) but does not add meaningful syntax or format details beyond what is already in the schema. The baseline score of 3 is appropriate as the description adds marginal value.
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 it searches clinical trials market-wide (cross-company) and explicitly distinguishes it from get_clinical_trials which is ticker-scoped. The verb 'search' combined with the resource and scope makes the purpose precise and 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 explicitly differentiates from get_clinical_trials by scope (market-wide vs single ticker). It lists filter capabilities, implying when to use this tool (broad search with filters). No explicit when-not-to or alternative tools beyond the one mentioned, but the differentiation is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds context about the data sources (SEC filings, market data, exchange rules) and credit cost. This provides useful behavioral context beyond the annotation, though it does not discuss pagination or performance.
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?
Three sentences efficiently convey purpose, scope, and cost. No redundancy or extraneous information. Could be slightly more concise but is well-structured.
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?
With an output schema present, the description need not detail return values. It covers the tool's comprehensive nature and cost. It is complete enough despite not mentioning prerequisites, which are likely minimal.
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 parameter 'ticker' described. The description does not add further detail about the parameter, but none is needed. 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 it 'Get full compliance rules evaluation for a company' and lists specific rules evaluated (Nasdaq/NYSE deficiency detection, bid price tracking, delinquent filing detection). This is specific and distinct from sibling tools, as no other tool focuses on compliance.
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 use for thorough compliance checking and mentions cost (25 credits). It does not explicitly contrast with alternatives but, given no direct compliance siblings, this is sufficient. Could be improved by stating when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so safety is clear. Description adds that it returns executives with specific attributes but no additional behavioral details like rate limits or data freshness. It does not contradict annotations.
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 redundant information, and front-loaded with the core purpose.
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?
With a simple single-parameter input and an output schema present, the description covers necessary context (company executives, specific fields) for an agent to use the tool effectively.
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% and already describes the ticker parameter. The description does not add any new meaning to the parameter, sticking to output fields.
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 verb 'Get' and the resource 'key executives and officers of a company', listing specific fields. It distinguishes itself from sibling tools like get_insiders by focusing on leadership rather than transactions.
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?
Description advises using when 'researching company leadership or management quality', providing context. However, it does not explicitly state when not to use it or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, and the description uses 'Get', aligning with a read-only operation. The description does not add any behavioral traits beyond what annotations already provide, so a baseline score of 3 is appropriate.
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 concise sentences, front-loaded with the core purpose, and no extraneous information. Every word serves a purpose.
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?
Given that the tool has 0 required parameters, 100% schema coverage, an output schema, and readOnlyHint annotations, the description covers all necessary context. It explains the core function and optional filters, which is complete for an AI agent to use this tool 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%, and the tool description briefly summarizes the parameters (date window, universe, formTypes) and their defaults. However, it does not add significantly more meaning than the schema itself, so baseline 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 states 'Get the forward-looking 10-K / 10-Q SEC filing-deadline calendar', specifying the verb (Get), the resource (filing-deadline calendar), and scope (within a date window). This distinguishes it from sibling calendar tools like get_earnings_calendar or get_economic_calendar.
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 explains the optional filters (universe, formTypes) and implies this is the tool for SEC filing deadlines. It does not explicitly state when not to use it or list alternatives, but the context is clear enough for an AI agent to differentiate from other calendar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no contradiction. The description adds period types but no additional behavioral details like pagination behavior or data latency. Minimal added value beyond annotations.
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, front-loaded with key purpose and period options, no redundant words. Efficient and clear.
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?
Output schema exists, so return structure is covered. Description explains what data is retrieved and when to use it, which is sufficient for selecting this tool among many financial siblings.
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?
Input schema has 100% coverage, each parameter already includes a description. The tool description does not add further meaning or context for parameters.
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 income statement, balance sheet, and cash flow data for a company, specifying exact financial statements and period types (annual, quarterly, TTM). It distinguishes from sibling tools by naming the specific resources.
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 explicit use cases ('when analyzing revenue, profitability, debt, or cash position') but does not explicitly mention when not to use or compare to sibling tools like get_earnings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation by using non-mutating verbs (discover, searches, find). It adds context about the tool's behavior (e.g., cluster buying patterns) but does not disclose additional behavioral traits beyond what annotations imply. With annotations present, the description contributes moderate value.
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 three sentences, each with clear purpose: first defines action, second contrasts with sibling, third lists filters and use cases. No redundant information, front-loaded with the main idea.
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?
The tool has an output schema (not shown) and 6 optional parameters; the description covers its core capability (cross-company insider search), mentions result types (cluster buying, large transactions), and is sufficient given the presence of an output schema for 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?
Schema description coverage is 100%, so the baseline is 3. The description mentions filtering by insider name, transaction type, or date range, which maps to several parameters, but does not add semantics beyond what the schema already provides.
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: 'Discover insider trading patterns across multiple companies.' It uses a specific verb (Discover) and resource (cross-company), and explicitly distinguishes from sibling get_insiders by noting the single-ticker vs. universe-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 provides an explicit alternative: 'Unlike get_insiders which shows insider activity for a single ticker...' and suggests use cases like detecting coordinated activity. However, it does not specify when not to use this tool or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds 'recent' constraint but no further behavioral traits beyond what annotations provide.
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 concise sentences, front-loaded with purpose, no wasted words.
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?
With output schema present, description covers all needed context for a simple retrieval 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?
Schema coverage is 100% with full descriptions; description adds no new parameter info 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?
Description clearly states 'Get recent news articles and press releases for a company' with specific verb and resource, easily distinguishing it from siblings.
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?
Provides explicit usage context ('when researching recent developments, catalysts, or sentiment drivers'), though no explicit when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that figures are estimates with ±25-40% error, details the FIFO and mark-to-market methodology, and matches the readOnlyHint annotation. No contradictions.
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 somewhat long but well-structured, front-loading purpose and methodology, then explaining output and accuracy. Every sentence adds value.
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, the description covers methodology, output structure, and accuracy. The output schema exists, so the description's overview is sufficient. Minor gap: no explicit mention of pagination or limits.
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 baseline is 3. The description adds context about slug format and prerequisite, but the schema already includes a detailed description of the slug parameter.
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 retrieves estimated P&L for a politician, with specific resource and action. It mentions scope (Congress and executive branch) but does not explicitly differentiate from sibling tools like get_politician_activity or get_politician_transactions.
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?
Provides explicit prerequisite: 'Use get_politicians first to find the slug.' Also explains methodology and accuracy caveats, helping the agent decide when to use this tool. Lacks explicit when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds specifics on return fields (trade count, tickers, buy/sell values) and behavior (ranking by trade count, lookback period). No contradictions.
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 concise sentences, front-loaded with key information. No wasted words.
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?
Tool has only 2 parameters, description fully explains purpose and returned data. Output schema exists to detail exact return fields; no gaps.
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%. Description mentions lookback period and default but does not add meaningful extra context beyond what the schema already provides.
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?
Description clearly states verb 'discover' and resource 'congressional traders ranked by trade count within a lookback period'. It is specific and distinguishes from other politician tools like get_politician_activity which focuses on individual activity.
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?
Implies usage for identifying prolific traders but lacks explicit guidance on when to use versus alternatives. No exclusions or when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, so the safe read behavior is covered. The description adds valuable context by listing the exact data fields returned (ticker, transaction type, amount range, filing delay, late flag, and summary totals), which goes beyond the annotation. No contradiction with annotations.
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: the first front-loads the core purpose, the second details the output. Every word serves a purpose; no redundancy or fluff.
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?
Given the tool has 6 parameters (with clear schema), annotations, and an output schema, the description is complete. It covers the essential what, why, and what-comes-back without needing to explain return values explicitly.
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 has 100% parameter description coverage, so the schema already defines each parameter adequately. The description adds no additional parameter-level semantics beyond what the schema provides, hence baseline 3.
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 explicitly states the action ('Get paginated trade history'), the target resource ('specific politician'), and the output content (STOCK Act disclosures with specific fields and a summary). This clearly distinguishes it from sibling tools that focus on other aspects like PnL, recent trades, or leaderboards.
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 does not provide when-to-use or when-not-to-use guidance relative to other politician trade tools (e.g., get_politician_recent_trades, get_senate_trades_by_ticker). Usage is implied by the purpose, but no explicit context or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only (readOnlyHint=true). The description adds valuable behavioral context about the trading-halt status field and the excludeHalted feature, which goes beyond the annotation. No contradictions.
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 concise with two sentences, front-loading the purpose and key features. The second sentence is somewhat long but still clear. Could be split for readability, but overall efficient.
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 20 optional parameters and existing output schema, the description covers the screening purpose and highlights the halt status feature. It does not detail pagination or return structure beyond key metrics, but the output schema fills that gap. Reasonably complete.
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 parameter descriptions. The description adds minimal extra semantics, primarily highlighting the excludeHalted parameter behavior and sorting capability. For most parameters, the schema already provides sufficient meaning.
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 screens companies by multiple financial and industry criteria, listing specific filters (price, volume, cash runway, etc.) and noting sortability and pagination. It distinguishes itself from sibling tools like get_quote or screen_sec_filings by its focus on broad company screening.
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 usage for filtering companies with numeric/industry criteria and mentions the optional excludeHalted parameter, providing context for when to use it. However, it does not explicitly state when not to use it or name alternative tools for simple lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to add safety info. It adds return field details but no additional behavioral traits beyond the annotation.
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 efficient sentences: first states action and return, second provides usage guidance. No wasted words.
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?
With output schema existing and return fields mentioned, the description is complete for a simple search tool. Covers purpose, usage, and return.
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 parameter descriptions; the tool description does not add additional parameter meaning beyond the schema, hence baseline 3.
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 it searches companies by name or ticker, specifies return fields (ticker, name, CIK, exchange), and distinguishes itself from sibling get_* tools by positioning as the first step.
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?
Explicitly says 'Use this as the first step to find a company before calling other tools,' providing clear context for when to use it. Lacks explicit 'when not to use' but is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's safety profile is covered. The description adds that it returns forward estimates but does not detail behavior on invalid tickers or rate limits. Overall adequate, but no significant extra transparency beyond the annotation.
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 consists of two concise sentences. The first sentence covers purpose and key outputs, the second provides usage context. No unnecessary words, and the most important information is front-loaded.
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 three parameters and existing output schema, the description is complete for an agent to understand the tool's purpose and when to use it. It does not need to explain return values since the output schema exists. Minor gaps (e.g., error handling) are acceptable for a simple read 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?
Schema coverage is 100%, but the description adds meaning by listing the financial metrics (EPS, revenue, EBITDA, net income) and stating support for annual/quarterly periods, which is not present in the schema descriptions. This helps an AI agent understand what values to expect.
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 forward analyst estimates (EPS, revenue, EBITDA, net income) with low/high/avg and analyst counts. It distinguishes itself from sibling tools like get_analyst_consensus or get_analyst_grades by specifying it provides detailed breakdowns per period.
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 explicitly says 'Use when analyzing forward earnings expectations or revenue forecasts,' providing clear context. It does not specify when not to use it, but the guidance is sufficient for an AI agent to identify relevant scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds value by specifying the data fields returned (EPS, revenue, surprise), which is beyond what annotations provide. No contradiction.
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, front-loaded with key action and content. Every word is informative.
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?
With an output schema and good parameter documentation, the description covers purpose and usage adequately. Could mention ordering of results, but not necessary given available context.
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 descriptions for both parameters. Description does not add extra meaning beyond the schema (e.g., default limit is mentioned in 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 clearly states the tool retrieves historical earnings data with specific fields (EPS, revenue, surprise percentages). It distinguishes from sibling tools like get_earnings_calendar by focusing on historical vs future data.
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?
Provides explicit context ('use when analyzing earnings beats/misses or upcoming earnings expectations') but does not mention when not to use or name alternative tools explicitly. However, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's read-only. The description adds behavioral context (identifies periods of cluster buying, interpreted as bullish) which goes beyond the annotation without contradiction. No destructive actions mentioned.
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: first states purpose, second explains condition and interpretation. No unnecessary words, highly efficient.
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?
The description covers the core functionality and significance. With an output schema existing (as indicated in context), the lack of output details is acceptable. Some limitations or edge cases could be mentioned for higher completeness.
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?
Only one parameter (ticker) with 100% schema coverage. The description does not add additional meaning beyond the schema's 'Stock ticker symbol'. Baseline score of 3 is appropriate since the schema already documents the parameter adequately.
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 detects cluster buying patterns for a company, specifying the condition (3+ distinct insiders within 14-day window) and interpreting it as a strong bullish signal. This distinguishes it from sibling tools like get_insider_transactions by focusing on cluster detection.
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 indicates when to use the tool (to detect cluster buying patterns) but does not explicitly state when not to use it or compare to alternatives. The context is clear, but lacking explicit exclusions prevents a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known safe. The description adds behavioral context by describing the returned data type and filter capabilities, but does not mention rate limits or other operational constraints, which is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 4 sentences, each earning its place: purpose, return data, pagination, filtering, and use case. Information is front-loaded, and no redundant or irrelevant content exists.
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?
Given the presence of an output schema (so return values need not be described), the description covers all essential aspects: filtering, pagination, transaction codes, and a practical pattern. No gaps are evident for a tool of this complexity.
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% with descriptions for all 6 parameters. The description adds value beyond the schema by listing example transaction codes and explaining how to use year/month filtering. It does not repeat schema information verbatim.
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 it retrieves insider transaction history from Form 4 filings, specifying the data fields returned (insider name, title, shares, price, transaction codes). It distinguishes from siblings implicitly by focusing on transaction-level detail rather than positions or clusters, but does not explicitly differentiate.
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 explicit filtering guidance (year, month, transactionCode) and a practical use case ('first insider buy since X patterns'). However, it does not directly state when to use this tool over alternatives like get_insider_positions or get_insider_cluster_buys.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description adds behavioral detail beyond annotations: ranking by AUM, cross-company scope, optional min AUM filter. No contradictions.
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?
Three sentences, front-loaded with primary purpose, differentiation, optional parameter, and use case. No wasted 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?
Output schema exists so return values are covered. Description covers purpose, differentiation, optional parameter, use case. Lacks mention of offset/pagination but schema handles it. Complete enough for a low-complexity 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?
Schema coverage is 100% and describes all parameters well. Description adds minimal extra meaning ('Optionally set a minimum AUM'), which aligns with schema. No additional semantics beyond what schema provides.
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 verb 'Discover' and resource 'top institutional holders across the entire company universe ranked by AUM', distinguishing itself from get_ownership which shows institutions for a single company.
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?
Explicitly contrasts with get_ownership ('Unlike get_ownership...this tool searches across all companies') and provides use cases ('identifying smart money flows and major institutional positioning trends'). Lacks explicit when-not-to-use guidance but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds valuable behavioral details: the selection criterion (45-day rule) and sorting order (filing delay descending). This goes beyond the annotations without contradicting them.
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 wasted words. The first sentence immediately defines the tool's function, and the second adds a practical use case. Each sentence 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 the existence of an output schema and high schema coverage, the description provides sufficient context: it explains the core logic, sorting, and use case. It does not need to detail return fields. A small improvement could be to mention that results are limited by the parameters, but the schema covers that.
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?
While schema coverage is 100%, the description adds domain context by explaining that 'late' means filed more than 45 days after the transaction, which clarifies the meaning of the 'days' parameter and the overall data. This aids the agent in understanding parameter impact.
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 verb ('Get') and a well-defined resource ('STOCK Act late filing violations') with clear criteria (filed more than 45 days after transaction, sorted by filing delay descending). This distinguishes it from sibling tools like get_politician_transactions or get_politician_recent_trades.
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 a clear use case ('identifying politicians with poor disclosure compliance') but does not explicitly state when to use this tool versus alternatives, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms it's a read operation. It adds value by detailing returned fields: 'senator info, ticker, transaction type, amount, and filing delay', which is beyond annotations.
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 with no fluff: first states purpose, second describes output fields and filters. Essential information is front-loaded and every sentence 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 read-only list tool with full schema descriptions, output schema, and annotations, the description covers purpose, output fields, filters, and a use case. It could mention pagination or defaults but schema handles that.
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 descriptions exist for all 4 parameters. The description highlights 'Filter by direction (buy/sell) and lookback period' which aligns with direction and days params, but doesn't add significant extra meaning for limit and offset.
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 'Get recent STOCK Act trades across all politicians' with a specific verb and resource. It distinguishes from siblings like get_politician_transactions and get_senate_trades_by_ticker by indicating it covers all politicians and recent trades.
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: 'Useful for monitoring current congressional trading activity' and mentions filters by direction and lookback period. It does not explicitly exclude alternatives but implies that for specific politicians, other tools may be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the default behavior (consensus split-adjusted average) and the effect of the list parameter. Annotations declare readOnlyHint=true, which aligns. No contradictions. It adds context beyond annotations.
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 with no wasted words. Front-loaded with purpose. Efficiently conveys key information.
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 output schema exists and schema coverage is complete, the description sufficiently covers behavior. Could briefly mention prerequisites like data availability, but overall complete for a read-only analytics 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?
Schema coverage is 100%, baseline 3. The description adds meaning by explaining the list parameter's effect (consensus vs per-analyst) and limit parameter's context (only when list=true). This goes 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 gets analyst price target data for a ticker, distinguishing between consensus and per-analyst list. It uses specific verbs ('Get') and specifies the resource ('price target data'), differentiating it from sibling tools like get_analyst_consensus or get_analyst_estimates.
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 price targets but does not explicitly state when to use this tool versus alternatives like get_analyst_consensus. It provides context on the list parameter but lacks exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true. The description adds significant behavioral context beyond annotations by detailing the types of splits (forward/reverse), data fields (dates, ratios, type classification), and the specific cumulative 2-year reverse split ratio. No contradictions with annotations.
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 concise, front-loaded sentences. The first sentence states the core purpose, and the second adds a specific compliance context. Every word adds value; no 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?
The tool has an output schema (not shown but indicated), so the description does not need to explain return values. It provides a complete overview of the data included and a specific use case. For a single-parameter tool with a clear purpose, this is sufficient.
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 one required parameter (ticker) documented in the schema. The description does not add new semantic details about the parameter beyond what the schema already provides, so 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 specific verbs and resources: 'Get stock split history for a company' including forward and reverse splits with dates, ratios, etc. It clearly distinguishes from sibling tools (e.g., other financial data retrieval tools) by focusing exclusively on stock splits.
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 this tool: for NASDAQ/NYSE minimum bid-price compliance and understanding cumulative reverse splits. However, it does not explicitly state when not to use it or name alternative tools for similar data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds details on what metrics are returned (e.g., VWAP, volume). No contradiction, though it doesn't mention any limitations or edge cases.
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 concise sentences front-loading the action and listing key metrics without any extraneous text. Highly efficient.
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?
Given the simple input schema (one parameter) and the presence of an output schema, the description fully explains the return values. No gaps for an agent to interpret.
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?
With 100% schema coverage for the single parameter 'ticker,' the description adds no additional meaning beyond the schema's 'Stock ticker symbol.' 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 it gets intraday accumulation/distribution metrics for the current or most recent trading session, listing specific metrics like VWAP and volume breakdowns. This distinguishes it from other data retrieval tools among the many siblings.
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?
Explicitly states 'Use for assessing real-time buying/selling pressure,' providing clear context for when to use. However, it does not contrast with siblings like get_volume_profile or get_intraday_bars.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns as a pure data retrieval. The description adds transparency by enumerating returned fields (price target, breakdown) which goes beyond annotations. No contradictions.
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 concise sentences: first describes action and outputs, second gives usage context. No redundant information; front-loaded with the core function.
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?
Given the tool's simplicity (1 parameter, no nested objects, output schema present), the description covers the purpose, outputs, and usage. No additional context is needed for correct 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?
Schema coverage is 100% for the single parameter 'ticker', and the description does not add extra semantics beyond what the schema provides (e.g., format or examples). 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 retrieves analyst ratings consensus with specific outputs: average target price, analyst count, buy/hold/sell breakdown, and consensus recommendation. This verb+resource combination is distinct from sibling tools like get_analyst_coverage or get_analyst_estimates.
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?
Explicit use case is given: 'Use when evaluating Wall Street sentiment or price targets.' While it does not provide negative guidance or alternative tools, the single-line guidance is sufficient for this simple function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds valuable behavioral context: files can be very large (1MB+), maxLength truncation behavior, and response includes a 'truncated' boolean. No contradiction with annotations.
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?
Three sentences with front-loaded key purpose, followed by size warning and parameter usage. Every sentence provides necessary information without redundancy.
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?
With a detailed output schema mentioned (and likely containing the listed fields), the description covers all needed context: how to get the ID, size behavior, truncation, and response contents. Adequate for a two-parameter 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?
Schema description coverage is 100%, so baseline is 3. The description does not add new input parameter details beyond what the schema already provides (e.g., filingId and maxLength descriptions are identical). The mention of response fields (company_name, etc.) is output-related, not parameter semantics.
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?
Clearly states verb (Get), resource (full raw text/HTML content of an SEC filing), and identifier (internal filing ID). Distinguishes from siblings like get_filing_exhibits and search_sec_filings by specifying it returns the complete document.
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?
Explicitly instructs to find filing IDs using search_sec_filings first, and suggests using maxLength for previews. Provides clear context but does not explicitly state when not to use this tool (e.g., for exhibits).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the readOnlyHint annotation by specifying the exact data fields returned. No destructive behavior is implied, and no contradictions exist.
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 wasted words. It front-loads purpose and includes usage guidance efficiently.
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?
Given low complexity (1 param, no nested objects, output schema exists), the description fully covers what the tool does and when to use it.
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 a clear description for the ticker parameter. The description does not add additional meaning beyond the schema, 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 clearly states the verb (Get), resource (float and share structure data), and lists specific data points (shares outstanding, public float, insider ownership %, institutional ownership). It distinguishes from siblings like get_ownership and get_insider_transactions by focusing on float-specific data.
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 explicitly says 'Use when analyzing share supply and ownership concentration,' providing clear context. It doesn't mention when not to use or suggest alternatives among siblings, but given the specific purpose, it's adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds that it returns holdings from the latest 13F filing with shares, value, and weight, plus pagination support, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the main action first and no extraneous words. Every sentence serves a purpose.
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?
Given the presence of an output schema (though not shown), the description adequately explains the return content and pagination. Parameters are well-documented in the schema, so no gaps.
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 baseline is 3. The description mentions 'by CIK' and 'pagination' but does not add significant extra meaning beyond what the schema already provides for each 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 specifies the verb 'Get' and the resource 'full portfolio holdings for a specific institution by CIK', clearly distinguishing it from sibling tools like 'get_institution_activity' or 'get_institution_filings'.
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 states to use a CIK and mentions pagination support, but does not explicitly compare with alternatives or provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description does not need to restate that. The description adds value by listing the specific output metrics, but does not mention any constraints like snapshot nature or rate limits.
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, each serving a clear purpose: first describes functionality, second suggests usage. No fluff, front-loaded.
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?
With one enum parameter, readOnlyHint annotation, and an output schema, the description is complete enough for effective agent use.
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 description's repetition of enum values and default adds minimal 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 specifies the exact metrics (advance/decline, % above moving averages, 52-week highs/lows) and the universe options (sp500, ndx, all), clearly distinguishing it from broader market tools like get_market_metrics.
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 explicitly states a use case ('add market-state context to commentary, tweets, or daily summaries'), but does not mention when not to use it or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is highly transparent beyond the readOnlyHint annotation. It explains that matches are sector-level co-occurrence, the meaning of daysDelta, matchBasis (only 'sector'), and matchCount as a noise indicator. It also warns about chance matches and clarifies that executive-branch slugs return real data.
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 well-structured but somewhat verbose. It front-loads the key purpose, then details, contrast, and warnings. Every sentence adds value, but some redundancy could be trimmed (e.g., repeating 'sector matches are broad'). Still, it remains clear and informative.
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 complexity of the tool and the presence of an output schema, the description covers all essential aspects: what it does, how it works, defaults, limitations, and important caveats. It does not need to explain return values. One minor gap: it might clarify that the output includes a summary field, but that 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 the baseline is 3. The description adds useful context like default window (14 days) and default direction ('before'), but does not provide significant additional semantics beyond what the schema already specifies for each 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 lists trades for a single politician within a window around an executive order signing. It distinguishes itself from get_donor_trade_overlap by noting that executive-branch slugs return real data here. The verb 'list' and resource 'policy-trade overlap' are specific.
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 defaults (trades 1-14 days before signing), excludes same-day trades, and includes a strong caveat that sector matches are broad and not evidence of foreknowledge. It contrasts with get_donor_trade_overlap but does not explicitly compare to other sibling tools like get_policy_trade_leaderboard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation, such as aggregation details, trailing window, and output fields. It is consistent with the annotation and discloses no destructive 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 concise, using three sentences to convey purpose, output, and usage. It is front-loaded with the core function and avoids redundancy.
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?
With an output schema present, the description adequately covers the tool's behavior, parameters, and usage context. No critical information is missing.
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 100% description coverage for all 4 parameters, including defaults and constraints. The tool description adds minimal additional meaning beyond the schema, so a 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 that it returns which market sectors politicians have been trading in over a trailing window, aggregating congressional and executive trades by sector with specific metrics. It distinguishes itself from sibling politician tools by its sector-level aggregation focus.
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 usage example ('politicians piled into Energy this month') and mentions sorting options. It implies when to use this tool (to see sector concentration) but does not explicitly state when not to use it or name alternatives, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions it returns a paginated list and details the fields (name, amount, type, employer/occupation, committee details). However, this adds minimal value beyond the output schema (which exists) and annotations (readOnlyHint=true). No additional behavioral traits like rate limits or side effects are disclosed.
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?
Three sentences: purpose and returned fields, usage trigger, and link to alternative. No redundant information. Highly efficient and front-loaded with key information.
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?
Given the tool has 8 parameters, an output schema, and annotations, the description sufficiently explains purpose, usage, and alternatives. It does not need to elaborate on return values since an output schema exists. Complete for the complexity.
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 parameters are already described in the input schema (100% coverage). The description does not add any parameter-specific guidance or usage examples beyond what the schema provides. 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 verb 'Get' and the resource 'paginated list of campaign donors' for a single politician across one election cycle. It distinguishes itself from the sibling tool 'get_politician_donor_summary' by specifying that it returns the full donor list, not just a summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when a user asks "who donated to <politician>" or wants the full donor list.' Also provides an alternative: 'For a quick top-10 + cycle totals overview, use get_politician_donor_summary instead.' This gives clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description describes a read-only operation (listing/searching). It goes beyond annotations by specifying return fields (trade counts, last trade date, net buy/sell direction) and pagination behavior, providing useful behavioral context without contradiction.
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, front-loaded with the main purpose, followed by specific details. No redundant or extraneous information. Every word serves a purpose.
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?
With 7 optional parameters (all documented), an output schema present, and readOnlyHint annotation, the description is complete. It covers the core functionality, filters, pagination, and return fields, providing all necessary context for an agent to use this tool 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?
Schema coverage is 100%, so the baseline is 3. The description adds value by grouping parameters semantically ('Filter by party, state, or search by name') and listing key return fields, which helps the agent understand the tool's purpose beyond individual parameter descriptions.
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 identifies the verb ('List and search'), resource ('congressional politicians who have STOCK Act trading disclosures'), and scope (filters, return fields). It distinguishes from siblings like get_politician_detail or get_politician_activity by specifying the core functionality of listing/searching multiple politicians with trading 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 retrieving a filtered list of politicians with trading disclosures but does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to use get_politician_detail for a single politician's details). No when-not or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, so the description's burden is reduced. It adds value by specifying what the output includes (votes, bill info, position, result). No contradictions; the description aligns with the read-only nature.
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 zero waste. The first sentence front-loads the primary purpose, and the second adds a use case and key prerequisite. Every sentence 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?
Given the presence of an output schema and full parameter schema, the description adequately supplements with the return type (votes with bill info, position, result) and a prerequisite. For a simple read-only query tool, this is complete.
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%, and parameter descriptions in the schema are already clear (slug example, limit/offset with defaults and max). The description adds no additional semantics beyond restating 'by slug', so 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 'voting records for a politician by slug' and specifies it returns 'congressional votes with bill info, position, and result'. This distinctively separates it from sibling tools like get_politician_activity or get_recent_congressional_votes.
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 use case ('assessing alignment between votes and trading positions') and a prerequisite ('requires Bioguide ID resolution'). While it does not explicitly list when not to use or name alternative tools, the context of siblings like get_recent_congressional_votes gives some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds value by listing the returned fields (preEarningsClose, currentPrice, changePct, surprise data) and mentions the computation is pre-computed, setting expectations for a single-call retrieval without side effects.
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, comprising three sentences that front-load the core purpose and quickly provide functional details. Every sentence adds value without 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?
Given the presence of an output schema, the description adequately covers the tool's functionality. It explains the input parameters, the data returned, and the benefit over alternatives, making it complete for agent decision-making.
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 descriptions for all three parameters. The description reiterates the minChangePct filter and default values but adds little new meaning beyond the schema. The listing of return fields does not directly enhance parameter understanding.
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 stocks that moved significantly after earnings on a given date, specifying the verb 'get' and resource 'post-earnings movers'. It distinguishes from chaining multiple calls, providing a clear use case.
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 explains when to use this tool (to avoid chaining get_earnings_calendar, get_historical_prices, and get_quote) and implies alternatives but does not explicitly state when not to use it. The guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds valuable detail about halted ticker behavior: returns last-known quote or currentPrice:null+halted:true, and includes halted/haltCode fields. This goes beyond annotations.
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, front-loaded with purpose and fields. No extraneous words. Every sentence adds value.
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?
Given the presence of an output schema (not shown but indicated), the description adequately covers behavior and edge cases. The tool is simple with one parameter, and the description fully sets expectations.
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?
With 100% schema description coverage, the schema already documents the ticker parameter clearly. The description does not add additional meaning beyond what the schema provides, so 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 clearly states the tool gets the current stock quote including price, volume, change, market cap. It distinguishes usage for current price/trading activity. However, it does not explicitly differentiate from many sibling data tools, but the mention of 'real-time market data' and specific fields helps.
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?
Provides explicit guidance: 'Use this when a user asks about a stock's current price or trading activity.' It does not mention when not to use or alternatives, but the given context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the readOnlyHint annotation by explaining that politicianSlug is null for ex-members. It also details the sponsor block structure. This provides useful behavioral insight without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence clearly states the purpose, and the second adds key structural and requirement details. Every sentence earns its place with no redundant information.
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?
Given the tool has 3 optional parameters, full schema descriptions, an output schema, and low complexity, the description covers all necessary context: purpose, data structure (sponsor block), a special case (null slug), and authentication. No gaps for this simple list endpoint.
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 input schema has 100% description coverage, so the description is not required to repeat parameter details. However, it adds meaning by explaining the output structure related to parameters (e.g., the sponsor block details) and the null case for politicianSlug.
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 recently introduced bills across all congressional sponsors, with a specific verb and resource. It distinguishes itself from sibling tools by focusing on bills rather than legislators or votes, and the title adds 'cross-politician' to indicate aggregation.
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 the requirement for CONGRESS_API_KEY, which is useful, but it does not provide guidance on when to use this tool versus alternatives like get_politician_recent_trades or get_recent_congressional_votes. No explicit when-not or alternative scenarios are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds the time range (last 7 days) and default item filtering. No mention of rate limits or auth, but adequate given annotations.
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, front-loaded with purpose, efficient. No redundant information.
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?
With an output schema present, no need to describe returns. The description covers time range, default filtering, universe choice, and optional parameters. Complete for a filtered-list 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?
Schema coverage is 100%. The description adds meaning by explaining default behavior for items (high-signal codes) and the role of universe. It goes beyond the basic schema descriptions.
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 it returns recent material 8-K filings for index constituents, with default high-signal items and optional filtering. It distinguishes from siblings by specifying 'recent material 8-K filings' and 'index universe'.
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 explicitly tells when to use the tool (for recent material filings) and how to filter by items and universe. It does not explicitly state when not to use it or list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description adds value by specifying it returns 'recent STOCK Act disclosures' and the exact fields (politician info, transaction type, amount). No contradictions with annotations.
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 concise sentences with the key action ('Reverse lookup') front-loaded. Every word serves a purpose, no redundancy.
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?
Given the presence of an output schema and complete parameter documentation, the description effectively conveys the tool's function and return fields. It is sufficiently complete for an agent to understand usage.
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% for all three parameters, so the description's lack of additional parameter detail is justified. The description focuses on tool purpose rather than parameter syntax, which is appropriate at baseline.
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 verb 'find' and resource 'politicians recently traded a given TICKER'. It also specifies the output includes 'politician info, transaction type, and amount', making it distinct from sibling tools like get_politician_recent_trades which focus on politician-centric queries.
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 phrase 'Reverse lookup' signals the tool is for finding politicians from a ticker, contrasting with other tools. While it doesn't explicitly mention when not to use it, the context of sibling tools implies it's the go-to for ticker-based trade discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, consistent with description. Description adds behavioral context about return values (Point of Control, Value Area) but no additional traits beyond what annotations provide.
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 wasted words. Front-loaded with purpose and immediate use case. Excellent structure.
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?
Complete for a simple read-only tool with output schema and good annotations. No gaps.
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%, but description adds meaning by explaining output concepts (price buckets, Point of Control, Value Area) that are not in schema. This helps agent understand what the tool returns.
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?
Description clearly states it gets volume distribution across price levels for a single trading day, specifying outputs like price buckets, Point of Control, and Value Area. This distinguishes it from sibling tools like get_historical_prices or get_intraday_bars.
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?
Explicitly states use case for identifying support/resistance and high-volume price nodes. Does not mention when not to use or alternatives, but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds that the tool returns both individual filing records with pre-computed price returns and aggregate statistics. This goes beyond the annotation by detailing the output structure, without any contradiction.
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 with three sentences, each serving a distinct purpose: stating the function, listing filters, and providing examples. It is front-loaded and contains no unnecessary words.
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?
Despite having an output schema (as per context signals), the description covers all essential aspects: purpose, filters, and example usage. It is complete for a tool with 12 optional parameters and no required inputs.
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 baseline is 3. The description mentions company-level and filing filters but does not add significant meaning beyond what the schema already provides for each parameter. The examples illustrate usage but do not redefine parameter semantics.
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 analyzes stock price performance after SEC filings with specific return periods (+1, +3, +7, +30 days) and aggregate statistics. It distinguishes from sibling tools like screen_sec_filings by focusing on performance rather than just listing filings.
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 explicit example questions (e.g., 'how do biotech stocks perform after S-1 filings?') and explains how to combine company and filing filters. However, it does not explicitly state when not to use this tool or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is safe. The description adds that results are 'ranked by AUM descending,' which is a behavioral trait not in annotations. It does not cover pagination or rate limits, but these are partially addressed by the parameter schema (limit, offset). Overall, it adds value beyond annotations.
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. It starts with the core action and lists return fields, then provides usage guidance and an example. Every sentence serves a purpose, and the structure is front-loaded.
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?
Given that the output schema exists (documenting return values) and the parameter schema is fully described, this description completes the picture by explaining when to use the tool, what it returns, and how results are ordered. No gaps remain.
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 reinforces the search term examples and purpose but does not add significant new meaning beyond the schema. It is adequate but not exceptional.
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 the tool searches institutional investors by name, explicitly mentions the returned fields (CIK, name, AUM, holdings count, latest filing period), and distinguishes it from sibling tools like 'get_institution_*' which require a specific identifier. The verb 'search' and resource 'institutional investors (13F filers)' are precise.
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: 'Use this to find a specific fund or investment manager when you know part of their name' with examples. It does not explicitly state when NOT to use it, but the context strongly implies that for known identifiers, the 'get_institution_*' tools are alternatives. The guidance is sufficient but lacks explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint=true annotation, stating it returns detailed information without suggesting side effects. It adds context about the specific data returned (name, AUM, holdings, filing history), which is helpful beyond the annotation. No contradictions, and the behavioral profile is complete for a read-only detail lookup.
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 only two sentences: one covering purpose and returns, one covering usage guidance. No redundant or extraneous content. Every sentence serves a clear function, making it highly efficient and well-structured.
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 (1 parameter, no nested objects, output schema exists), the description adequately covers the retrieval purpose. It mentions the return fields. It could optionally note that invalid CIKs may raise errors, but this is not critical for a well-defined schema. Overall, it is complete enough for a detail lookup 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 schema provides 100% coverage for the single parameter 'cik' with a description. The tool description adds value by giving an example ('0001067983' for Berkshire Hathaway) and explaining the parameter's purpose in context, which aids correct invocation.
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 specifies the action ('get detailed information') and the resource ('a specific institutional investor by their SEC CIK number'). It lists the returned fields (name, total AUM, number of holdings, filing history), distinguishing it from sibling tools like get_institutions or get_institution_activity by focusing on detail retrieval via CIK.
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 explicitly directs users to 'Use get_institutions first to find the CIK for an institution,' providing a clear prerequisite and alternative tool. This helps agents select the appropriate tool in a workflow. Slightly downscored because it does not explicitly state when NOT to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as read-only. Description adds behavioral details: server-side SQL computation, sorting, and return categories. Missing explanation of changePercent but output schema covers return format.
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?
Three sentences efficiently convey purpose, behavior, and efficiency. Front-loaded with core action, no wasted words. Each sentence 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 output schema exists, description covers key aspects: comparison method, sorting, efficiency. However, lacks explanation of changePercent computation. Adequate for the tool's complexity.
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 baseline 3. Description does not add significant meaning beyond schema for parameters like cik, limit, offset, only providing an example for cik.
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 it diffs two quarterly 13F snapshots and returns position changes, using specific verbs like 'diff' and 'compares'. It distinguishes itself from sibling tool get_institution_holdings by highlighting efficiency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (need position changes) and when not to (avoid manual diffing). Provides efficiency justification and mentions sorting by changePercent descending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with non-destructive search. Description adds behavior: substring match, case-insensitive, minimum 2 characters (from schema), and returns snippets with context. Does not mention rate limits or pagination, but output schema exists.
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?
Three sentences covering action, output, and filtering options. Front-loaded with main purpose. No wasted 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?
Covers essential aspects: what it searches, what it returns, filtering options, and typical use cases. Missing pagination or default limit, but schema covers limit parameter and output schema exists. Sufficient for a search 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?
Schema description coverage is 100%, so parameters are technically documented. Description adds usage context: examples of search terms, mention of filtering by company/filing/form type, and what snippet length does. Adds value beyond 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?
Clearly states full-text substring search across SEC filing exhibit content, distinguishing it from siblings like get_exhibit_content (full exhibit retrieval) and search_sec_filings (metadata search). Examples of specific clauses reinforce purpose.
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?
Provides examples of when to use (finding specific clauses) and mentions optional filters (CIK, form type, etc.), implying when to narrow searches. Does not explicitly contrast with all siblings but context signals and sibling names help differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the readOnlyHint annotation: results are sorted by urgency (lowest runway first), the runway is an estimate subject to future changes, and default window is today to 90 days. No contradictions with annotations exist.
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 four sentences with no redundant information. It is front-loaded with the main purpose, followed by key distinguishing features and caveats. Every sentence 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?
Given the tool's moderate complexity (5 parameters, output schema present, many siblings), the description fully covers the purpose, behavior, and important caveats. The existence of an output schema means the return value structure does not need explanation in the description.
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 input schema already documents all parameters. The description adds marginal value by mentioning the default window (today to 90 days) but does not elaborate on each parameter's meaning or provide additional context beyond what the schema already offers. 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 explicitly states the tool finds companies projected to run out of cash within a date window, with a clear verb ('find') and resource ('cash depletion events'). It distinguishes itself from sibling tools by noting similarity to lockup expiration calendars but for cash depletion, providing unique identity.
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 on when to use the tool (companies running out of cash) and includes important caveats about the estimate's dependence on future events. However, it does not explicitly state when not to use it or name alternatives among the extensive sibling list, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, and the description aligns with this by describing a data retrieval operation. The description adds valuable context about the output structure (total raised, top donors, splits, leaderboard) beyond what annotations provide. It does not contradict annotations.
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 three sentences, front-loading the core purpose, then providing usage examples and sibling differentiation. No extraneous words; every sentence adds value.
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?
The tool has an output schema, so return values are covered. All three parameters are optional with descriptions. The description covers the expected use cases and output components sufficiently for a market-wide rollup 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?
Schema description coverage is 100% with all parameters described. The description does not add additional meaning beyond the schema, such as parameter constraints or defaults (though cycle default is mentioned in schema). Given high 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 clearly states the tool's purpose: 'Get market-wide campaign-finance rollups across ALL tracked politicians for a cycle.' It lists specific data points (total raised, top donors, etc.) and distinguishes from sibling tools by explicitly naming 'get_politician_donor_summary' for single-politician queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with example questions ('who are the biggest donors in 2024?' or 'which party raised more?') and tells when not to use the tool ('For a single politician, use get_politician_donor_summary'). This helps the agent select appropriately among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, indicating a safe read operation. The description adds meaningful behavioral context: return fields (ticker, date, time, estimates with 'when available' caveat) and market cap filtering options. No destructive behaviors are relevant, and the description is consistent with annotations.
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 concise sentences: first states the primary function and input, second details output and optional filters. No filler, front-loaded with essential information. Every sentence is earned.
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?
Given the tool's complexity (5 params, 2 required, output schema exists), the description covers input (date range, tickers, market cap), output fields, and the 'when available' qualifier. It addresses the main use cases without missing critical context. The presence of an output schema reduces the burden, but the description still explains what is returned.
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% with descriptions on all 5 parameters. The description adds value by summarizing the filtering intent ('market cap filtering to focus on large-cap or small-cap earnings only') and explaining the overall workflow (date range, optional tickers, market cap). This goes beyond redundant repetition.
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'), resource ('earnings calendar'), and scope ('between two dates'). It clearly distinguishes from siblings by focusing on earnings releases with date range, ticker filter, and market cap filtering. The return fields are listed (ticker, date, time, EPS estimate, revenue estimate).
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 usage context (upcoming and recent earnings, optional filters) but does not explicitly state when to use this tool over alternatives like get_earnings or get_post_earnings_movers. However, the detail is sufficient for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds caching behavior ('cached independently') and mentions the combination of multiple sources. Annotations already indicate readOnlyHint, so the description adds value without contradiction.
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, front-loaded with main purpose, then supporting details. No wasted words.
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?
Covers all essential aspects: purpose, data types, caching, defaults. Output schema exists, so return details are adequately handled.
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%, but description adds default values for 'include' parameter (profile,stock-summary,holdings,sectors) and lists available types, supplementing 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?
Description clearly states it retrieves aggregated ETF data in one call, listing the combined data sources. This distinguishes it from individual sibling tools like get_company_profile or get_news.
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?
Provides clear context: use for aggregated data, defaults, and optional types. Implicitly suggests alternatives (individual tools for single data types) but lacks explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate readOnlyHint=true, and the description confirms a read operation by stating it returns content. The description adds context about truncation behavior and return fields. No contradictions; minor improvement could mention response format or rate limits.
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 with no fluff. The first sentence states purpose and returned fields, the second provides usage direction for the parameter and prerequisite. Every sentence 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?
Given the presence of an output schema (reducing the need to describe return values), the description is complete. It covers purpose, usage, parameters, and prerequisite. No gaps for a read-only data retrieval 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?
Schema coverage is 100%. The description adds semantic value by explaining the maxLength parameter's effect (truncation and truncated boolean) and instructing users to find exhibit IDs via get_filing_exhibits, which is helpful 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 purpose: getting the full text/HTML content of a single SEC filing exhibit. It specifies the exact fields returned, distinguishing it from sibling tools like get_filing_exhibits and get_filing_document.
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 explicit usage guidance: it tells users to first find exhibit IDs using get_filing_exhibits and explains how to use the maxLength parameter to truncate large exhibits. While it doesn't explicitly exclude alternative tools, the use case is well defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds exclusion detail and metadata return, providing useful behavioral context beyond basic safety.
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?
Three sentences, front-loaded with purpose, no redundancy. Every sentence adds value.
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?
Output schema exists, so return values need not be fully described. However, description still mentions key metadata fields. Combined with annotations and schema, complete for the tool's complexity.
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?
Only one parameter with full schema description. Description does not add extra meaning beyond schema. Baseline 3 as schema coverage is 100%.
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?
Clear verb 'List' and resource 'exhibits within an SEC filing'. Distinguishes from sibling get_exhibit_content by stating it returns metadata, not content. Explicitly mentions return fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use to identify exhibits for reading with get_exhibit_content. Also notes exclusion of XML/XBRL exhibits, setting boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the dual-mode behavior (issuer vs insider) and the fallback logic, complementing the readOnlyHint annotation. It adds value beyond the annotation by explaining the lookupMode field and derivation from Form 4.
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 (5 sentences) and front-loaded with the main purpose. Each sentence adds meaningful information without redundancy.
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?
Given the tool's simplicity (1 parameter, output schema present, readOnlyHint annotation), the description covers all necessary aspects: behavior, parameter usage, return field, and data source.
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?
With 100% schema coverage, the schema already describes the CIK parameter thoroughly. The description adds further context on the dual interpretation and fallback, providing added value.
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 verb 'Get' and the resource 'current open insider positions' for a CIK. It explicitly distinguishes between issuer and insider CIK modes, which differentiates it from sibling tools like get_insider_transactions.
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 on when to use the tool (e.g., when you have a CIK and need open positions, with dual interpretation based on CIK type). However, it does not explicitly mention when not to use it or point to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true; description adds value by specifying the two leaderboard sections, name-deduping, and volume details, giving behavioral context beyond annotations.
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 wasted words, front-loads key purpose and alternatives, earning every character.
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?
With output schema present, description completes the picture by summarizing return content (two sections) and noting pagination alternative; no gaps for this simple 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?
Schema coverage is 100% with one parameter (limit) fully described in schema; description does not add new semantics beyond what schema provides, 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?
Description clearly states the tool returns two market-wide institution leaderboards (topByAum and mostActive) in one call, with explicit details on what each contains, distinguishing it from siblings like get_institution_top_aum.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'No CIK required' and directs users to get_institution_top_aum for a full paginated AUM list, providing clear when-to-use and 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds valuable behavioral details beyond the readOnlyHint annotation: pagination via limit/offset, default limit of 100, and that aggregate stats are always included. No contradictions.
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 concise sentences with front-loaded purpose and efficient detail on pagination and stats. No wasted words.
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?
Given the presence of an output schema, the description appropriately covers purpose, pagination, and aggregate stats. It is complete for a 3-parameter read-only 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?
Schema coverage is 100%, so each parameter is already described. The description reinforces pagination defaults but does not add new meaning beyond what's in 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?
Description clearly states the tool provides a unified ownership breakdown combining Form 4, 13F, and 13D/13G filings, distinguishing it from sibling tools that focus on individual ownership types (e.g., get_insider_positions, get_institution_holdings).
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 use for comprehensive ownership needs but does not explicitly compare to alternatives or state when not to use. The context is clear enough for an agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is already set, so the description's role is lower. It adds value by detailing the bundled nature and specific data returned (cycle totals, top donors), providing useful behavioral context without contradictions.
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 core purpose, and contains no fluff. Every sentence adds value.
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?
Given the low complexity (2 parameters, 1 required, output schema present), the description fully covers what the tool does and how to use it. No gaps.
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% and both parameters are described in the schema. The description does not add new semantic information beyond what the schema already provides (e.g., default cycle behavior is already in 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 tool returns a 'bundled donor summary for a single politician' including specific fields (cycle totals, donor count, top donors). It also explicitly distinguishes this from the sibling tool get_politician_donors, which handles paginated lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context with example questions ('who funds <politician>', 'biggest donors to <politician>') and tells when to use the alternative sibling tool for a full paginated list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description adds value by specifying the exact output (committee leadership roles). No contradictions; no additional behavioral context needed beyond what annotations supply.
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 concise sentences, front-loaded with the action, no extraneous information. Every word contributes to clarity.
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?
Given the low complexity (1 param, output schema present, annotations provided), the description fully covers the tool's purpose and usage. No gaps remain.
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% and already describes the slug parameter. The description adds context by explaining the slug's purpose ('find the slug') and links it to the prerequisite tool, enhancing semantic understanding.
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?
Description clearly states the verb 'Get' and resource 'committee leadership roles for a politician', distinguishing it from sibling tools that handle other politician data (e.g., get_politician_activity, get_politician_detail).
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?
Explicitly instructs to 'Use get_politicians first to find the slug', providing a clear prerequisite step. While it doesn't mention when not to use or list alternatives, the guidance is sufficient for the simple use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond the readOnlyHint annotation by specifying it returns percentage changes across multiple timeframes. No contradictions.
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 with zero waste: first sentence defines the action and scope, second provides usage guidance. Front-loaded and efficient.
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?
Given simple input (one required param) and existing output schema, description fully covers purpose, usage, and behavior. No gaps.
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?
Only parameter 'ticker' has 100% schema coverage, and description repeats the schema's example. No additional meaning added beyond 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?
Description clearly states the verb 'get', resource 'percentage price changes', and lists all supported timeframes (1D through MAX). Distinguishes from sibling tools like get_historical_prices by focusing on percentage change rather than raw candle data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use ('quick how much is it up/down answers') and when not to ('without fetching full candle data'), implying alternative tools for full data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds behavioral context beyond that: default penny-stock filtering with specific thresholds, session window constraints, and the optional includePennyStocks parameter behavior. No contradiction with annotations.
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 three concise sentences, front-loaded with the core purpose, and covers all necessary details without redundancy. Every sentence adds value.
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?
Given the tool has an output schema (implied true), the description is complete: it explains all parameters, default behaviors, and constraints (session not supported for active, penny-stock filtering). No gaps for a read-only data retrieval 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?
Schema coverage is 100%, baseline 3. The description adds valuable context: for 'session' it provides ET time ranges, for 'includePennyStocks' it explains the default filter and what true/false mean, and for 'direction' it clarifies the types. This enhances understanding 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 provides top stock movers by gainers, losers, or active (volume), with specific session support. It distinctly differentiates from sibling tools like get_market_breadth or get_accumulation_snapshot.
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 explains when to use each direction and session, and explicitly states that 'active' does not support session windows, and that penny-stock filtering is applied by default. It provides clear context for usage, though it does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is safe. The description goes beyond by explaining the default threshold (6 months), sorting behavior (by urgency), and the estimation basis (current burn rate). No contradictions with annotations.
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 cover purpose and use cases with zero wasted words. The critical information (defaults, use cases) is front-loaded in the first sentence.
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?
Given the presence of annotations, output schema, and 100% schema coverage, the description is complete. It explains the tool's purpose, default behavior, sorting, and use cases, leaving no gaps for effective invocation.
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?
All 4 parameters have descriptions in the schema, but the description adds value by specifying defaults (maxMonths=6, limit=25) and the sorting logic. This enhances agent understanding 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 ('Find') and resource ('companies with imminent capital raise needs') and clearly explains the screening criteria (cash runway <6 months, sorted by urgency). It distinguishes itself from sibling tools like 'screen_companies' by specifying a concrete financial metric and use case.
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 ('identifying distressed companies, imminent dilution situations, or potential financing catalysts') but does not explicitly state when not to use it or list alternative tools. A clear usage context is provided, but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. Description adds context about enriched output (ticker, sector, etc.) and mentions combining filters, but doesn't detail pagination or rate limits, which are acceptable for a read 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?
Three sentences with high information density: first defines functionality, second gives examples, third provides sibling guidance. No wasted words.
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?
Given the tool has 12 well-described parameters, output schema, and annotations, the description covers high-level purpose, use cases, and differentiation. Nothing significant is missing.
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 baseline is 3. The description does not add extra detail beyond what the schema provides for each 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 screens SEC filings with combined company and filing filters, and provides concrete examples of questions it answers. It also distinguishes from search_sec_filings by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to use this for broad screening and search_sec_filings when CIK is known. Includes example queries to clarify use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it returns paginated results with metadata, which aligns with the readOnlyHint annotation. No contradictions. It adds value by explaining the paginated nature and the metadata fields, though it doesn't detail other behavioral aspects like rate limits.
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: first states purpose and filters, second explains usage flow. Every sentence serves a clear function, no fluff. Front-loaded with the most important information.
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?
Given 6 fully described parameters, an output schema, and readOnlyHint annotation, the description covers the essential flow: search, filter, paginate, then read with other tools. No significant gaps.
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 description does not need to add much. It mentions CIK, form type, and date range, which mirror schema descriptions. No additional meaning beyond what's in the schema, 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 clearly states the tool searches and lists SEC filings with specific filters (CIK, form type, date range). It distinguishes from sibling tools like get_filing_document and get_filing_exhibits by noting the use case of finding filings before reading content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool: 'Use this to find filings before reading their content with get_filing_document or get_filing_exhibits.' This provides clear context and names alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by detailing behavioral traits: EMPTY calendar is normal (not an error), affectedTickers are verified, vote windows are predictions with provenance, and sponsor trade facts are restatements not evidence of wrongdoing. This provides comprehensive behavioral context.
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 thorough but efficiently structured, front-loading the main purpose. While slightly lengthy, every sentence adds necessary context for a complex tool, making it justified.
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?
Given the complexity and presence of an output schema, the description covers all essential aspects: return item structure, default parameters, behavior when empty, and data quality notes. It is fully complete for agent understanding.
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 description coverage is 100%, so baseline is 3. The description adds value by explaining the minRelevance enum in detail, especially the 'none' option, and by restating defaults and important notes, enhancing parameter understanding.
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 it is a 'Forward-looking legislative catalyst calendar' listing upcoming House/Senate floor votes filtered to items that can move tickers, distinguishing it from sibling calendar tools like get_economic_calendar and get_earnings_calendar.
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 defaults (from=today, to=+14 days, minRelevance=low) and explains that an empty calendar is normal, giving clear context for use. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond readOnlyHint annotation by disclosing that matches are sector-level co-occurrence, broad, and many by chance. It explains matchBasis and matchCount fields, adding critical behavioral context not captured in annotations.
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 somewhat lengthy but well-structured and front-loaded. Every sentence adds value, though slight trimming could improve conciseness without losing content.
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?
Given complexity of sector-level matching, the description thoroughly explains return fields, match interpretation, and limitations. With an output schema present, it completes the picture by detailing what each field represents and how to interpret results.
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%, but description adds context like default window (14 days) and direction (before), and explains the relationship with get_policy_trade_overlap's lens. It provides meaning beyond what the schema alone offers.
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 it ranks politicians by trades near executive-order signings, specifying the verb 'rank', resource 'politicians', and context. It distinguishes from sibling get_policy_trade_overlap by noting same lens but different aggregation.
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 explicitly says 'Use for "who trades most around policy activity" style questions.' It provides defaults and explains the sector-level co-occurrence. It references the sibling tool get_policy_trade_overlap but lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description correctly adds behavioral details: deduping by period with annual preference over quarterly, chronological sorting, and returns array of objects. No contradictions with annotations.
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, both dense with information. The first sentence covers purpose, source, time range, and output format. The second adds dedup logic and availability. No unnecessary words.
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?
Given the output schema exists, the description adequately explains the return structure and behavior. It covers the 10-year quarterly range, dedup, sorting, and that it works broadly. No gaps.
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 single required parameter 'ticker' has 100% schema description coverage. The description adds value by explaining the tool 'works for any company with SEC filings', which expands on the parameter's 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 retrieves quarterly cash position history from SEC XBRL filings, specifying the 10-year limit and listing the output fields. It distinguishes itself from siblings by emphasizing it works for any company with SEC filings, not feature-gated.
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 explicitly states the tool is for up to 10 years of cash history, implying it should be used when this specific historical data is needed. It does not explicitly mention when not to use it or provide alternatives, but the clarity on scope is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, making its non-destructive nature clear. The description adds what data is returned but does not mention pagination, rate limits, or empty result behavior. Still, given annotations, it's sufficiently 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?
Two sentences convey all necessary information without redundancy. Front-loaded with action and data details, no wasted words.
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 read tool with one parameter and an existing output schema, the description covers purpose, prerequisite, and data content. No gaps identified.
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%, and the description adds value by explaining the parameter's format (e.g., 'sen-nancy-pelosi') and the prerequisite step (get_politicians). This goes beyond the schema's minimal description.
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 purpose: 'Get committee assignments for a politician' with specific details on the data returned (committee name, chamber, role, subcommittee). It distinguishes itself from sibling tools like get_politician_detail and get_politician_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use get_politicians first to obtain the slug, and suggests a use case: 'Use to correlate trading activity with committee oversight areas.' This provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so safety is covered. The description adds detail on returned fields, which annotations do not. It does not mention potential errors or pagination, but output schema likely covers return structure.
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, front-loaded with purpose, no fluff. Efficient and clear.
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 retrieval tool with one parameter and output schema, the description is complete. It covers purpose, prerequisite, and return content.
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 covers slug with 100% description. The description adds a concrete example and explains slug source, which aids selection 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 it retrieves a full politician profile with specific fields (party, state, chamber, etc.), distinguishing it from siblings like get_politician_activity. It also instructs to use get_politicians first, indicating prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using get_politicians first to obtain the slug, providing clear usage context. While alternatives are not listed, the sibling tools imply them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds context: source (Nasdaq Trader feed), return fields, and the fact that an empty list is not an error. No contradictions. For a read-only tool with no params, this is fully 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?
Three sentences: scope, output details, and usage hints. No filler, front-loaded with the main action. Every sentence 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?
Despite no parameters, the description covers all necessary behavioral context: source, fields, normal empty response, and a practical use case. With an output schema available, the description is complete.
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?
No parameters exist, so schema coverage is trivially 100%. The description doesn't need to explain params; it adds value by describing the output fields and behavior, exceeding the baseline for high 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 it lists active trading halts across NASDAQ/NYSE/AMEX, specifies the feed source, and lists key fields. It distinguishes from sibling tools like get_quote by framing halts as catalysts and suggesting a follow-up action.
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?
Explicitly describes the use case (discover halted names) and suggests get_quote as a next step. Clarifies that an empty list is normal. Lacks explicit when-not-to-use or alternatives, but the guidance 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses two possible return states (full metadata vs basic with isInDatabase flag) and format flexibility. Consistent with readOnlyHint annotation, no contradictions.
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?
Efficient three-sentence description with clear front-loading of purpose, followed by format and behavior details. No redundant text.
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?
Adequately covers input, output behavior, and edge case (not in database) for a simple lookup tool with one parameter.
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 covers parameter fully (100% coverage), but description adds value by providing format examples and clarifying the two accepted formats.
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?
Description clearly states the tool looks up a filing/exhibit by SEC accession number, with examples of formats. Distinguishes from sibling tools that use different identifiers for filing-related operations.
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?
Provides guidance on input format support and expected return behavior (local vs EDGAR), but does not explicitly contrast with alternative tools like search_sec_filings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description accurately describes the read operation with no contradictions, detailing what data is returned (OHLCV candles) and supported parameters.
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 three concise sentences, front-loaded with purpose, then features, then use cases, with no unnecessary information.
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?
The description covers inputs, defaults, and use cases comprehensively; output schema exists so return values are not needed; the tool is fully self-explanatory for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, and the description adds value by explaining period shorthand, default values, and the relationship between from/to and period, surpassing schema content.
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 specifies it retrieves historical OHLCV price candles for a stock, distinguishes from siblings like get_intraday_bars by mentioning daily, weekly, monthly resolutions, and covers multiple use cases.
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 use cases (compute returns, chart history, analyze volume), but does not explicitly state when not to use it or mention alternatives, leaving some reliance on sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![signal8-mcp MCP server](https://glama.ai/mcp/servers/signal8ai/signal8-mcp/badges/card.svg)](https://glama.ai/mcp/servers/signal8ai/signal8-mcp)

Score Badge

Copy to your README.md:

[![signal8-mcp MCP server](https://glama.ai/mcp/servers/signal8ai/signal8-mcp/badges/score.svg)](https://glama.ai/mcp/servers/signal8ai/signal8-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/signal8ai/signal8-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server