Real-time stock quotes, history, options chains, sector performance & screening for agents.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 9 of 9 tools scored. Lowest: 3.5/5.
Each tool targets a distinct market data resource: single quotes, batch quotes, price history, options chains, sector performance, screener, and market briefs. The only potential overlap is quote/batch_quote, but they are clearly differentiated by single vs. batch, and brief_summary vs. daily_brief by depth. No ambiguity in purpose.
All tool names follow a consistent lowercase_with_underscores pattern and are primarily noun phrases (quote, price_history, sector_performance, etc.). There is no mixing of camelCase or inconsistent verb styles. The naming is predictable and readable.
Nine tools is well within the ideal 3-15 range for a focused domain. Each tool covers a distinct aspect of stock market data without redundancy or unnecessary bloat, making the set well-scoped.
The server covers core market data needs: single/batch quotes, historical price, options chains, sector performance, and a screener, plus daily briefs. Minor gaps include lack of direct index quotes or fundamental data, but these are arguably outside the stated market-data scope. Overall, the surface is complete for typical tracking and analysis workflows.
batch_quoteAInspectGet latest quotes for many tickers in one call — price, change, volume, market cap, P/E and 52-week range for each.
FREE for up to 10 tickers. Above 10, PAID at $0.005 USDC per extra ticker after the daily free allowance (cap 100 tickers). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | list of stock symbols, e.g. ["AAPL", "MSFT", "NVDA"]. | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so comprehensively. It discloses the free tier (up to 10 tickers), paid pricing ($0.005 USDC per extra ticker, cap 100), the 402 retry flow (pay returned Solana memo and re-call with payment_tx), and the alternative Bearer key auth that bypasses payment. This is rich behavioral context covering cost, limits, error handling, and authentication.
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, then efficiently covers pricing, limits, and retry logic. Every sentence earns its place, though the payment details are slightly verbose and contain a minor typo ('Solano' for 'Solana'). Overall it is well-structured and not padded.
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?
Despite moderate complexity and no annotations, the description is highly complete for a batch-quote tool. It explains the main function, data returned, free/paid thresholds, retry behavior, and auth alternatives. Since an output schema exists, it need not describe return structure, and it does not — the description fills all necessary gaps.
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 schema already documents each parameter. The description adds meaningful context: it explains that agent_id scopes the free-tier counter (aligning with the schema), payment_tx is the re-call signature after a 402, and tickers are limited to 100 total. It enriches the raw schema by linking parameters to the billing/retry workflow, going beyond the 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?
The description begins with 'Get latest quotes for many tickers in one call' — a specific verb, resource, and scope — and enumerates the data returned (price, change, volume, market cap, P/E, 52-week range). The phrase 'many tickers in one call' distinguishes it from the sibling tool 'quote', which presumably handles single tickers.
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 it is for fetching multiple quotes in one call and provides billing/limit details, but it never explicitly states when to choose this over alternatives (e.g., 'use quote for a single ticker'). No exclusions or when-not-to-use guidance is given, so the usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brief_summaryAInspectGet the top 5 signals from today's brief as structured JSON — a cheap sample of the full daily_brief. Returns the day's highest-priority items (no prose) so an agent can decide whether to buy the full brief.
PAID: $0.50 USDC (vs the full daily_brief price). Defaults to today (UTC). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | brief date YYYY-MM-DD (default today, UTC). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to rely on, the description discloses all critical behaviors: payment requirement ($0.50 USDC), 402 retry flow with Solana memo and payment_tx, optional Bearer token bypass, default to today UTC, and the output being structured JSON with 'no prose.' This is comprehensive and leaves no hidden surprises.
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 tightly written paragraphs. The first states the core function and value proposition. The second covers payment and retry mechanics. Every sentence carries necessary information, though the payment section is dense and could be slightly reorganized for readability.
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 tool involves a nontrivial payment flow, and the description covers all aspects: what it returns, cost, default behavior, retry on 402, and auth bypass. An output schema exists, so not detailing return fields is acceptable. Complete for the complexity involved.
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 meaningful context beyond the schema: it explains the payment_tx parameter in the 402 retry flow and mentions agent_id scopes the free-tier counter. This elevates the semantics for practical use.
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 opens with a specific verb and resource: 'Get the top 5 signals from today's brief as structured JSON.' It further distinguishes itself from the sibling daily_brief by calling itself a 'cheap sample of the full daily_brief,' making the purpose unmistakable.
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 clearly implies a usage context: 'so an agent can decide whether to buy the full brief.' It also contrasts the cost with daily_brief, hinting at when to choose this tool. While it doesn't name alternative tools explicitly, the sibling context and cost comparison provide adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daily_briefAInspectGet the curated daily market brief — the day's top gainers and losers, most active names by volume, sector performance, and notable 52-week highs/lows, in one package. Each brief carries a MINT provenance attestation so a buyer can verify it was produced by this server, unaltered.
PAID: $20 USDC per brief. Defaults to today (UTC); a brief expires at the next midnight UTC. On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An fnet_ Bearer key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | brief date YYYY-MM-DD (default today, UTC). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402 (x402 rail). | |
| stripe_token | No | Stripe Checkout Session id (cs_…), when re-calling after paying the Stripe payment link (alternative to x402). Can also be supplied via the X-Stripe-Token header. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it discloses the $20 USDC cost, expiration, provenance attestation, the 402 recovery procedure (pay memo, re-call with payment_tx), and the fnet_ key bypass. This is rich non-obvious behavior an agent must know before calling.
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 main purpose, then a compact PAID block. Every sentence carries a distinct operational requirement: cost, expiry, payment failure flow, and auth bypass. No filler, and the length is justified by the payment 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?
For a paid, date-expiring tool with 4 params and an output schema, the description covers the what, contents, cost, expiry, payment retry, and authentication. The output schema handles return-value documentation, so no essential behavioral context is missing.
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. The description adds operational meaning by explaining payment_tx is used after a 402 and that the same args must be re-used, and the default date behavior reinforces the schema text. It goes slightly beyond a mere restatement of parameter 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 opens with 'Get the curated daily market brief' and lists concrete contents (top gainers/losers, active names, sector performance, 52-week highs/lows), making the operation specific and distinct from sibling tools. It clearly identifies the resource and the primary action.
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 strong operational context: defaults to today UTC, expiration at next midnight UTC, and the full 402 payment retry flow. However, it does not explicitly compare this tool to siblings like brief_summary or quote, so there is no stated 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.
mint_infoAInspectFoundryNet Data Network + MINT Protocol details (FREE). How to attest your agent's market analysis and trade signals on-chain for verifiable proof of work, and the sibling data servers available across the network.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. It notes the tool is 'FREE' (a useful cost/access hint), but does not describe the return format, whether it makes network calls, or any side effects. For a zero-parameter info tool, this is acceptable but not exemplary.
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 only two sentences, but the second sentence is dense and rambling, mixing attestation instructions with sibling server availability. It front-loads the core subject (details) but would benefit from clearer structure and separation of concepts.
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 simple no-argument informational tool with an output schema, the description covers the main relevant content: network details, MINT protocol, attestation steps, and sibling servers. It does not need to explain return values since an output schema exists, and it is reasonably complete within its 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?
The tool has zero parameters, and the schema coverage is 100% by definition. Per the rubric, a baseline of 4 is appropriate since no parameter explanation is needed and the description adds no irrelevant parameter detail.
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 indicates this is an informational tool about FoundryNet Data Network, MINT Protocol details, and attestation instructions. It distinguishes itself from the sibling market-data tools by focusing on network/protocol metadata rather than quotes or price history. The absence of an explicit verb like 'get' is a minor gap.
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 this tool is for learning about MINT/attestation and available sibling data servers, but it does not explicitly state when to use it versus alternatives. No exclusions or direct comparisons to sibling tools are provided, leaving the usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
options_chainAInspectGet the option chain for a ticker — calls and puts with strike, last price, bid/ask, volume, open interest, and implied volatility, plus the available expiries. (Greeks are not provided by the source; IV/OI/volume are.)
PAID: $0.02 USDC per query after a daily free allowance. On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| expiry | No | expiry date YYYY-MM-DD (default: nearest available expiry). | |
| ticker | Yes | stock symbol, e.g. "AAPL". | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so excellently: it explicitly notes Greeks are not provided, discloses the payment requirement ($0.02 USDC per query), explains the 402 retry flow with payment_tx, and mentions the bearer key bypass. These are critical behavioral details 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 efficiently structured: first sentence states purpose and data fields, second sentence clarifies limitations, and the final paragraph covers payment/auth. Every sentence serves a purpose and is front-loaded with the primary function.
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?
Complex tool with payment mechanics and data caveats; the description covers these thoroughly. Output schema exists, so return values are already specified. Overall, the description is complete and addresses the key operational concerns.
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 explaining the payment_tx workflow with SAME args, which is crucial context not present in the schema. It also clarifies that IV/OI/volume are included, tying to the data fields.
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 function: 'Get the option chain for a ticker', listing specific data fields (calls/puts, strike, last price, bid/ask, volume, OI, IV) and expiries. This distinguishes it from sibling tools like quote and price_history.
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 options data and provides the resource scope, but does not explicitly name when to use this over alternatives. Context is clear enough to differentiate from siblings, meeting the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
price_historyAInspectGet OHLCV price history for a ticker — open/high/low/close/volume bars over a window, for charting, backtesting, and technical analysis.
PAID: $0.01 USDC per query after a daily free allowance. On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 1d,5d,1mo,3mo,6mo,1y,2y,5y,10y,ytd,max (default "6mo"). | 6mo |
| ticker | Yes | stock symbol, e.g. "AAPL". | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| interval | No | 1m,5m,15m,1h,1d,1wk,1mo (default "1d"). | 1d |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It thoroughly discloses the payment requirement ($0.01 USDC after free allowance), the 402 retry flow with Solana memo and payment_tx, and the Authorization Bearer bypass. This goes beyond the basic 'get data' expectation, though it stops short of detailing rate limits beyond the daily 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 compact and well-structured: the first sentence defines the core capability and use cases, and the second addresses the crucial payment/retry behavior. Every sentence earns its place with no filler or 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?
The tool has an output schema, so return values need no explanation. The description effectively covers purpose, use cases, payment behavior, and retry logic, which are the essential contextual elements. It is complete enough for an agent to select and invoke correctly, though it could have briefly mentioned potential error cases beyond 402.
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%, and each parameter already has a meaning in the schema. The description adds useful context about re-calling with payment_tx and the same args, but overall it adds little beyond the schema's parameter descriptions. Baseline 3 is appropriate given the high 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 explicitly states the tool 'Get OHLCV price history for a ticker — open/high/low/close/volume bars over a window', which is a specific verb+resource+scope. It clearly distinguishes from siblings like quote (current price) and options_chain by focusing on historical OHLCV bars for charting, backtesting, and technical analysis.
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: it is for charting, backtesting, and technical analysis, implying historical data needs. It does not explicitly name alternatives or exclusions, but the context is clear enough to guide tool selection among siblings like quote or batch_quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quoteAInspectGet the latest stock quote for a ticker — price, change, change %, volume, market cap, trailing P/E, and the 52-week high/low. FREE — the gateway tool every agent tracking equities needs. Served from a snapshot refreshed every 30 minutes (live fallback on a cold cache).
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | stock symbol, e.g. "AAPL". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the burden and reveals important behavior: data comes from a snapshot refreshed every 30 minutes, with a live fallback on cold cache. It also lists the output fields, making the data scope transparent. It does not mention error handling or rate limits, but for a read-only quote tool, the caching detail is significant.
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 and front-loaded with the core purpose and fields. The phrase 'FREE — the gateway tool every agent tracking equities needs' is somewhat promotional and not strictly necessary, but the overall structure is tight and readable.
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 a simple single-parameter tool with an output schema, the description is complete enough: it covers what data is returned, the snapshot freshness behavior, and the singular ticker scope. It could briefly mention that this is not for batch or historical queries, but the schema and sibling names largely convey that.
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 schema already fully describes the only parameter (ticker) with an example. The description adds no additional parameter-level meaning beyond repeating 'ticker' in prose. Baseline 3 is appropriate given 100% 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 gets the latest stock quote for a ticker, listing specific data fields (price, change, volume, market cap, P/E, 52-week range). It distinguishes from siblings like batch_quote by explicitly being for a single ticker and from price_history by focusing on the latest snapshot.
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 gives context that this is a free, snapshot-based, always-available quote tool and calls itself 'the gateway tool every agent tracking equities needs,' implying a default starting point. However, it does not explicitly mention when to prefer alternatives like batch_quote for multiple tickers or price_history for historical data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screenerAInspectScreen the tracked large-cap universe by market cap, trailing P/E, dividend yield, and sector — returns matching stocks ranked by market cap. A raw market-data filter; for a ranked, fundamentals-driven screen pair this with financial-signals-mcp's composite_value_score.
PAID: $0.01 USDC per query after a daily free allowance. On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| max_pe | No | maximum trailing P/E. | |
| sector | No | GICS sector filter, partial match (e.g. "Technology"). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| min_dividend | No | minimum dividend yield. | |
| min_market_cap | No | minimum market cap (USD). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the paid nature ($0.01 USDC per query, daily free allowance), the 402 retry flow, the market-cap ranking of results, and the 'tracked large-cap universe' scope. It does not mention batch limits, data freshness, or whether results are sorted ascending/descending, but the described behavior is sufficiently transparent for an AI agent to invoke it correctly.
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 remarkably concise yet complete. The first sentence states core functionality, the second positions it vs. alternatives, and the third covers payment handling. Every sentence earns its place, with no filler. The structure is front-loaded with the most important information, and the payment instructions are isolated for clarity.
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 tool with 6 optional parameters, a payment mechanism, and an output schema, the description covers the essential context: the universe, filter criteria, ranking, alternative tool, and payment/re-call flow. It does not detail the output schema (but that is provided separately) and omits the exact daily free allowance or how to obtain an API key. Given the complexity, the description is quite complete, though a fully exhaustive treatment would include those minor details.
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 already documents all 6 parameters with clear descriptions (e.g., 'maximum trailing P/E', 'minimum market cap (USD)'). The description adds value by mapping the screen criteria to the parameters conceptually (market cap, P/E, dividend yield, sector) and explains the payment_tx parameter's role. However, it does not go beyond the schema's semantics—no parameter interactions, defaults, or formatting details are added. Baseline 3 is appropriate because schema coverage is 100%.
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 opens with a specific verb and resource: 'Screen the tracked large-cap universe by market cap, trailing P/E, dividend yield, and sector — returns matching stocks ranked by market cap.' It clearly distinguishes the tool from a ranked fundamentals screen by calling it 'a raw market-data filter' and naming a complementary tool. This makes the purpose unambiguous and differentiates it from sibling tools like quote 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?
It explicitly says when to use it ('A raw market-data filter') and when to pair with an alternative ('for a ranked, fundamentals-driven screen pair this with financial-signals-mcp's composite_value_score'). It also gives a concrete workflow for the payment path: 'On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=<signature>.' This is clear, actionable guidance for both normal and edge-case usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sector_performanceAInspectGet market sector performance — the 11 GICS sectors (via their SPDR sector ETFs) ranked by today's move, with 5-day, 1-month, and year-to-date returns. FREE. For rotation, breadth, and macro positioning at a glance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and does a solid job: it specifies the data source (SPDR sector ETFs), the universe (11 GICS sectors), sorting (ranked by today's move), and timeframes (5-day, 1-month, YTD). It lacks deeper detail like data delay or pagination, but for a simple read-only report this is adequate.
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 sentences: the first front-loads the core purpose and contents, the second adds cost and intended use. No redundant words; every clause 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?
Given the low complexity (0 params) and the presence of an output schema, the description fully covers what the tool does and the intended scenario. It is complete for a lightweight, no-input market data snapshot.
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, and the rubric gives a baseline of 4 for no-parameter tools. The description adds no parameter info because none is needed; the empty input schema is fully self-explanatory.
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 opens with a specific verb ('Get') and a clear resource ('market sector performance'), then details exactly what's included: the 11 GICS sectors via SPDR sector ETFs, ranked by today's move, with 5-day, 1-month, and YTD returns. This clearly distinguishes it from sibling quote/price_history tools.
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 explicitly states the intended use cases ('For rotation, breadth, and macro positioning at a glance') and notes the tool is FREE, giving a clear context for when to use it. However, it does not name alternatives or explicit when-not-to-use conditions, so it misses the top criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!