Financial Signals MCP

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

No annotations are provided, so the description carries full burden. It discloses payment requirements, retry mechanism on 402, and Authorization header alternative. It does not explicitly state read-only status, but the nature of anomaly detection implies no destructive side effects. This is sufficient context beyond the schema.

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

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

The description is front-loaded with the core purpose, but the payment instructions and retry logic add length. While necessary for usage, they could be more condensed. Approximately 80 words, which is reasonable but not exceptionally concise.

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

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

Given the complexity of payment handling and the presence of an output schema (not shown), the description adequately covers the tool's behavior. It explains the payment flow, free tier, and retry process. No major gaps exist for an API tool of this nature.

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

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

Schema coverage is 100%, with each parameter described in the schema. The description adds minimal extra meaning: it mentions payment_tx in the context of retry, and severity is implied by 'ranked by severity' but not explicitly linked to min_severity. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool detects unusual patterns across all monitored companies, ranked by severity. This specific verb+resource combination distinguishes it from siblings like company_profile or earnings_check, which focus on individual entities or metrics.

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

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

The description provides explicit usage context: to get anomalous patterns. It also details payment handling (free allowance, payment on 402, re-call with payment_tx). While it doesn't explicitly state when not to use it, the payment model implies selective use, and alternatives are listed among siblings.

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

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

No annotations exist, so description carries burden. It discloses that it's a paid tool with specific pricing and free-tier handling, which adds behavioral context. However, it omits other behavioral traits such as read-only nature, data freshness, error handling, or rate limits beyond free allowance.

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

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

Two paragraphs: first clearly states purpose, second covers payment. No unnecessary words. Could be slightly more structured (e.g., bullet points for components), but sufficiently concise.

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

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

Given output schema exists (not shown in prompt but indicated), description covers core functionality, payment, and free allowance. Missing details on error conditions or output format, but output schema compensates. Overall complete for a tool with good schema coverage.

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

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

Schema coverage is 100%, so description adds value beyond schema for agent_id (explains scoping of free counter) and payment_tx (details re-call payment flow). Ticker param is redundant with schema, but overall contribution is positive.

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

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

Description clearly states it provides a comprehensive blended profile for a ticker, listing specific components like ratios, insider activity, institutional ownership, earnings, sector positioning, and a proprietary score. This distinguishes it from sibling tools that are more focused (e.g., insider_activity, earnings_check).

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

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

Provides guidance on when to use ('one call for the full financial-intelligence picture') and includes detailed payment instructions (daily free allowance, payment flow on 402, bypass with Bearer key). However, it does not explicitly mention when to use alternatives or 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.

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

No annotations are provided, so the description carries the full burden. It transparently discloses the paid nature ($0.01 per query after free allowance), the 402 flow with payment_tx, and the data scope (8 quarters, etc.). It does not mention rate limits or error handling beyond 402, but the payment explanation is thorough. Score 4 for good transparency.

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

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

The description is front-loaded with purpose and data details, then payment instructions. It is somewhat lengthy but each part is relevant. It could be slightly more concise, but it maintains clarity. Score 4 for good structure and no wasted sentences.

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

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

The description covers all needed aspects: what the tool returns (explicit data list), how to use it (ticker required, agent_id optional, payment flow), and cost. It has an output schema (not shown) but description already summarizes output. For a tool with 3 parameters and no nested objects, it is complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal value: it reiterates the ticker example, explains agent_id as 'scopes the free-tier counter' (matching schema), and payment_tx context. It adds marginal context beyond the schema. Score 3 as adequate.

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

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

The description clearly states the tool's purpose: checking the earnings track record for a ticker, including specific data points like last 8 quarters of EPS surprises, beat/miss streak, etc. It distinguishes itself from siblings like 'company_profile' or 'screen_stocks' by focusing on earnings data, making the purpose specific and actionable.

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

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

The description does not explicitly compare with sibling tools or provide when-to-use guidance. It implies usage for earnings analysis but lacks exclusions or alternative tool mentions. The payment flow is detailed, but that's operational, not usage context. Score 3 for implied usage but no explicit guidance.

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

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

No annotations provided, so the description carries full burden. It discloses the tool's nature (derived patterns, not raw filings), payment model ($0.01 per query, daily free allowance), and error recovery (402 handling). This is adequate behavioral transparency, though it could mention data freshness or limitations.

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

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

Two paragraphs: first clearly states purpose and signals, second explains payment mechanics. Information density is good, though the payment explanation could be slightly more streamlined. Front-loads the core functionality.

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

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

Tool has an output schema (indicated) and 5 parameters, all described. The description covers the unique value proposition, payment model, and error handling. For a paid tool with complex retry logic, it provides sufficient context for an agent to use it correctly.

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

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

Schema description coverage is 100% (all 5 parameters described). The description adds context for payment_tx (re-call after 402) and signal_type (listing enums), but these are already well documented in the schema. Baseline 3 is appropriate as the description adds marginal value beyond the schema.

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

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

Description clearly states the tool's purpose: insider transactions with PATTERN analysis (not raw filings), listing specific derived signals. It distinguishes itself as a premium tool for unusual insider selling before earnings, effectively differentiating from siblings.

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

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

Provides explicit usage context ('show me unusual insider selling before earnings') and details the payment flow (daily free allowance, 402 handling with re-call using payment_tx). Lacks explicit when-not-to-use or 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.

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

With no annotations, the description carries full burden. It transparently discloses the payment requirement, daily free allowance, and the 402 re-call flow. It also gives an example of output content. However, it does not mention data freshness, rate limits, or error behavior for invalid arguments.

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

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

Two concise sentences cover the core purpose and provide an example. The payment flow is clearly explained in two sentences without repetition. Every sentence earns its place, and the description is front-loaded.

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

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

Given 6 parameters (0 required) and an existing output schema, the description covers purpose, usage, and payment. It provides an example of returned data. It could mention whether results are paginated or limited, but overall it is fairly complete for a data retrieval tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by linking parameters to real-world concepts: e.g., 'new positions, exits, and big increases/decreases' maps to signal_type, and 'ticker or fund' and 'institution' align directly with parameters ticker and institution. This context helps the agent understand parameter usage.

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

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

The description clearly states it returns 'significant institutional (13F) position changes with context — new positions, exits, and big increases/decreases'. It uses a specific verb ('position changes') and resource, and distinguishes from sibling tools like anomaly_alert or insider_activity.

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

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

The description provides clear context on when to use (institutional ownership flow for any ticker or fund) and includes payment instructions (free tier, 402 flow). It lacks explicit when-not-to-use or alternatives, but the sibling tools are distinct enough that no exclusion is necessary.

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

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

No annotations are provided, so the description bears the full burden. It mentions the tool is free and provides trends and historical-percentile context, but does not disclose data freshness, update frequency, or any limitations. A score of 3 reflects adequate but not comprehensive transparency.

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

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

The description is two sentences long, front-loading the specific indicators. The second sentence adds marketing flair ('FREE') which is slightly extraneous but not excessive. It earns its place overall.

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

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

Given the tool has no parameters and has an output schema (per context signals), the description need not explain return values. It lists the included indicators comprehensively, making the tool's purpose and scope fully clear for a low-complexity dashboard.

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

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

The tool has zero parameters, with 100% schema description coverage (no properties). Per guidelines, the baseline is 4, and the description does not need to explain parameters. No additional meaning is necessary.

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

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

The description clearly states the tool provides current macro indicators including Treasury yields, spread, Fed funds, CPI, unemployment, VIX, credit spreads, and the dollar. It uses specific verb+resource composition and distinguishes itself from sibling tools (e.g., anomaly_alert, company_profile) that focus on micro or company-specific data.

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

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

The description implies usage for obtaining macro context, stating 'every financial agent needs macro context, so this is the gateway.' It does not explicitly state when not to use or list alternatives, but the sibling tools' names indicate distinct purposes, so the usage context is clear.

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

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

With no annotations, the description takes full burden. It indicates the tool is free and returns specific information (attestation method, endpoint, sister servers). No destructive behaviors are implied, and the read-only nature is clear.

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

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

Two concise sentences that are front-loaded with key info ('FoundryNet Data Network info + MINT Protocol details. FREE.') and then detail outputs. No wasted words.

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

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

Given zero parameters, no annotations, and an output schema, the description provides adequate context: it specifies what the tool returns and its cost. The information is complete for selection and invocation.

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

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

There are no parameters, so schema coverage is 100%. The description adds context about what is returned, which is sufficient for a zero-parameter tool.

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

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

The description clearly states the tool provides FoundryNet Data Network info and MINT Protocol details, and lists specific outputs. It distinguishes itself from siblings like company_profile or earnings_check.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies it's for getting network/protocol info but does not state usage context or prerequisites.

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

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

With no annotations, the description carries the full burden. It explains the payment mechanism (cost, free tier, 402 handling, payment_tx parameter) and mentions the optional Authorization header. This is transparent about the cost and authorization requirements, though it does not disclose rate limits or data freshness.

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

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

The description is a single paragraph that front-loads the core purpose then adds payment details. It is concise but could benefit from structuring (e.g., separating purpose, scoring, and payment). Every sentence provides necessary information.

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

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

Given the tool's complexity (9 params, output schema exists), the description covers the main purpose, scoring system, and payment flow. It does not mention pagination or return format, but the output schema handles the latter. The payment procedure is detailed, making it usable for an agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the composite_value_score and its role in ranking, adding context to the sort_by parameter. It also clarifies that agent_id scopes the free-tier counter and payment_tx is used for re-calls after a 402, going beyond the schema descriptions.

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

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

The description clearly states it screens stocks by fundamentals, providing a full ratio profile with sector comparison, and ranks by the proprietary composite_value_score. This distinguishes it from sibling tools like company_profile or earnings_check which focus on individual companies or specific metrics.

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

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

The description implies usage for broad fundamental screening but does not explicitly state when to use this tool vs alternatives. It provides concrete guidance on payment handling (free daily allowance, 402 error, re-call with payment_tx) and an optional Authorization key to bypass payment.

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

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

No annotations are provided, so the description carries full burden. It discloses paid nature, daily free allowance (25/day), 402 handling with Solana memo, and auth bypass using a Bearer token. These are critical behavioral traits beyond the basic read operation. 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.

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

Two sentences: first defines purpose and output, second covers payment mechanics. Every word adds value; no redundancy. The critical information is front-loaded.

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

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

Given the tool has an output schema (known from signals), the description adequately describes the three output categories (median ratios, top/bottom names, earnings trend). It also covers payment workflow. Could be slightly more explicit about read-only nature, but overall complete for the complexity.

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

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

Schema description coverage is 100%, so baseline of 3 applies. The description does not add additional meaning to individual parameters beyond what the schema already provides. For example, the 'sector' parameter is described in both places as a GICS sector.

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

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

The description explicitly states 'Sector snapshot — median ratios (P/E, P/S, P/B, EV/EBITDA, margins, yield), the top and bottom names by composite_value_score, and the aggregate earnings-growth trend for a GICS sector.' This clearly identifies the verb (snapshot) and resource (GICS sector), and distinguishes it from sibling tools which focus on individual companies, anomalies, or macro data.

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

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

No explicit guidance on when to use this tool versus siblings like 'screen_stocks' or 'company_profile'. The purpose implies usage when sector-level aggregate data is needed, but alternatives or when-not-to-use are not addressed. The description focuses on payment details rather than usage context.

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