Stock Market Data MCP

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

With no annotations, the description carries the full burden and does well: it discloses the pricing model, the daily free allowance, the 100-ticker cap, and the exact 402 recovery protocol (pay the returned Solana memo, re-call with the SAME args plus payment_tx). It omits data freshness/delay characteristics and behavior on invalid or partially-unresolvable tickers.

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

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

Three short sentences, front-loaded with what the tool returns, then cost, then the payment-recovery path. Every sentence carries actionable information with no filler.

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

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

For a paid, batch market-data tool with an output schema already defining return values, the description covers cost, limits, auth, and error recovery well. The one meaningful gap is that it never says whether quotes are real-time or delayed, which matters for a market-data 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 the baseline is 3, but the description adds value the schema does not: payment_tx is only valid when re-calling after a 402 with identical arguments, and agent_id scopes the free-tier counter. Those are procedural constraints rather than restatements of the field docs.

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

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

States a specific verb and resource ('Get latest quotes for many tickers in one call') and enumerates the returned fields (price, change, volume, market cap, P/E, 52-week range). The 'many tickers in one call' scope clearly separates it from the singular `quote` sibling without needing to name it.

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?

Gives concrete operating conditions: free up to 10 tickers, paid at $0.005/extra ticker above that, hard cap of 100, and a Bearer key bypass. It does not explicitly say 'use `quote` for a single symbol', so the alternative routing is implied by the batch scope rather than 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?

With no annotations, the description carries the full burden and does: it discloses that the tool is paid ($0.50 USDC), the 402 payment handshake, an auth bypass, UTC defaulting, and that the response is items-only with no prose. These are the behavioral traits an agent cannot infer from 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?

Four short sentences, front-loaded with what the tool returns and why, followed by the payment mechanics. No filler, and each sentence carries a distinct fact.

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?

An output schema exists, so return values need no prose explanation; combined with full parameter coverage and the payment/auth disclosure, an agent has everything needed to call this correctly, including on the 402 retry path.

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

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

Schema coverage is 100%, so the parameter baseline is 3, but the description adds real value: it explains payment_tx as the field supplied on re-call after a 402 and confirms the date defaults to today UTC. Only agent_id is left to 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?

States a concrete verb and resource ('Get the top 5 signals from today's brief as structured JSON') and immediately frames it as a cheap sample of the sibling tool daily_brief, which lets an agent distinguish the two without reading either schema.

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?

Gives an explicit selection criterion — call this to 'decide whether to buy the full brief' — and names daily_brief as the alternative. It also documents the exact 402 recovery path (pay the returned memo, re-call with the same args plus payment_tx) and the bearer-key bypass.

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 behavioral burden and does it well: discloses the $20 USDC price, the exact 402 recovery procedure (pay memo, re-call with SAME args plus payment_tx), the Stripe alternative path, and expiry semantics. It also explains the MINT provenance attestation, which is unexpected behavior an agent could not infer.

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 tight blocks: what you get first, then cost and payment recovery. No filler, and the highest-value constraint (paid, per-brief) is front-loaded rather than buried.

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?

An output schema exists, so return values need not be described, and the description covers the money path thoroughly. The one gap is the free-tier counter tied to agent_id, which only the schema mentions; for a paid tool that is a notable omission but not disqualifying.

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 all four parameters are already documented, giving a baseline of 3. The description does add one piece of semantics beyond the schema — that payment_tx must be paired with identical arguments on retry — but says nothing about agent_id's free-tier scoping or stripe_token, which the schema handles alone.

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

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

States a specific verb and resource ('Get the curated daily market brief') and enumerates the actual payload (gainers/losers, volume leaders, sector performance, 52-week extremes). That inventory of contents distinguishes it from quote, screener, and sector_performance without opening any schema.

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?

Gives clear operating context: defaults to today (UTC), expiry at next midnight UTC, the 402 pay-and-retry loop, and the fnet_ Bearer bypass. It stops short of naming when to reach for brief_summary or batch_quote instead, so the alternative-selection guidance is missing.

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 burden itself; it discloses that the call is free and that the content is documentation rather than live market data, which is useful context. However, it never states that the tool is a read-only, side-effect-free informational call, nor does it describe how current the protocol details are. The output schema covers the return shape, so that omission is acceptable.

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, front-loaded with the identity of the resource and followed by the two content areas. The second sentence is grammatically fragmentary ('How to attest your agent's…'), which slightly slows parsing, but no words are wasted.

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

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

For a zero-parameter documentation tool with an output schema, the description covers what an agent needs: what content lives here and why it matters (verifiable proof of work, sibling servers). The one real gap is a clear trigger condition for when to call it versus jumping straight to a data sibling.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies a parameterless call by describing it purely as a content lookup.

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 names the resource concretely (FoundryNet Data Network + MINT Protocol details) and lists the content it returns: attestation guidance and the catalog of sibling data servers. That clearly separates it from the sibling tools, which are all market-data endpoints. It lacks an explicit verb ('returns'/'describes'), but the noun-phrase framing is unambiguous enough to act on.

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?

Usage is only implied: an agent can infer it should call this to learn how to attest signals on-chain or to discover the other data servers, and '(FREE)' hints there is no cost barrier. There is no explicit 'use this when…' or 'do not use this for…' statement, and no mention of when to prefer a sibling tool instead.

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

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

With no annotations, the description carries the full burden and does well: it discloses pricing ($0.02 USDC after a daily free allowance), the exact 402 recovery loop (pay memo, re-call with SAME args plus payment_tx), and that a Bearer key bypasses payment. It also pre-empts a likely expectation by stating Greeks are not available. Missing only rate/pagination or caching details.

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-loads the payload contents in one sentence, then a compact payment paragraph. Every line is functional, though the parenthetical about Greeks duplicates part of the opening list and could be tightened.

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?

An output schema exists, so return-shape detail is unnecessary, and the description covers the non-obvious payment flow, auth alternative, and data gaps. What remains uncovered–caching, response size, or failure modes beyond 402–is minor for a required-1-param read 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, but the description adds real meaning for payment_tx (only used when re-calling after a 402, with identical args) that the schema alone does not convey. Ticker and expiry semantics are left entirely to 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?

States a specific verb and resource ("Get the option chain for a ticker") and enumerates the returned fields (strike, bid/ask, volume, OI, IV, expiries), which clearly separates it from siblings like quote or price_history. The explicit caveat that Greeks are absent further sharpens what this tool is.

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?

Usage is implied by the resource–option chains are for options analysis versus quote/price_history for spot and history–but no sibling is named and no when-not-to-use condition is given. The payment/auth instructions are operational rather than selection guidance.

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

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

With no annotations, the description carries the burden and usefully discloses payment behavior: $0.01 USDC per query after a daily free allowance, the 402 payment flow, re-calling with the same args plus payment_tx, and Bearer key bypass. It does not explicitly state read-only/safety semantics, but the payment and auth behavior are substantially clarified.

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 intended use cases, then concisely explains payment mechanics. Every sentence serves a clear operational or selection purpose, with no redundant filler.

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

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

Given the absence of annotations, five parameters, full schema descriptions, and an output schema, the description supplies the necessary missing operational context: what it returns, when it is useful, and exactly how to handle payment. Nothing critical for correct invocation is omitted.

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 the schema already documents ticker, period, interval, agent_id, and payment_tx. The description adds workflow semantics for payment_tx by specifying that the re-call must use the same arguments plus the payment signature, which is useful beyond the schema.

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

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

The description uses a specific verb and resource: 'Get OHLCV price history for a ticker', and clarifies the output shape via 'open/high/low/close/volume bars over a window'. It does not explicitly distinguish this from sibling tools like quote or options_chain, but the OHLCV historical-bar scope is clear.

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

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

It names intended use cases such as charting, backtesting, and technical analysis, which implies when to use it. However, it gives no explicit when-not-to-use guidance or alternative tool routing against siblings such as quote.

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 burden and does disclose real behavioral context: data is a snapshot refreshed every 30 minutes with a live fallback on a cold cache, and the call is free. That freshness/staleness disclosure is genuinely valuable for a quote tool, but auth requirements, rate limits, and behavior on an unknown ticker are unstated.

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 return fields and the 30-minute refresh cadence are front-loaded and useful. The "FREE — the gateway tool every agent tracking equities needs" sentence mixes genuine cost information with puffery, so it only partly earns its place.

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

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

An output schema exists, so listing return fields is bonus rather than required, and the freshness model is spelled out. For a single-parameter read tool that is nearly sufficient; only rate limits and invalid-ticker behavior are missing, which 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?

Only one parameter and schema coverage is 100%, with the schema already supplying the "stock symbol, e.g. AAPL" example. The description adds nothing about ticker format (exchange suffixes, case sensitivity, invalid-symbol handling), so the baseline 3 applies.

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?

A specific verb+resource ("Get the latest stock quote for a ticker") plus an explicit enumeration of the returned fields (price, change, volume, market cap, P/E, 52-week range). It never names a sibling, though, so the agent isn't told why this beats batch_quote for multiple tickers or price_history for trends — the enumeration implies single-ticker snapshot but doesn't state it.

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 gateway tool every agent tracking equities needs" is promotional framing, not guidance. There is no statement of when to prefer this over price_history (historical series) or batch_quote (multiple tickers), and no prerequisites or exclusions are given.

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

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

With no annotations provided, the description carries the full behavioral burden and does well: it discloses pricing, the daily free allowance, the 402 payment flow, exact retry semantics with payment_tx, and bearer-token bypass. It does not cover data freshness, full rate-limit behavior, or permission requirements beyond auth/payment.

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 filters, then cleanly separates payment instructions. Every sentence, including the payment and auth details, earns its place for a paid tool.

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

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

For a six-parameter optional-filter tool with a full input schema and an output schema, the description covers purpose, ranking behavior, payment, and auth adequately. It could further define the tracked universe or no-filter default behavior, but an agent has enough information to invoke it correctly.

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

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

Schema coverage is 100%, so all six parameters are already documented in the schema. The description adds useful context around payment_tx and the daily free allowance, but it does not add meaning beyond the schema for screening parameters such as max_pe, min_dividend, min_market_cap, or agent_id.

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

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

States a specific verb and resource: screen the tracked large-cap universe by market cap, P/E, dividend yield, and sector, returning stocks ranked by market cap. It clearly distinguishes this raw market-data screen from a fundamentals-driven screen, but it does not explicitly differentiate itself from listed siblings like quote, price_history, or sector_performance.

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 a clear use context: a raw market-data filter, with financial-signals-mcp's composite_value_score offered as the alternative for ranked fundamentals-driven screening. It does not explicitly state when to avoid this tool or how it relates to sibling tools such as sector_performance, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the whole burden. It usefully discloses cost tier ('FREE') and the exact data composition (11 sectors, four return windows), but says nothing about data freshness/delay, update cadence, or failure behavior if the market is closed. For a zero-parameter read-only snapshot, that is adequate but not rich.

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 short sentences, front-loaded with the core payload and finished with the use case. 'FREE.' is a single-token qualifier that earns its place given no annotations exist to declare cost or safety. Nothing is redundant.

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 structure needn't be explained, and with zero params and no annotations the surface area is small. The description covers what is fetched, at what grain, and why. A note on data delay or market-hours behavior is the only meaningful gap.

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

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

The tool takes no parameters, so there is no parameter semantics to explain; baseline 4 applies. The description's mention of return windows correctly signals what the single fixed call returns rather than implying any configurable inputs.

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

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

States a specific verb and resource ('Get market sector performance') and then spells out the exact payload: the 11 GICS sectors via SPDR ETFs ranked by today's move with 5-day, 1-month, and YTD returns. That level of specificity makes it unmistakable against siblings like quote, price_history, or options_chain, which operate on single instruments rather than cross-sector aggregates.

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?

'For rotation, breadth, and macro positioning at a glance' gives a clear, concrete use case that tells an agent when this tool is the right reach. It stops short of naming an alternative or stating exclusions (e.g., use quote for a single ticker), so it is clear context rather than full routing guidance.

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