Drillr — The financial MCP for AI agents
Server Details
The financial MCP for AI agents - 90+ financial tables, SEC filings, signals, alt-data.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Little-Grebe-Inc/drillr-mcp-server
- GitHub Stars
- 3
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.5/5 across 9 of 9 tools scored.
Each tool targets a distinct purpose: company_search for qualitative discovery, run_sql for quantitative queries, fiscal_utility for date conversion, sec_report_list/search for filings, etc. The descriptions explicitly contrast overlapping tools (e.g., company_search vs run_sql on company_snapshot), eliminating ambiguity.
All tool names follow a consistent verb_noun snake_case pattern (e.g., company_search, get_table_schema, list_tables, news_search, run_sql, sec_report_list, ticker_lookup). No mixing of conventions or unclear verbs.
9 tools is well-scoped for a financial MCP server covering company discovery, news, filings, alternative data, SQL analytics, and utilities. Each tool earns its place without unnecessary bloat.
The tool surface covers core financial workflows: discovery (company_search, ticker_lookup), fundamentals (run_sql on financial_statements), news (news_search), filings (sec_report_list/search), alt-data (list_tables), and utilities (fiscal_utility, get_table_schema). Minor gaps include no dedicated tool for earnings calendar or insider transactions, but these are accessible via run_sql.
Available Tools
9 toolscompany_searchARead-onlyInspect
Use for qualitative company discovery (industry, business model, supply chain, competitors, management background). For numerical screening (revenue, margins, ratios, growth rates) use run_sql on company_snapshot instead.
Drillr's company knowledge base — searchable across industry classification, product offerings, business model, segment structure, competitive landscape, supply chain, management background, and customer profile.
Coverage: US + Japan listed companies only. Optional market filter ('us' | 'jp') narrows
to one market; omit to search both.
Pass a natural language description (e.g. "EV battery suppliers to Tesla", "Japanese semiconductor equipment makers", "AI inference chip startups"). Returns a structured list of matching companies with context snippets.
ONLY for finding a LIST of companies by description.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | natural language query | |
| market | No | Optional market filter: 'us' | 'jp' — the knowledge base covers US + Japan companies only. Omit to search both. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that tool searches across specific fields (industry, products, etc.) and returns structured list with snippets. 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 clear sections: purpose, coverage, usage, return. Multiple sentences but each adds value. Could be slightly more concise, but overall effective.
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?
No output schema, but description explains return format (structured list with context snippets). Covers key aspects like coverage, filtering, and query examples. Adequate for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but description adds examples of natural language queries and explains market filter enum values, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it's for qualitative company discovery (industry, business model, etc.) and distinguishes from numerical screening via run_sql. Specific examples like 'EV battery suppliers to Tesla' clarify 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?
Clearly states when to use (qualitative search) and when not (numerical screening, use run_sql). Specifies coverage (US+Japan) and optional market filter. Provides alternatives (run_sql) and usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fiscal_utilityARead-onlyInspect
Use to convert between fiscal year/quarter and calendar months for a given ticker. Companies have different fiscal year starts (Apple Sep, Nvidia Jan) — call this before filtering on period_end columns.
Fiscal year ↔ calendar month bidirectional conversion. Forward: ticker + fiscal_year + fiscal_quarter → period_start/period_end. Reverse: ticker + yyyy_mm → fiscal_year/fiscal_quarter.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker (e.g. AAPL, MSFT, NVDA) | |
| yyyy_mm | No | Calendar month yyyy-mm (required for reverse conversion) | |
| fiscal_year | No | Fiscal year (required for forward conversion) | |
| fiscal_quarter | No | Quarter 1-4, or 0 for full fiscal year (required for forward conversion) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds context about the conversion behavior (non-modifying, lookup-like) and explains why different fiscal year starts matter, which is beyond the 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 concise, with a clear first paragraph explaining context and a succinct second part outlining the two conversion modes. No unnecessary 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?
No output schema exists, and the description only hints at output fields ('→ period_start/period_end' and '→ fiscal_year/fiscal_quarter') without specifying exact return format or field names. Additional detail on the output structure would improve 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?
Schema description coverage is 100%. The description groups parameters by conversion direction (forward requires fiscal_year/fiscal_quarter, reverse requires yyyy_mm), adding semantic structure beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts between fiscal year/quarter and calendar months for a given ticker, with specific examples (Apple Sep, Nvidia Jan) and explanation of bidirectional conversion. It distinguishes itself from siblings by focusing on fiscal calendar mapping.
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 explicitly states when to use ('call this before filtering on period_end columns') and explains the two modes (forward/reverse) with parameter requirements. No confusion with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_table_schemaARead-onlyInspect
Use BEFORE run_sql when you're unsure which columns a table has.
Look up column definitions (name, type, description) for a data table.
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=true. Description adds specific output details (name, type, description). No contradictions, and behavioral context is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with usage instruction. 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?
Covers return content adequately. Could mention that table names come from list_tables, but not essential. Good for a simple schema lookup 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?
Single parameter with enum coverage. Description does not elaborate on the parameter beyond 'data table', but schema's enum provides all allowed values, making it self-explanatory. Baseline score appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'look up' and the resource 'column definitions (name, type, description) for a data table', distinguishing it from sibling tool 'run_sql'.
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 use before run_sql when unsure of columns, providing clear context. Does not mention when not to use or list alternatives, but still strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tablesARead-onlyInspect
List alternative-data tables under the given categories. Returns each table's name, one-line purpose, and column names (call get_table_schema if you need column types/comments). Batch up to 5 categories in one call.
Use this BEFORE run_sql when you want to explore alt-data — run_sql alone won't tell you which tables exist.
Available categories:
Energy & Power — US power plants, electricity prices, regional hourly generation/demand
Data Centers — facilities, GPU clusters, cooling
Semiconductors — AI chip specs, sales, ownership, foundry revenue, customs trade
Compute Pricing — GPU rental, cloud VM spot/on-demand, instance specs
Model Development — model specs, benchmarks, AI companies, AI polling, LLM arena
Inference Economics — LLM API pricing across providers
Macro & Trade — UN Comtrade, US Census trade flows, FRED macro series
Prediction Markets — Polymarket and Kalshi events, markets, trades, daily aggregates
Critical Minerals — USGS mineral deposits, country supply, critical materials
| Name | Required | Description | Default |
|---|---|---|---|
| categories | Yes | Altdata category names (see tool description for the list) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds that it returns only column names (not types/comments) and recommends get_table_schema for more detail. It also mentions a batching limit of 5 categories, which is consistent with the schema. 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 concise and well-structured: a clear purpose statement, return value details, batching advice, usage guidance relative to siblings, and a bullet list of categories. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and high schema coverage, the description provides sufficient context for an AI agent to decide when to use it. It covers the return format, batch limits, and relationship to sibling tools. It could be more explicit about what 'alternative-data' entails, but the category list clarifies.
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 describes the 'categories' parameter with 100% coverage. The description reinforces the parameter by listing the category options in a readable format with subtopics, but this adds only marginal value since the enum values are 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 clearly states the tool lists alternative-data tables under given categories, specifies the return fields (name, purpose, column names), and distinguishes it from get_table_schema. It also provides a detailed list of categories, leaving no ambiguity about what the tool does.
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 run_sql when exploring alt-data, explaining that run_sql alone doesn't list tables. It also suggests using get_table_schema for column types. However, it does not explicitly mention when not to use it or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_searchARead-onlyInspect
Use for any news, event, development, or statement question about a company, theme, or the market.
Covers US, Japan, Hong Kong and A-share markets; The ticker filter takes
exchange-suffixed symbols: US bare (AAPL), Japan .T (7203.T), Hong Kong
.HK (00700.HK), A-share .SH/.SZ (600519.SH).
Returns Markdown: a ## Stories numbered list (each storyline once), then flat
## Events and ## Claims tables (claims = attributed statements: analyst
actions, corporate guidance, central-bank remarks). The Events story column
refers back to the Stories number. sources counts corroborating reports;
first_reported/last_reported give the reporting span. Lowest-ranked stories
are dropped to fit length; the meta line flags how many were omitted.
At least one of query/theme/ticker/since/until is required. Per-parameter detail is on the input schema — search_type=claims needs query/ticker/a time window, not theme.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Semantic query (English). One of query/theme/ticker/since/until required. | |
| since | No | ISO8601; filter time_event >= since. | |
| theme | No | Theme word, resolved to the nearest canonical theme. Not valid with search_type=claims. | |
| top_k | No | Story count. Default 10, max 50. | |
| until | No | ISO8601; filter time_event < until. | |
| ticker | No | Exact ticker symbol(s) — a single symbol, an array, or a comma-separated string; multiple tickers are an OR/overlap filter. US symbols bare (AAPL); other markets carry their exchange suffix — 7203.T, 00700.HK, 600519.SH. Company names/brands are NOT resolved here; resolve a name via ticker_lookup/company_search first. | |
| order_by | No | Result ordering. relevance (default) | event_time (newest event time first) | create_time (most recently ingested first). | |
| search_type | No | all (default) | events | claims (opinions/statements only). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the output format (Markdown with Stories, Events, Claims sections), how stories are dropped to fit length, and meta information about omitted stories. Annotations only indicate readOnlyHint=true and destructiveHint=false, so the description adds significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose first, then market coverage, ticker details, output format, and final constraints. While comprehensive, it is slightly lengthy but each sentence adds value. A minor trim could improve conciseness.
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 8 parameters, 2 enums, and no output schema, the description compensates fully by detailing output format, parameter constraints, and usage rules. It provides all necessary context 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%, but the description adds critical context: ticker suffix rules for different markets, the incompatibility of theme with search_type=claims, and that multiple tickers act as an OR/overlap filter. These details enhance parameter 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 is for news, events, developments, or statements about companies, themes, or markets. It distinguishes from sibling tools like company_search (company info) and sec_report_search (SEC reports) by focusing on news content and specifying market coverage.
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 usage guidance: 'Use for any news...question' and specifies required parameter combinations ('At least one of query/theme/ticker/since/until is required'). It also notes constraints for search_type=claims. However, it does not explicitly mention when to avoid using this tool in favor of siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_sqlARead-onlyInspect
PostgreSQL SELECT over financial / market / alt-data tables — returns structured rows.
Hard rules (query fails otherwise):
SELECT only, no CTE (
WITH ... AS) — use subqueries.Period columns are TEXT, not dates —
period_endis 'YYYY-MM'. Compare as strings (period_end >= '2024-01'); a::datecast on it fails.Filter structured tables by ticker (
WHERE ticker IN ('AAPL','MSFT'); screening: addticker NOT LIKE '%-%'to drop preferred stock).
Equity coverage: US + Japan (US tickers bare, Japan .T). NOT every table spans both — analyst, insider/institutional, executive, 8-K event and extended-hours tables are US-only, where a .T ticker returns zero rows rather than an error. get_table_schema states each table's markets; check it before reporting an empty result as a finding.
Tables by domain (call get_table_schema for detail):
Market: price_volume_history (OHLCV history; MUST filter ticker + time_frame), index_price, equity_extended_rt (pre/after/overnight quotes)
Fundamentals: financial_statements (GAAP income/balance/cashflow), company_snapshot (ratios, per-share, growth)
Earnings: earning_call_summary, earning_call_calendar
Analyst: analyst_ratings, analyst_ratings_consensus
Ownership: insider_and_institution_activities
8-K events: executive_change, company_deal_events, debt_issuance, securities_offering
Signal events: signal_events (canonical news / market events with tickers[] and themes[])
Executives: executive_profile, executive_compensation
Alt-data: macro / industry / trade / AI-supply-chain — call list_tables(categories=[...])
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | PostgreSQL SELECT query |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, destructiveHint), the description discloses constraints like table market restrictions and zero-return behavior for mismatched tickers. 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 well-structured with bullet points and sections, but it is verbose. The main purpose is front-loaded, making it easy to scan.
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 details query syntax, table domains, and error behavior (US-only tables returning zero rows). It lacks output schema or pagination info but references get_table_schema for additional detail, making it adequate for the tool's 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?
The schema covers the single parameter (sql) with a basic description, but the tool description adds substantial context on allowed SQL syntax and common filtering patterns, which goes 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 it is a PostgreSQL SELECT tool over specific data domains returning structured rows. It distinguishes itself from sibling tools like news_search or ticker_lookup by focusing on SQL 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 rules for usage (SELECT only, no CTE, period columns as strings) and advises checking get_table_schema for table domain coverage. It implies when to use but lacks explicit comparisons to alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sec_report_listARead-onlyInspect
Use to discover which SEC filings exist for a ticker before searching content. For the actual content use sec_report_search instead.
List indexed SEC filings for a given ticker with a summary header.
Returns: summary (period coverage, per-type counts) + table of up to 50 filings (fiscal_year, fiscal_quarter, filing_type, filing_date, period_start, period_end).
filing_types filter: omit for main reports only (US 10-K/10-Q/20-F/S-1/DEF 14A
/A amendments; JP 120/140/160; HK/A-share annual_report / quarterly_report / q1_report; excludes ad-hoc 8-K/6-K); pass [] for all indexed types; pass explicit allowlist to override.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker, e.g. NVDA, 6758.T, 00700.HK, 600519.SH | |
| filing_types | No | Filter by filing type. Omit for default (periodic reports + IPO/shelf registrations + amendments; excludes ad-hoc disclosures). Pass [] for all indexed types. Pass an explicit allowlist to override — use values from the `filing_type` column of a prior unfiltered call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds operational details: returns summary + table with up to 50 filings, explains default filing_types behavior (what is included/excluded), and constraints. No contradictions detected.
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 clear sections: purpose, usage guideline, return format, and parameter behavior. Each sentence adds value, though it is slightly longer than necessary. 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 the tool has 2 parameters and no output schema, the description adequately covers return format (summary + table fields) and constraints (up to 50 filings). It could be improved by mentioning pagination or what happens if more than 50 filings exist, but overall it is sufficiently complete for the 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 coverage is 100% for both parameters. The description adds significant meaning beyond the schema for filing_types by providing concrete examples of default types (US 10-K/10-Q/20-F, etc.) and exclusions. For ticker, the schema already gives examples, so the description adds minimal additional value.
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: 'List indexed SEC filings for a given ticker with a summary header.' It distinguishes from the sibling tool sec_report_search by specifying usage before searching for actual content.
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?
Explicit guidance: 'Use to discover which SEC filings exist for a ticker before searching content. For the actual content use sec_report_search instead.' This clearly tells when and when not to use the tool, with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sec_report_searchARead-onlyInspect
Use when you need narrative content from company filings — risk factors, MD&A, guidance language, deal terms, accounting policies, share structure. For consolidated financial numbers use run_sql on financial_statements instead.
Semantic search over the full text of company-filed reports; returns matching passages.
Coverage: US + Japan + Hong Kong + China A-shares. US = SEC EDGAR (including foreign issuers' 20-F/6-K). Japan = EDINET, .T ticker (6758.T). Hong Kong = HKEX filings, 5-digit .HK ticker (00700.HK). A-shares = .SH/.SZ (600519.SH, 300750.SZ).
Parameters:
query (required): natural-language search; phrase it as the concept or section name you want, e.g. "share repurchase authorization", "Risk Factors". Run a few phrasings rather than one broad query.
ticker (required): US bare (NVDA), Japan
.T, HK.HK, A-share.SH/.SZ, ADRs as their US symbol (SONY).filing_types (optional): US = SEC form names (10-K, 10-Q, 8-K, 20-F, 6-K, DEF 14A, S-1/F-1, + amendments). Japan = EDINET NUMERIC codes: 120 (annual), 140 (quarterly), 160 (semi-annual). HK/A-share = plain names — annual_report; A-share quarters per-quarter (q1_report, ...); HK quarterly results all quarterly_report. OMIT to search all types.
period_start / period_end (optional): yyyy-mm window; omit to search all history.
top_k (optional): max passages to return (default 10).
Scope: indexes ONLY company-filed reports — NOT institutional filings (13F-HR/13D/13G; for those use insider_and_institution_activities with source='institution').
Section targets: non-GAAP reconciliations → earnings 8-K (Ex 99.1); dilution / SBC / buyback → "Shareholders' Equity"; segment breakdown → "Segment Information"; guidance → "Outlook" in MD&A; exec comp → DEF 14A.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| top_k | No | ||
| ticker | Yes | Stock ticker, e.g. NVDA, 6758.T, 00700.HK, 600519.SH | |
| period_end | No | End period YYYY-MM | |
| filing_types | No | ||
| period_start | No | Start period YYYY-MM |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true) are consistent. The description adds context: semantic search returns matching passages, covers specific markets and filing databases, and excludes institutional filings. 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 comprehensive yet well-structured: purpose first, then coverage, then parameter details, then scope and targets. Every sentence adds value, and it is front-loaded with the primary use case.
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 markets, filing types, parameter nuances), the description is thorough. It covers return behavior (matching passages), exclusions, and provides actionable examples. Without an output schema, it still gives enough context for the 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 coverage is 67%, but the description explains each parameter with examples: query (natural language), ticker (market-specific formats), filing_types (US forms, Japan codes, etc.), period_start/end (YYYY-MM), and top_k (default/max). This adds substantial meaning 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 specifies that the tool performs semantic search over company-filed reports to retrieve narrative content like risk factors and MD&A. It distinguishes itself from run_sql for financial numbers and from sec_report_list for listing, making its purpose unambiguous.
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 (narrative content) and when not (financial numbers -> run_sql; institutional filings -> insider_and_institution_activities). Provides guidance on query phrasing, filing types per market, and section targets for specific information needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ticker_lookupARead-onlyInspect
Resolve a company name, brand, or ticker substring to canonical ticker(s). Use this FIRST when the user mentions a company by name/brand/nickname before running any ticker-keyed tool.
Input:
query (required): company name, brand, or ticker substring, e.g. "Apple", "苹果", "AAPL", "OpenAI"
market (optional): "us" | "jp" | "hk" | "cn" — omit to search all markets
Returns up to 5 matches ranked by prefix-hit first, then name length. Returned
symbols carry their market suffix: US bare (AAPL), Japan .T, Hong Kong 5-digit
.HK (00700.HK), A-share .SH/.SZ (600519.SH).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name or ticker substring (case-insensitive). Matches historical names + tickers too. | |
| market | No | Optional market filter: 'us' | 'jp' | 'hk' | 'cn'. Omit to search all markets. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only and non-destructive. Description adds ranking logic (prefix-hit first, then name length), symbol suffix details, and limit of 5 results, significantly extending behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs with no fluff. First paragraph states purpose and usage, second details ranking and output format. Front-loaded and 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?
Despite no output schema, description fully explains output format, ranking, and market behavior. Covers all necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds examples and clarifies market suffix behavior, but the schema already defines parameters well.
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 resolves company names/brands/ticker substrings to canonical tickers. Differentiates itself by recommending use before ticker-keyed tools, distinguishing from siblings like company_search.
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 advises using this tool first when a company is mentioned by name. Provides examples but does not explicitly describe when not to use or compare with alternatives like company_search.
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!