mrmarket.ai
Server Details
Analytical engine for US-listed equities: screens, rankings, and event studies in plain English.
- 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.6/5 across 8 of 8 tools scored. Lowest: 3.9/5.
Each tool serves a unique, clearly distinct purpose: describe_data catalogs available data, query_data performs analysis, fetch_page handles pagination, get_symbols resolves tickers, get_account_status shows account info, getting_started provides onboarding, recent_queries lists past queries, and report_issue reports problems. No two tools overlap in functionality.
Most tools follow a verb_noun pattern (e.g., describe_data, fetch_page, query_data). The exception is 'getting_started', which uses a gerund phrase and breaks the pattern. Overall, naming is predictable and clear.
With 8 tools, the set is well-scoped for a financial research assistant. It covers metadata discovery, querying, pagination, symbol lookup, account management, onboarding, history, and support. Each tool earns its place without being excessive.
The tool surface covers the full lifecycle of a research session: onboarding (getting_started), metadata exploration (describe_data), querying (query_data), pagination (fetch_page), account management (get_account_status), symbol lookup (get_symbols), history review (recent_queries), and issue reporting (report_issue). No obvious gaps for the stated purpose.
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?
Annotations already mark readOnlyHint=true, but description adds value by noting 'zero cost' and describing the scopes. 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 with bullet points for scopes, front-loaded with purpose. No 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?
For a tool with 3 params, no output schema, and multiple scopes, the description is thorough, covering use cases, scope meanings, and examples.
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?
Description explains each scope with examples and covers entity and search_term usage beyond the schema. Schema coverage is 67% but description fills gaps.
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 for exploring the data catalog before querying, with specific scopes (overview, category, etc.). It distinguishes from sibling tool query_data by recommending use before 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?
Explicitly says 'Use BEFORE query_data when you're unsure what data is available' and provides guidance on which scope to use. Lacks explicit when-not-to-use statements but overall clear.
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 provide readOnlyHint=true, but description adds critical context: it is free, runs no new query, and snapshots live ~15 minutes. 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 and front-loaded with the primary purpose. It is slightly long but each sentence adds value. Could be slightly more concise by merging some points, but overall efficient.
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?
Without an output schema, the description fully covers the pagination behavior, including cursor handling, lifecycle, and when to stop. It is complete enough for an agent to use 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 cursor parameter with description, but the description adds the instruction to pass it verbatim and to keep calling until null. This provides valuable guidance beyond the schema, but schema coverage is already high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches the next page of a query_data result, with specific verb 'Fetch' and resource 'NEXT page'. It distinguishes from siblings like query_data by emphasizing it never runs a new query.
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 (prior response had truncated: true and pagination.next_cursor) and when not to use (if first rows or summary answers the question). Also warns about cursor expiry and provides guidance on repeated calls.
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 already indicate readOnlyHint=true. Description adds valuable context: zero LLM cost, no credits charged, and specifics of returned data (email, plan, credits split, limits). 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?
Three sentences: first states what it is, second lists outputs, third gives usage. No fluff, every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers purpose, output details, and use cases. 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?
No parameters exist, so baseline is 4. Description adds no parameter info but doesn't need to.
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 returns an account snapshot including email, plan, credits, and query limits. It uses specific verbs ('Returns', 'snapshot') and distinguishes itself from siblings by being an account-level status check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides two use cases: (a) confirm expected account is connected, (b) check credit balance before batch queries. While it doesn't list exclusions, the guidance is clear and context-aware.
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?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds behavioral context: sub-50ms speed and zero LLM cost, aiding agent decision-making. 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 and front-loaded with purpose and performance. Action list is presented compactly. Could be slightly more structured (e.g., separating parameter hints) but overall efficient.
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 4 parameters, no output schema, and no parameter descriptions, the description covers the basic use cases but does not specify return format or detailed behavior for each action, leaving some gaps for agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description only lists actions implicitly via enumeration but does not explain parameters like query, sector, industry individually. For example, it's unclear what query expects (a company name?) or how sector/industry relate to actions.
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 'Fast company/sector/industry lookup' and enumerates specific actions (search, list_sectors, etc.). It distinguishes itself from sibling tools like query_data by focusing on symbol resolution.
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 advises using this tool before fanning out query_data calls for backtests or per-symbol price pulls, providing clear context. It could explicitly mention when not to use (if tickers already known).
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?
Discloses zero LLM cost and zero credits, adds details on return value (structured orientation packet), and explains each topic scope. No contradiction with annotations (readOnlyHint).
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 key info and bullet list of topics. Slightly long but all content earns its place; could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description fully explains return value and each topic. Completely adequate for the simple parameter structure.
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 describes parameter with 100% coverage, but description adds deeper meaning: default behavior, explains each enum option in detail, making it more actionable.
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 it is an onboarding tour for mrmarket.ai, with specific verb 'call this FIRST in a fresh session' and distinguishes from siblings by being the orientation 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 when to call: first in fresh session or on user asking capabilities. Does not explicitly state when not to use or give alternatives, but context is clear.
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?
Beyond readOnlyHint=true, the description details response format, error handling, output size limits, pagination, assumptions, warnings, limitations (no MEDIAN, max drawdown approximation), timeout, and credit cost. 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?
The description is excessively long (hundreds of words) and reads like a manual. While well-structured with sections, it lacks conciseness for a tool description. The first sentence is good, but subsequent detail could be trimmed.
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 and the absence of an output schema, the description is remarkably complete. It covers capabilities, usage patterns, limitations, response format, pagination, and best practices, leaving no critical 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% and the description adds crucial context: for max_rows, it clarifies no default cap and preview usage; for question, it elaborates on phrasing, examples, and decomposition. The description significantly enhances understanding 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 explicitly states the tool answers analytical financial questions about US-listed equities with natural language, returning structured rows and columns. It differentiates from siblings like describe_data and fetch_page by specifying that query_data is the main 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?
The description provides extensive guidance on when to use this tool vs. alternatives, including explicit when-to-decompose criteria (iteration, randomness, optimization, etc.), when to compute locally, and when to use siblings for pagination or schema discovery.
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 already have readOnlyHint=true, but description adds 'Zero LLM cost, zero credits' and details return fields. No contradictions; adds behavioral context beyond 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?
Well-structured: main purpose first, then usage guidance, return fields, and parameter notes. Every sentence is informative and concise. Front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 simple parameters, 100% schema coverage, and no output schema, the description thoroughly explains return fields (including examples like query_id format, status values, time formats). Covers all necessary aspects for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. Description repeats parameter info (default 10, max 50, status filters) but does not add significant new semantic meaning beyond schema. It does not compensate for output schema absence because it describes return fields, not parameters.
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 'List the user's most recent query_data calls (newest first)', which is a specific verb+resource combination. It distinguishes itself from siblings like 'query_data' and 'report_issue' by focusing on recent calls and providing query IDs.
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 'that query I ran earlier' etc., and advises to look up here instead of asking for query_id. Provides clear context and alternatives.
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?
The description discloses key behavioral traits: zero LLM cost/credits, auto-linking to query traces, and category meanings. Annotations indicate non-read-only and non-destructive, which aligns with the description. 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?
The description is well-structured with bullet points and clear sections. Every sentence adds value, and it is concise without being overly brief.
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 lacking an output schema, the description explains what happens with the report (support reads, attaches query info) and covers all necessary behavioral aspects. It is complete and informative.
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%, and the description adds extra context beyond the schema, such as the auto-attach behavior of `query_id`, default category, and character limit for `description`. This provides meaningful guidance for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for reporting issues, bugs, feature requests, and slow queries. It uses specific verbs and resources ("Tell support something went wrong") and distinguishes itself from sibling tools like `query_data` and `recent_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?
The description provides explicit when-to-use scenarios (e.g., wrong query result, confusing error, slow query) and category examples. It mentions it's the preferred channel over email, but does not explicitly list when not to use it, though the context is clear enough.
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!