mrmarket.ai
Server Details
mrmarket.ai is a remote MCP server that resolves financial research questions against clean, structured market data. Multi-factor screens, rankings, cohort-relative comparisons, point-in-time event studies, and forward-return analysis across 11,000+ US-listed tickers, returned as structured rows.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.8/5 across 8 of 8 tools scored.
Each tool has a clearly unique purpose: describing available data, paginating results, account info, symbol lookup, onboarding, querying, recent query history, and issue reporting. No two tools overlap in functionality.
Most tools follow a verb_noun pattern (describe_data, fetch_page, get_symbols, query_data, report_issue), but 'getting_started' and 'recent_queries' deviate slightly. Overall naming is clear and predictable.
Eight tools cover the full research workflow without excess or deficiency. Each tool earns its place, supporting discovery, querying, pagination, account management, history, and support.
The tool surface is complete for the domain: schema discovery (describe_data), symbol lookup (get_symbols), onboarding (getting_started), data querying (query_data), pagination (fetch_page), account status (get_account_status), history (recent_queries), and issue reporting (report_issue). No obvious gaps.
Available Tools
8 toolsdescribe_dataARead-onlyInspect
Data catalog — zero cost. Use BEFORE query_data when you're unsure what data is available or whether a specific field or metric is supported.
Scopes:
overview → list all data categories (prices, financials, earnings, insider transactions, etc.) + key fields + computed metrics. Good first call.
category → full field list for one data category. Pass entity with the category name: 'Stock Prices', 'Income Statements', 'Earnings', etc.
computed_metrics → list of pre-defined computed metrics (ROIC, FCF, D/E, ROE, ROA, margins, EPS/revenue growth, stock return, surprise).
search → keyword search across field names, categories, and computed metrics. Pass search_term: 'volatility', 'dividend', 'capex', etc.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | Yes | Use "category" (or "entity" as alias) for a specific data category. | |
| entity | No | Category name for scope "category" — e.g. "Stock Prices", "Income Statements", "Earnings". | |
| search_term | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits including read-only nature (aligned with readOnlyHint annotation), and details what each scope returns. It adds context beyond annotations, such as the zero-cost characteristic and the scoping behavior.
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 well-structured. The first sentence establishes purpose and usage, followed by a clear bullet list of scopes with explanations. No redundant or unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple scopes, no output schema), the description is complete. It covers all scopes, provides usage examples, and indicates what each scope returns, satisfying the need for contextual completeness.
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 description adds significant meaning beyond the input schema. For example, it explains the 'overview' scope as listing categories and key fields, 'category' requires an entity with category name, and 'search' allows keyword search with examples. Schema coverage is 67%, but description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it describes the data catalog, with explicit verb 'describe' and resource 'data catalog.' It distinguishes itself from sibling 'query_data' by advising use before querying data when uncertain about available fields or metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use BEFORE query_data when you're unsure what data is available or whether a specific field or metric is supported.' It also explains each scope's use case, such as 'Good first call' for overview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_pageARead-onlyInspect
Fetch the NEXT page of a large query_data result — FREE (zero credits, runs no
new query). Only use this when a prior query_data (or fetch_page) response had
truncated: true and a pagination.next_cursor.
When to call: the user genuinely needs MORE of the raw rows than page 1 returned.
If a summary, ranking, or the first rows already answer the question — or you only
needed an aggregate (the response carries a full-dataset summary on page 1) —
you are DONE; do NOT paginate.
Pass the cursor string from pagination.next_cursor VERBATIM — do not edit or
truncate it. Keep calling fetch_page with each new next_cursor until it is null.
Snapshots live ~15 minutes; if the cursor has expired, re-run the original question.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | Yes | The opaque continuation cursor from a prior response's `pagination.next_cursor`. Paste it exactly. Do NOT pass a question here — fetch_page returns the next page of an existing result and never runs a new query. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only; description adds: free, runs no new query, cursor must be verbatim, session expires in ~15 minutes, and how to paginate until cursor is null. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with front-loaded purpose, followed by clear sections. Each sentence adds value, though slightly verbose than strictly necessary.
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 simplicity (one param, no output schema), the description fully covers when to call, cursor handling, stopping condition, and expiration. No 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 covers 100% with description; description adds important guidance: pass it verbatim, do not edit/truncate, it is opaque, and not a question. Adds significant value 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?
Clearly states 'Fetch the NEXT page of a large query_data result — FREE', distinguishing it from siblings like 'query_data' which runs new queries.
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 specifies when to use (prior response had 'truncated: true' and a 'pagination.next_cursor') and when not to (if summary/aggregate already answers). Provides alternatives implicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_statusARead-onlyInspect
Account snapshot — zero LLM cost, no credits charged. Returns which mrmarket.ai account this MCP connection is authorized as (email), the plan tier, the current credit balance (and subscription vs top-up split), and per-tier query limits.
Use this to (a) confirm the expected account is connected — a mismatch here explains an unexpected "out of credits", and (b) check the credit balance before running a batch of queries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds that this has 'zero LLM cost, no credits charged', which is valuable beyond annotations. No contradictions; safe, read-only behavior is fully disclosed.
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 plus a bullet-like list for return values. Front-loaded with the key benefit ('zero LLM cost') and 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 no output schema, the description thoroughly lists all return fields (email, plan, credit balance, subscription/top-up split, per-tier limits) and provides usage context. Nothing is missing for a snapshot 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?
The tool has zero parameters, so baseline is 4. The description does not need to add parameter info, and it provides no redundancy. It fully covers what the tool returns.
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 specific verbs like 'Returns' and 'Use this to' to clearly state the tool's purpose: providing account snapshot (email, plan, credits, limits). It is distinct from siblings such as query_data or report_issue, so 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?
Explicitly tells when to use: (a) to confirm the expected account is connected, (b) to check credit balance before batch queries. It also implies when not needed and provides actionable scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_symbolsARead-onlyInspect
Fast company/sector/industry lookup. Sub-50ms, zero LLM cost. Use to resolve names → tickers, list sector members, or get the full universe before fanning out query_data calls (e.g., for backtests or per-symbol price pulls). Actions: search | list_sectors | list_industries | by_sector | by_industry | all.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| action | Yes | ||
| sector | No | ||
| industry | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds performance characteristics ('Sub-50ms, zero LLM cost') and all possible actions, which go beyond the annotations (readOnlyHint). No contradictions; the tool is read-only as described.
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 extremely concise with only two sentences and a list of actions. Every sentence adds value: first states purpose and speed, second gives usage guidance, and the list enumerates available actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, performance, and usage context well. However, it lacks details about the output format (e.g., what information is returned for each action), which could help an agent understand the tool's responses without an output schema.
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 description lists the available actions but does not explain the relationship between parameters like query, sector, and industry with specific actions. With 0% schema description coverage, the description should provide more detailed parameter guidance, but it only offers a high-level list.
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 is a 'fast company/sector/industry lookup' and lists specific actions (search, list_sectors, etc.). It distinguishes itself from sibling tools like query_data by positioning itself as a precursor to data queries.
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 states when to use: 'resolve names → tickers, list sector members, or get the full universe before fanning out query_data calls.' Provides concrete use cases and implicitly identifies query_data as the alternative for actual data retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getting_startedARead-onlyInspect
Onboarding tour for mrmarket.ai — call this FIRST in a fresh session, or any time the user asks "what can you do?" / "how does this work?". Zero LLM cost, zero credits, returns a structured orientation packet (tools, capabilities, limits, examples, troubleshooting, help).
Default scope ('overview') covers everything in a short tour. Optional topic deep-dives a
single area without re-fetching the whole thing:
tools → tool-by-tool reference for query_data, describe_data, get_symbols, get_account_status, report_issue.
examples → 20+ verified working prompts grouped by use case (screens, rankings, comparisons, cohort-relative, time-series, event-vs-price).
limits → universe, freshness, what is NOT supported (intraday, options, news, backtests in one call).
cost → credit model, which tools are free, how to read
credits_remaining.troubleshoot → error_code → recipe (RATE_LIMITED, INSUFFICIENT_CREDITS, QUERY_NOT_UNDERSTOOD, empty result, wrong-looking answer).
help → links + how to reach support; preferred channel is
report_issue.
Use it to bootstrap your understanding of the server before asking real questions — that's the fastest path to a useful first answer for the user.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional section to deep-dive. Default: "overview" — short tour of everything. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true; description adds valuable context: zero LLM cost, zero credits, and returns a structured orientation packet. Discloses optional deep-dive behavior via topic parameter but doesn't specify exact response format, which 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?
Well-structured with front-loaded purpose, bullet-pointed options, and no redundant information. Every sentence adds value, keeping the description concise yet comprehensive.
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 a single optional parameter and no output schema, the description covers all aspects: use cases, cost, parameter options, and what the tool returns. It fully equips 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 covers the topic parameter with enum and brief description. The description adds detailed explanations for each enum value, significantly enriching understanding beyond the schema's minimal description.
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 is an onboarding tour for mrmarket.ai, instructing to call it first in a fresh session. It distinguishes itself from sibling tools by being the introductory orientation, not a data query tool.
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 says to call this first in a fresh session or when user asks about capabilities. Mentions zero cost, guiding usage without alternatives. No other tool serves this onboarding purpose among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_dataARead-onlyInspect
YOU ARE a research assistant helping a retail investor get answers from mrmarket.ai. You are NOT a database engineer. Ask questions the way a financial analyst would say them out loud — plain English, focused on intent. The server has a domain-trained financial expert that translates your question into the right methodology, picks appropriate thresholds, and documents every interpretation in the response so the user can see and correct what was assumed.
Answers analytical financial questions about US-listed equities in a single call. Send the full natural-language question — not SQL. Returns structured rows + columns.
CAPABILITIES — all handled in one call:
Top-N / bottom-N rankings by any metric
Multi-criteria stock screens (combine sector, ratios, growth thresholds, insider activity)
Computed financial metrics: ROIC, FCF, D/E, margins, ROE, ROA, dividend yield, growth rates
Period-over-period changes: QoQ, YoY, multi-year
Rolling averages, trend slopes, volatility, correlation, statistical measures
Multi-symbol comparisons and time-series trends
Sector/industry rollups and averages
Cohort-relative analysis (vs sector average, vs universe z-score)
Forward returns after events (earnings beats, insider buys)
Price charts with event overlays (earnings dates, insider transactions)
Consecutive-quarter screening (e.g., 4 quarters of growing FCF)
EXAMPLES — notice how these read like a human asking, not a technical specification:
"Top 20 stocks by ROIC excluding financials"
"Companies with 4 consecutive quarters of growing free cash flow"
"Compare AAPL, MSFT, and GOOGL revenue over the last 5 years"
"Stocks whose ROIC is at least 1 standard deviation above their sector average"
"Average 30-day stock return after companies beat earnings by more than 10%"
"AAPL daily closes for the last 5 years with earnings dates overlaid"
"Top 20 quality compounders by 5-yr ROIC stability and margin trend"
"Find undervalued stocks with recent insider buying — low P/E, strong FCF, low debt"
"Average stock return 90 days after large CEO insider purchases"
HOW TO PHRASE YOUR QUESTION — this matters for best results:
Pass the user's question through with minimal rewording. The server's financial expert interprets casual language better than you can translate it:
"large purchase" → appropriate dollar threshold (documented in assumptions[])
"90 days" → trading-day equivalent (documented in assumptions[])
"CEO" → executive title matching
"growing" → positive AND increasing
"cheap" / "undervalued" → appropriate valuation thresholds
"Buffett screen" / "quality compounder" → recognized analytical frameworks
DO: ✓ Preserve the user's intent and language faithfully ✓ Use directional terms: "low P/E", "strong cash flow", "high margins" ✓ Add thresholds ONLY when the user stated them explicitly ✓ Ask for aggregated answers when the user wants a summary ("average return after...") ✓ Combine multi-criteria screens into ONE question, not separate calls
DON'T: ✗ Invent numeric thresholds the user didn't specify — the server picks sensible defaults and surfaces them in assumptions[] so the user can adjust ✗ Specify column lists — the server selects the most relevant columns automatically ✗ Convert calendar days to trading days — the server handles this ✗ Add metrics or time ranges the user didn't request — adds complexity and risk ✗ Use AND/OR boolean syntax — plain English works better ✗ Prefix with jargon like "Event study:" or "Screen:" — just ask the question
GOOD: "Find undervalued stocks with recent insider buying — low P/E, strong FCF, low debt" BAD: "Screen for companies where insiders have made open-market stock purchases in the past 3 months AND P/E ratio below 20 AND price-to-book below 3 AND positive free cash flow AND debt-to-equity below 1. Show symbol, name, sector, P/E..."
GOOD: "Average stock return 90 days after large CEO insider purchases" BAD: "For all insider buy transactions where title contains 'CEO' or 'Chief Executive' and transaction value > $100,000, calculate the return 63 trading days after..."
Both versions will work, but the GOOD versions produce better results: the server's financial expert picks market-appropriate thresholds and documents them in assumptions[] so the user can see and correct them. Your pre-translations hide these from the user.
DO NOT split these into multiple calls — they all work in one:
Multi-symbol comparison ("monthly returns for TSLA and SPY" — not two separate calls)
Multi-metric screens ("high ROIC, strong margins, low debt, consistent earnings")
Cross-metric formulas ("stocks where margin > 2x sector average")
Forward return studies ("average return after big earnings beats")
Cohort relatives ("ROIC ≥ 1 stddev above sector mean")
Price + overlay charts ("price chart with earnings markers")
Sector rollups ("average ROIC by sector, ranked")
MULTIPLE RETURN HORIZONS IN ONE CALL — this is critical. "Returns at 1, 5, 10, 21, and 63 days after earnings" is ONE call, not five. The server computes all forward windows in parallel. Never split by horizon — it scans the same data N times for no benefit. Even 5+ horizons in one call is fine.
Multi-entity data retrieval — "show ROIC, FCF yield, D/E, 6-month return, and earnings beat rate for every stock" is ONE call even though it touches fundamentals, prices, and earnings. The server joins them internally. Don't confuse "can't compute a composite score in SQL" with "can't fetch all the data in one call." Fetch in one call, score/rank/normalize in code.
Simple classifications — "stocks drawn down 25%, classify as earnings-driven or multiple-compression" is ONE call. The server handles conditional labels on joined data. Only split when you need the output of one call to parameterize the next.
COMPUTE IN CODE WHEN YOU CAN. Each query_data call costs credits and can fail. If you already have data from a previous call, compute locally instead of calling again:
Aggregations (averages, sums, medians, min/max)
Percentage changes, ratios, growth rates
Sorting, filtering, grouping, ranking
Statistical measures (std dev, correlation, z-scores)
Percentile normalization, composite scoring, factor weighting
Pairwise correlations, covariance matrices Only call query_data when you need NEW data you don't already have.
KNOWN LIMITATIONS — disclose to the user, don't silently work around:
MEDIAN is not supported as an aggregation. If the user asks for median, say so and offer average + standard deviation as an alternative. Don't silently substitute.
Max drawdown requires a continuous equity curve — per-trade returns only approximate it. Disclose the approximation.
DECOMPOSE INTO MULTIPLE CALLS only when: (a) Iteration with state — backtests with rebalancing, compounded returns (b) Randomness — Monte Carlo, bootstrap simulations (c) Optimization — portfolio weights, factor blending, risk parity (d) Custom multi-factor scoring with user-supplied weights — fetch all metrics in ONE call, do the scoring/weighting in code (e) Genuinely unrelated reports with no shared universe (f) "Full analysis" of a single stock — split by: (1) valuation vs sector, (2) financial trends (revenue, margins, FCF, EPS), (3) insider activity. Always announce the plan first. (g) Screen-then-drill — when you need to screen first, then fetch historical data for qualifying symbols (you don't know the symbols until the screen returns)
If the response carries meta.needs_decomposition: true, retry as parallel calls
using meta.suggested_split.
ANNOUNCE YOUR PLAN FOR 2+ CALLS on vague requests ("full analysis", "comprehensive overview"). For specific multi-part questions, announce at 3+ calls. Tell the user in plain language with rough credit cost before proceeding.
OUTPUT SIZE: the MCP tool-result ceiling is ~1MB. Quick math:
1 month ≈ 21 trading days, 1 year ≈ 252
Practical ceilings: ~5,000 price rows or ~2,500 fundamental rows
PREFER narrowing/summarizing first ("per-stock 6mo return" not "all stocks 6mo daily prices", or narrow by sector/time range). A focused question is almost always the better answer.
If a result is still too large, the server no longer fails — it returns page 1 plus a full-dataset
summaryand a freepagination.next_cursor. Callfetch_pagewith that cursor ONLY when the user genuinely needs every raw row; a summary/ranking is usually enough. For very large dumps, hand the userview_url(the full dataset) instead of paginating.
OUT OF SCOPE: intraday/tick data, options chains, news/transcripts, macroeconomic series, portfolio simulation, optimization.
RESPONSE FORMAT — what to expect back:
data: array of row objects keyed by column name (e.g., [{symbol: "AAPL", revenue: 394328000000}, ...])columns: metadata for each column —name,type(currency/percent/number/string/date/boolean),displayName(human-friendly label). Usetypeto format values for the user: currency → "$394.3B", percent → "18.5%", date → "2024-09-30"row_count: total rows returnedassumptions: what the server assumed on the user's behalf (thresholds, time ranges, metric interpretations). ALWAYS surface these to the user so they can correct them.warnings: diagnostic notes (low credit balance, applied defaults)credits_remaining/cost_credits: balance after this call / what this call costtruncated+pagination(oversize results only):truncated: truemeans this is page 1 of a larger result.paginationhaspage_index,page_count,has_more,total_rows, andnext_cursor— pass next_cursor tofetch_page(FREE) for the next page.summaryis a full-dataset per-column digest (min/max/mean/nulls) so you can often answer without paging.
On error: error_code + message + retryable flag. Retry once if retryable is true.
CLARIFICATION HANDLING: when the question is ambiguous, the server resolves it automatically.
If your client supports MCP elicitation, the user is prompted directly. Otherwise the server
applies a sensible default and proceeds. Either way you get a final answer in one call.
Check assumptions[] — always tell the user what was assumed.
LIMITS: 60-second timeout (180s with a clarification roundtrip). No default row cap.
Use describe_data to confirm fields exist before composing complex questions.
| Name | Required | Description | Default |
|---|---|---|---|
| max_rows | No | Optional caller-side row cap. There is NO default cap — by default the server returns every row the SQL produced. Only pass this when you deliberately want a preview (e.g., max_rows: 10). | |
| question | Yes | Full natural-language financial question. Not SQL. For complex multi-step workflows (backtests, Monte Carlo, multi-factor scoring), decompose into multiple calls — see mrmarket://capabilities resource. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds rich behavioral context: it's a query costing credits, has a 60-second timeout, handles pagination, returns assumptions and warnings, and explains error handling. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and verbose, but well-organized into clear sections (CAPABILITIES, EXAMPLES, DO/DON'T, etc.) with front-loaded purpose. While every sentence serves a purpose, the length may overwhelm agents; a more concise version could retain clarity while reducing verbosity.
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 (no output schema, many capabilities), the description is remarkably complete. It covers input format, output format, error handling, pagination, limitations, credit costs, and references sibling tools like fetch_page. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds immense value beyond schema: examples of valid questions, do's/don'ts for phrasing, explanation of max_rows default (no cap), and guidance on when to split into multiple calls. Nearly every line adds meaning.
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 answers analytical financial questions about US-listed equities in a single call. It lists extensive capabilities and examples, and distinguishes from siblings like describe_data (schema description) and fetch_page (pagination).
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 exhaustive guidance: when to use a single call vs decompose into multiple calls, when to compute locally, known limitations, phrasing do's/don'ts, and handling of large results. It explicitly tells agents what to avoid and how to phrase questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recent_queriesARead-onlyInspect
List the user's most recent query_data calls (newest first). Zero LLM cost, zero credits.
Use this when the user references "that query I ran earlier" / "the AAPL one from before" / "the slow one" — instead of asking the user to dictate the query_id, look it up here. Each entry returns:
query_id (the mcp__ handle — pass directly to report_issue or quote to support)
status (success | clarification | timeout | error)
error_code (null on success; the stable error taxonomy otherwise)
row_count (rows returned on success)
prompt_preview (first 120 chars of the original question)
when (relative — "2m ago" / "1h ago" / "3d ago")
created_at_iso (raw ISO timestamp for precise ordering)
execution_time_ms
limit defaults to 10, max 50. status filters: "all" (default), "success", or "error"
(includes timeouts).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recent queries to return. Default 10, max 50. | |
| status | No | Filter by outcome. "error" includes timeouts. Default "all". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, and the description adds that it costs zero credits and LLM cost. It details the return fields, pagination (limit default/max), and filtering by status. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: purpose, usage guidance, return fields, then parameters. Each sentence adds necessary information. 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?
For a read-only list tool with clear annotations, the description covers purpose, when to use, return format, parameters, and cost. No output schema exists, but return fields are fully listed. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description reinforces defaults (limit=10, max 50) and specifies that status='error' includes timeouts. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the user's most recent query_data calls, newest first. It includes specific verb and resource, and the sibling tools (query_data, report_issue) are distinct in purpose.
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 tells when to use: when user references a previous query like 'that query I ran earlier'. It provides concrete examples and contrasts with asking the user to dictate query_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_issueAInspect
Tell support something went wrong, file a bug, request a feature, or flag a slow query. Zero LLM cost, zero credits.
Call this when:
A
query_dataresult looks wrong or misleading (pass thequery_idfrom that response — support uses it to investigate the issue).You hit a confusing error or the same query keeps failing.
A query took unreasonably long (still pass
query_idif available).You wish mrmarket.ai supported something it currently doesn't.
This is the PREFERRED support channel because it auto-links to the query trace; email is slower and requires the user to copy/paste the query_id manually.
Categories:
wrong_data → result was incorrect / numbers look off
bug → something crashed or the response was malformed
slow → query took too long or timed out
feature_request → "I wish it could do X"
general → catch-all if none of the above fits
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional. Defaults to "general" if omitted. | |
| query_id | No | Optional but strongly recommended for query-specific reports. The `query_id` from the `query_data` response you want support to look at (format: `mcp_<timestamp>_<n>`). With it, the server auto-attaches the run's status, error_code, row_count, execution_time, and the original question snippet to the ticket — the user does not need to dictate any of that. If you don't have the query_id at hand, call `recent_queries` first to look it up. | |
| description | Yes | Required. Short free-text description of what went wrong or what you want. One or two sentences is plenty — support reads every report. Max 4000 chars. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false and destructiveHint=false, which are generic. The description adds valuable behavioral context: zero cost/credits, auto-attachment of query data when query_id is provided, and the fact that support reads every report. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections (when to call, categories, etc.) and no redundant sentences. Every sentence adds value, and the bulk is front-loaded with the crux of the tool's 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 the tool has 3 parameters with full schema coverage, no output schema, and good annotations, the description provides all necessary context: what support does with the report, how to provide query_id, and category options. No 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?
Input schema has 100% coverage, so baseline is 3. The description adds meaningful context beyond schema: query_id format and auto-attachment behavior, category defaults, and description max length. This extra information earns a 4.
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 multiple specific verbs (tell, file, request, flag) and resources (support, bug, feature, slow query) to clearly define the tool's purpose. It distinguishes this tool from siblings by positioning it as the preferred support channel, with no overlap with data retrieval or account 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?
Explicitly lists four specific scenarios when to call (wrong data, confusing error, slow query, feature request) and notes it is preferred over email, which is slower and less informative. Provides 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.
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.
Discussions
No comments yet. Be the first to start the discussion!