Financial Signals MCP

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

With no annotations, the description discloses key behaviors: data sources (SEC filings, market data), scope (S&P 500), ranking, payment requirements, and retry procedure. Does not mention error handling beyond 402 or behavior if no anomalies found.

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 somewhat verbose with marketing language ('The premium market-intelligence sweep.'). Core functionality is front-loaded, but could be more efficient. An adequate length given complexity.

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?

Covers main aspects: purpose, data sources, payment flow, retry mechanism. Output schema exists so return values are covered. Minor gaps in error handling and rate limiting details, but overall complete for a paid 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 covers all 3 parameters with descriptions. The description adds context for payment_tx (retry after 402) and agent_id (free-tier counter). This extra information raises the score above the baseline of 3.

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 S&P 500 companies for unusual patterns, listing specific anomaly types (insider trading clusters, earnings divergences, etc.) and ranking by severity. This distinguishes it from sibling tools like insider_activity 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?

Describes payment model and retry logic for 402 errors but lacks explicit guidance on when to use this tool versus alternatives (e.g., for broad scans vs. specific checks). Usage context is implied but not directly stated.

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 the description carries full burden. It discloses the tool returns structured JSON (no prose), costs $0.50, and details payment retry logic. Missing details on error responses beyond 402, but sufficient for agent invocation.

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 mostly concise and front-loaded with purpose. It includes necessary pricing and payment details, which lengthens it slightly but each sentence adds value. 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?

With an output schema present, return values need no explanation. The description covers purpose, cost, default behavior, and payment handling. Missing potential error states other than 402, but overall complete for a simple paid 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%, baseline 3. Description adds value by explaining 'date' defaults to today UTC, 'agent_id' scopes free-tier counter, and 'payment_tx' is for re-call after 402. These enrich understanding beyond schema.

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

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

The description clearly states the verb (Get), resource (top 5 signals from today's brief), and distinguishes from the sibling tool 'daily_brief' by noting it's a cheap sample. This meets the highest standard.

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 explains when to use (to decide whether to buy full brief) and how to handle payment (402 flow), but does not explicitly mention when not to use or compare to other siblings beyond daily_brief. Still clear and helpful.

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 discloses costs, error handling (402 with payment_tx), and authentication (Bearer key). It does not mention destructive behavior, but the read-only nature is implied. Data sourcing from SEC filings is noted.

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 paragraphs, front-loading purpose then usage details. No irrelevant sentences, though paragraph breaks could be slightly clearer.

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 (multiple data categories) and presence of output schema, the description sufficiently sets expectations by listing return components. It does not detail output schema fields but covers the overall scope.

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%. The description adds value by clarifying the free-tier counter scope for agent_id and the retry logic for payment_tx after a 402. The main text also provides cost context not in schema.

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

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

The description clearly states the tool analyzes an S&P 500 stock in one call, listing specific components (financial ratios, insider trading, institutional ownership, etc.). It differentiates itself from sibling tools like insider_activity or earnings_check by offering a blended profile.

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 use for a comprehensive stock analysis, but does not explicitly state when not to use it or provide direct alternatives among siblings. However, the 'blended profile' framing guides appropriate usage.

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

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

With no annotations provided, the description fully discloses that the tool is paid, requires payment via USDC or Stripe, includes a provenance attestation, and expires daily. It also explains the 402 error handling and re-call mechanism. This is good behavioral transparency for a paid tool.

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

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

The description is concise (5-6 sentences), well-structured with the purpose front-loaded, and every sentence provides essential information. No wasted words; the payment details are clearly separated.

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 (paid, multiple parameters, payment flow, expiration), the description is complete. It covers what the tool does, how to use it, payment handling, and provenance attestation. An output schema exists, so return values need not be detailed in the description.

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%, but the description adds significant context beyond the schema: it explains the payment flow for payment_tx and stripe_token, clarifies the free-tier scoping for agent_id, and notes the date default. This added value raises the score above the baseline of 3.

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 'Get the curated daily market-intelligence brief' and lists specific contents (top insider trading anomalies, earnings surprises, etc.), making it distinct from sibling tools like anomaly_alert or macro_dashboard which focus on individual components.

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 instructions including payment requirements ($25 USDC), default date behavior, expiration at midnight UTC, and a detailed payment flow (402 response with Solana memo, re-call with payment_tx). It also mentions optional agent_id for free-tier scoping. However, it does not explicitly compare when to use this versus other tools.

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

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

No annotations provided, so the description carries full burden. It transparently discloses the payment mechanism (402 flow, free allowance, Solana memo, authorization key). Missing details on data freshness or error handling, but the behavioral traits are largely covered.

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 comprehensive yet concise, front-loading the core purpose. Pricing and payment details are integrated without unnecessary verbosity, though slightly lengthy for a tool description.

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

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

Given there is an output schema, the description sufficiently lists all returned data elements. It also covers the payment workflow and authorization, making it complete for effective use without relying on external context.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by noting the S&P 500 constraint for ticker and explaining the payment_tx re-call flow, which goes beyond 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 the tool checks an earnings track record for S&P 500 stocks, listing specific metrics like EPS surprises, streak, average surprise, guidance trend, and next date. It distinguishes itself from sibling tools by focusing solely on earnings data.

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

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

The description gives clear context for use—earnings analysis for trading agents—but does not explicitly mention when not to use it or provide alternatives among siblings. The pricing and payment flow are explained, aiding usage decisions.

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, so description carries full burden. Discloses data source (derived from Form 4), payment model (paid after free tier), 402 response handling, and auth bypass. Does not discuss rate limits or other behaviors but covers key aspects.

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 explaining purpose and signals, second payment flow. No unnecessary words, efficient communication. Could separate sections slightly but overall 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 complexity (paid tool, derived signals, multiple parameters), description covers essential aspects: data source, signals, payment, auth, and parameter roles. Output schema exists, so return format not needed. Minor omissions but sufficient.

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. Description adds value by explaining agent_id scopes free allowance and that Authorization header bypasses it. Also implies payment_tx usage. Adds context beyond raw 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 it analyzes insider trading activity from SEC EDGAR Form 4 filings, deriving signals like cluster_sell, large_buy, etc. Distinguishes from raw filings and provides a specific use case: 'the premium tool for show me unusual insider selling before earnings'. No ambiguity.

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?

Description explains when to use (e.g., 'show me unusual insider selling before earnings') and details payment flow with free allowance, 402 handling, and auth options. Lacks explicit exclusions or comparisons to siblings but provides sufficient context for usage.

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 full burden. It describes the behavior (checking moves, providing context examples) and the payment mechanism (daily free allowance, 402 re-call). However, it does not fully explain the authorization bypass or details of rate limits beyond the daily 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?

The description is concise at two paragraphs: first states purpose, second details payment. It is front-loaded with the core function. Could be slightly more structured, but every sentence adds value.

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

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

Given the tool has 6 optional parameters, an output schema, and no annotations, the description explains purpose and payment workflow adequately. It does not elaborate on return data formatting, but the output schema covers that. Missing details are minor.

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

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

The input schema covers all 6 parameters with descriptions (100% coverage), so baseline is 3. The description does not add additional meaning beyond the schema, e.g., it does not explain how 'agent_id' scopes the counter or the exact format of 'payment_tx'.

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 verb 'Check' and the resource 'institutional ownership moves from SEC 13F filings', listing specific move types (new positions, exits, increases/decreases). The purpose is distinct from sibling tools like insider_activity 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?

The description provides explicit payment instructions and how to handle a 402 error, including the re-call workflow with payment_tx. It does not explicitly state when not to use the tool or compare to alternatives, but the payment model gives clear context for usage.

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?

Describes output in detail (current indicators, trend, historical-percentile, specific metrics) and notes it's free. No annotations, but the description adequately covers the behavior for a read-only tool with no parameters.

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, efficient and front-loaded. First sentence provides essential functional description; second sentence adds context without redundancy.

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

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

Output schema is present, so return format is covered. No parameters needed. Description fully explains purpose and scope of the 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?

No parameters, so schema coverage is 100%. Baseline score of 4 applies, as there is no need for additional parameter information.

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 gets macro indicators with trend and historical-percentile context, listing specific indicators and source (FRED). Distinguishes from sibling tools (e.g., company_profile, sector_snapshot) by focusing on macro context.

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

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

Explicitly positions itself as the gateway for macro context, implying it should be used first. Does not provide explicit when-not 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 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 provided, the description carries the full burden. It transparently describes the data source (SEC filings, market data), the cost model ($0.01 USDC after free allowance), and the error recovery flow (402 → memo → payment_tx). It does not mention rate limits or caching behavior, but overall provides solid 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.

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

The description is two paragraphs: first explains the screening output, second covers payment details. It is front-loaded with the primary purpose and avoids tautology. While relatively long, every sentence serves a purpose.

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 9 parameters with full schema coverage and the presence of an output schema, the description covers the key aspects: what the tool does, what the output contains, and the payment flow. It is sufficiently complete for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so each parameter is already well-described in the schema. The description adds context about the output (full ratio profile, composite_value_score) but does not significantly enhance individual parameter meanings. Baseline score of 3 is appropriate.

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

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

The description explicitly states the tool screens S&P 500 stocks by financial ratios, provides a full ratio profile with sector comparison, and ranks by a proprietary composite_value_score. This clearly distinguishes it from siblings like 'company_profile' or 'earnings_check' which have different focuses.

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 includes payment instructions (daily free allowance, 402 handling) and clarifies the proprietary ranking, but does not explicitly state when to use this tool versus alternatives. The context is clear enough for an agent to understand the primary use case.

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, so description carries full burden. Discloses paid nature, free allowance, 402 re-call flow, and API key bypass. Does not state read-only or side effects, but no annotations to contradict.

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?

Front-loaded with core purpose and output details, followed by payment instructions. Slightly lengthy but every sentence adds value; no redundancy.

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

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

Covers tool purpose, output contents, payment flow, and data sources. Output schema exists for return values. Lacks rate limit details beyond daily allowance, but sufficient for typical usage.

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 covers all 3 parameters with descriptions (100% coverage). Description adds context for payment_tx (re-call after 402) and agent_id (free-tier counter), exceeding baseline.

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?

Clearly states the tool gets a market-intelligence snapshot for a GICS sector, listing specific contents (median ratios, top/bottom names, earnings trend). Distinguishes from sibling tools by being sector-level rather than company-specific.

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?

Describes when to use (for sector-level analysis) and includes payment/retry guidance. However, does not explicitly mention when not to use or suggest alternatives among siblings.

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