Drillr — The financial MCP for AI agents
Server Details
The financial MCP for AI agents - 90+ financial tables, SEC filings, signals, alt-data.
- Status
- Healthy
- 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.6/5 across 8 of 8 tools scored.
Each tool has a distinct purpose: company_search for qualitative discovery, fiscal_utility for calendar conversions, get_table_schema for column lookup, list_tables for table exploration, run_sql for SQL queries, sec_report_list and sec_report_search for SEC filings, and signal_list for news. The descriptions clearly indicate when to use each, avoiding overlap.
Most names follow a verb_noun pattern (e.g., company_search, get_table_schema, list_tables, sec_report_search), but 'fiscal_utility' deviates as a noun phrase. 'run_sql' is verb_noun. Overall consistency is high with minor exceptions.
With 8 tools, the server covers essential functionalities for financial data access: discovery, schema exploration, SQL querying, SEC filings, and news. The count is well-balanced—neither sparse nor bloated for the domain.
The tool set covers core workflows: qualitative search, fiscal conversions, SQL access to structured data (market data, fundamentals, earnings, analyst, ownership), SEC filing list/search, and news. A minor gap is the lack of a direct tool for looking up a specific ticker's high-level overview, but this can be done via SQL query.
Available Tools
8 toolscompany_searchAInspect
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.
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what it searches across and that it returns a structured list with context snippets. No annotations provided, so description carries the burden; it is transparent but does not explicitly state it is read-only or mention any limitations.
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?
Five sentences, front-loaded with the critical usage guidance. No wasted words; each sentence adds distinct value.
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 one parameter, no output schema, and no annotations, the description covers the purpose, input expectations, output format, and contrasting sibling tool. Very complete.
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 single parameter 'query' is well described with natural language examples and context about acceptable input. The description adds significant value beyond the minimal schema 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?
Clearly states it is for qualitative company discovery and distinguishes from numerical screening via run_sql. Specifies the resource (companies) and action (search/list). Provides examples of queries and scope.
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 use (qualitative discovery) and when not to use (numerical screening), naming the alternative tool (run_sql). Provides example queries and describes return value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fiscal_utilityAInspect
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?
The description explains the bidirectional conversion (forward and reverse) and the required parameters for each mode. Since no annotations are provided, the description carries the full burden. It could be more explicit about the tool being read-only and non-destructive, but the behavior is well documented.
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 (two paragraphs, key points front-loaded). It states purpose, usage context, and then conversion modes. Every sentence is necessary 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?
For a conversion utility, the description is complete: it covers all required aspects (usage timing, conversion directions, parameter roles). No output schema exists, but the return values are implied by the description. Could mention output format, but not essential.
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?
With 100% schema coverage, the parameters already have descriptions. The description adds value by explaining the forward and reverse conversion patterns, relating parameters like fiscal_year/fiscal_quarter and yyyy_mm to the conversion direction, 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 the tool's purpose: converting between fiscal year/quarter and calendar months for a given ticker. It uses specific verbs ('convert', 'call before filtering') and distinguishes itself from siblings by being the only tool dealing with fiscal calendar conversions.
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 context on when to use the tool ('call this before filtering on period_end columns') and notes company variations in fiscal year starts. However, it does not explicitly mention when not to use it or list alternatives, though sibling tools are clearly different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_table_schemaAInspect
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?
No annotations are present, so the description must cover behavioral traits. It conveys a readonly lookup operation and hints at output fields ('name, type, description'), but does not detail side effects, permissions, or output structure. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the usage guideline, and every word adds value. No redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the action, usage context, and result fields. Missing an explicit statement of the return format, but the inference is straightforward.
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 single parameter 'table_name' has an enum defined in the schema, but the description provides no additional explanation or guidance about the parameter or its values. With 0% schema description coverage, more context was needed.
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 purpose: 'Look up column definitions (name, type, description) for a data table.' It identifies the specific verb ('look up') and resource ('column definitions'), and distinguishes from sibling tool 'run_sql' by specifying when to use 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?
Explicit usage guidance is provided: 'Use BEFORE run_sql when you're unsure which columns a table has.' This tells when to use the tool and contrasts with a specific alternative (run_sql), meeting high standards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tablesAInspect
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?
No annotations exist, so the description must cover behavioral details. It discloses the return structure (name, purpose, column names) and batching constraint. It does not mention pagination or rate limits, but for a listing tool this 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?
The description is concise and well-structured: purpose first, then return info, usage guidance, and a neatly formatted category list. 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?
The description is comprehensive for a listing tool given no output schema. It specifies what is returned and what is not (column types). Could mention if metadata like row count is included, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage and the description adds significant value by listing all nine categories with meaningful descriptions, far beyond the schema's enum list. This helps the agent select appropriate categories.
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: listing alternative-data tables under given categories, returning each table's name, one-line purpose, and column names. It distinguishes itself from sibling tools by referencing get_table_schema for column types and run_sql for querying.
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 guidance to use this tool before run_sql to explore alt-data, and notes a batching limit of 5 categories. While it does not specify when not to use it, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_sqlAInspect
Use when you need structured rows from financial/market/altdata tables. For SEC filing narrative use sec_report_search instead. For company qualitative discovery use company_search instead. For recent news + market events use signal_list instead.
Execute a read-only PostgreSQL SELECT query on financial and alternative-data tables.
Call get_table_schema first to look up columns for a specific table. For alternative-data categories, call list_tables(categories=[...]) to see tables + columns.
SQL constraints:
No CTE (
WITH ... AS) — use subqueries instead.Date columns are TEXT — use plain string comparison (
period_end >= '2024-01'). Never use::datecast orINTERVALarithmetic.No
ROUND(float8, int)— useCAST(value AS DECIMAL(10,2))if rounding is needed.Structured-data queries: always filter by ticker (
WHERE ticker IN ('A','B','C'); screening:ticker NOT LIKE '%-%'to exclude preferred stock). Alternative data is macro/industry/patent — no ticker filter required.
Structured data (tables grouped by domain):
Market Data
price_volume_history: Historical OHLCV price data, ~32M rows. MUST filter by ticker AND time_frame ('daily'|'weekly'|'monthly') to avoid timeout. Columns: ticker, period_end, time_frame, open, high, low, close, adj_close, volume, turnover, vwap, change, change_percent. Ticker conventions:
STOCK / ETF — bare 1–5 letters (AAPL, MSFT, SPY, QQQ, VOO, TLT). Foreign listings use exchange suffix: 1557.T (JP), 310960.KS (KR).
INDEX — leading "^" (^GSPC=S&P 500, ^DJI, ^IXIC=NASDAQ Composite, ^NDX=NASDAQ 100, ^RUT=Russell 2000, ^VIX). Foreign indices: ^FTSE, ^GDAXI, ^N225, 000001.SS (Shanghai Composite), FTSEMIB.MI.
COMMODITY — [code]+USD or +USX (CLUSD=WTI futures, BZUSD=Brent, NGUSD=natgas, GCUSD=gold, SIUSD=silver, HGUSD=copper, ZCUSX=corn, CTUSX=cotton). Suffix USX = priced in cents.
FOREX — 6 letters base+quote, no separator (EURUSD, USDJPY, GBPUSD, USDCNY).
CRYPTO — [token]+USD (BTCUSD, ETHUSD, SOLUSD, DOGEUSD, USDTUSD, USDCUSD). Pitfalls:
Same asset, different tickers: NASDAQ 100 → index ^NDX (~26000) vs ETF QQQ (~640). Pick the one matching user intent.
WTI spot ≠ futures. CLUSD here is NYMEX futures, NOT spot (FRED has spot via DCOILWTICO).
Tickers with "." or "^" MUST be quoted in SQL:
WHERE ticker = '^NDX'.
index_price: Real-time price snapshot for 3 major US indices: S&P 500 (^GSPC), Dow Jones (^DJI), NASDAQ 100 (^NDX).
index_composition: Index constituent membership for S&P 500 / Dow Jones / NASDAQ 100 / Nikkei 225 (^N225) / TOPIX (^TPX). Includes current and historical members (active rows have exit_date IS NULL).
equity_extended_rt: Extended-hours snapshot, one row per ticker (~6.1K US equities; PK=ticker; refreshed every few minutes — see extended_updated_at). Use ONLY for pre-market / after-hours / overnight quotes. Columns: ticker, company_name, market, price_current (last regular-session close), then three parallel blocks pre_* / after_* / overnight_* (price, change_val, change_rate, high, low, volume, turnover), plus extended_updated_at. For regular-session OHLCV history use price_volume_history; for valuation / fundamentals use company_snapshot. Japan tickers are NOT in this view yet — extended-hours data is US-only.
Fundamentals
financial_statements: Quarterly and annual financial data covering income statement, balance sheet, and cash flow statement. Filter by ticker + fiscal_period ('FY' annual, 'Q1'..'Q4' quarterly).
company_snapshot: Real-time company snapshot, one row per company. Pre-computed metrics (ratios, percentages, per-share figures, growth rates) only — NOT raw statement line items. For raw statements use financial_statements; for qualitative discovery use company_search.
Earnings
earning_call_summary: Earnings call data with AI-structured summaries (management_highlights, guidance, risks, segment_performance, q_and_a). Filter by ticker + period_end (yyyy-mm). NOT for structured financial numbers.
earning_call_calendar: Earnings conference call schedule with EPS and revenue estimates vs actuals.
datecolumn is the scheduled earnings call datetime (UTC timestamptz) — NOT the press-release / 10-Q filing date (the filing typically lands the same day or shortly after). Use eps_actual IS NULL for upcoming calls, IS NOT NULL for reported.
Analyst Coverage
analyst_ratings: Individual analyst rating events — every re-rating is a separate row. ~565K rows, 519 firms. Filter by ticker;
dateis TEXT (string comparison, no ::date cast). importance >= 4 for high-impact calls.analyst_ratings_consensus: Per-ticker analyst consensus rollup — one row per ticker, refreshed daily. Columns: strong_buy/buy/hold/sell/strong_sell counts, total_analysts, consensus, pt_consensus/high/low.
Ownership & Insider Activity
insider_and_institution_activities: Insider trades (Form 3/4/5) and institutional holding changes (13D/G/F, 13F-HR) from SEC EDGAR. Filter by ticker + source ('insider' vs 'institution'). For institutions, filer_name is the holder; shares/market_value give position size.
Corporate Events (8-K)
executive_change: 8-K executive change events — appointments, departures, reasons, successors, effective dates. Filter by ticker + event_type.
company_deal_events: Single source of truth for corporate deal activity (8-K 1.01/1.02/2.01, S-4, press releases). M&A, financing, material agreements as event-based rows (announced/signed/amended/closed/terminated/waived). Filter by ticker only — do NOT filter by deal_type. One deal may span multiple rows linked via deal_fingerprint.
debt_issuance: 8-K debt issuance events — principal amount, interest rate, maturity, lender, use of proceeds. Use is_current = true for latest version when amendments exist.
securities_offering: 8-K securities offering events — shares, price per share, total proceeds, investors, lock-up. Use is_current = true for latest version when amendments exist.
Executive Profiles & Compensation
executive_profile: Key executive profiles — name, title, compensation, gender, birth year. One row per executive per company.
executive_compensation: Annual executive compensation breakdown — salary, bonus, stock awards, option awards, total. Filter by ticker + year.
Alternative Data
For alternative-data tables, call list_tables(categories=[...]) first.
| 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?
Despite no annotations, the description explicitly states the tool is read-only, lists SQL constraints (no CTEs, date handling, no ROUND, etc.), and provides detailed behavioral notes about ticker conventions and query patterns. This fully compensates for the lack of 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 long but well-structured with clear sections (when-to-use, constraints, table descriptions, pitfalls). Information is front-loaded, and every part adds value for the tool's complexity. No wasted 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 (many tables, constraints, ticker formats), the description is complete: it covers table schemas, query patterns, and special cases. No output schema exists, but return values are SQL rows, which is adequately explained.
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 parameter 'sql' has a brief schema description ('PostgreSQL SELECT query'), but the tool description adds extensive context: table schemas, column examples, ticker conventions, and query patterns, far exceeding what the schema provides.
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 executes read-only PostgreSQL SELECT queries on financial and alternative-data tables, and explicitly differentiates from sibling tools like sec_report_search, company_search, and signal_list by specifying when to use each.
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 guidance ('Use when you need structured rows...') and explicitly names alternative tools for other use cases. It also advises calling get_table_schema and list_tables first, establishing a clear workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sec_report_listAInspect
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 (10-K, 10-Q, 20-F, S-1, DEF 14A and /A amendments; excludes 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, AAPL | |
| 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?
With no annotations provided, the description fully bears the responsibility for behavioral disclosure. It explains the return structure (summary + table of up to 50 filings), lists the fields returned, and describes the filing_types filtering logic. There is 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 concise and well-structured. It uses clear sections: a brief usage header, a pointer to the sibling tool, the main purpose, and then a breakdown of the return value and parameter. Every sentence adds value, and the information is front-loaded.
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 lack of an output schema and annotations, the description covers the essential aspects: purpose, usage, return format, and parameter behavior. It could be slightly more complete by mentioning any prerequisites (e.g., ticker validity) or the fact that the operation is read-only, but overall it is adequate for an agent to select and invoke 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?
The input schema already provides descriptions for both parameters (100% coverage). However, the description adds meaningful context beyond the schema: for filing_types, it explains the default behavior, how to get all types, and how to use an allowlist. This provides useful semantics that the schema alone does not convey.
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: 'Use to discover which SEC filings exist for a ticker before searching content.' and 'List indexed SEC filings for a given ticker with a summary header.' It specifically names the sibling tool sec_report_search for content retrieval, effectively distinguishing the two.
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 guidance on when to use this tool versus the alternative: 'For the actual content use sec_report_search instead.' It also explains the filing_types parameter in detail, covering the default behavior, passing an empty array, and passing an explicit allowlist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sec_report_searchAInspect
Use when you need narrative content (risk factors, MD&A, guidance language). For consolidated financial numbers use run_sql on financial_statements instead.
SEC report semantic search. Search paragraph content in 10-K/10-Q/20-F/6-K filings.
Search Strategy:
(1) Time-specific queries ("recent", "last year", "Q4 2025", etc.): Apply a time range filter upfront to narrow results to the relevant period.
(2) Broad queries with no time requirement: Broad first, narrow later. First 1-2 searches: use MINIMAL filters. Do NOT set filing_types or period unless explicitly needed. This discovers what information exists in what filings. Later searches: add period/type filters to narrow down.
Filing types: 10-K (US annual), 10-Q (US quarterly), 8-K (US current/material events), 20-F (foreign annual), 6-K (foreign current), S-1 (US IPO registration), F-1 (foreign IPO registration).
SCOPE:
(1) Indexes ONLY company-filed SEC reports. Does NOT index institutional filings (13F-HR, 13D, 13G). For institutional holdings, use insider_and_institution_activities with source='institution'.
(2) For standardized consolidated financial numbers (revenue, margins, EPS, etc.), use financial_statements first — SEC filings contain narrative context, not structured data.
High-Value Search Scenarios (use proactively when relevant):
Share dilution / SBC / buyback → search "Shareholders' Equity" or "Capital Stock" for share-level (not just dollar-level) breakdowns
Facilities / properties → search "Properties" for owned vs leased status, lease terms, land use rights
Interest rate sensitivity → search "Market Risk" or "Interest Rate Risk" for floating-rate debt exposure, swap arrangements
Segment revenue breakdown → search "Segment Information" or "Revenue Disaggregation"
Risk factors → search "Risk Factors" for specific risks
Management guidance → search "Outlook" or "Guidance" in MD&A
Accounting policies → search "Critical Accounting Policies"
Stock split history → search "Stock Split" for split ratios and dates
Use for: segment revenue, risk factors, management discussion, guidance, accounting policies, operational metrics, related party transactions, property details, share structure.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| top_k | No | ||
| ticker | Yes | Stock ticker, e.g. NVDA, AAPL | |
| 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?
No annotations are provided, so the description carries the full burden. It explains the scope (indexes only company-filed SEC reports, not institutional) and describes search strategies (time-specific vs broad first). However, it does not mention rate limits, response format, or potential side effects.
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 long and highly detailed, with multiple sections (Search Strategy, Filing types, SCOPE, High-Value Scenarios). While well-structured, some repetition exists (e.g., use cases in SCOPE and later in list). It 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 the tool's complexity (6 parameters, no output schema), the description covers usage context, scope limitations, alternatives, and proactive use cases. It provides nearly all necessary guidance for an AI agent to use the tool effectively.
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%, and the description adds context for some parameters (e.g., filing types explained). However, it does not detail period_start/end or top_k beyond what is in the schema. The search strategy section adds indirect value but does not directly explain each parameter.
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 semantic search of narrative content in SEC reports (10-K, 10-Q, etc.) and distinguishes it from run_sql for financial numbers. It lists specific use cases like risk factors, MD&A, and guidance.
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 tells when to use this tool (narrative content) and when not to (use run_sql for financial numbers, use insider_and_institution_activities for holdings). It also provides search strategies and high-value scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
signal_listAInspect
Use when you need recent news, events, or market-moving signals for specific tickers or sectors. For SEC filing narrative use sec_report_search instead.
Recent news + market events filtered by ticker / sector / time range. Each row is one signal: id, headline, summary, suggested_tickers, sector, score, trigger_sources, earliest_trigger_event_time, created_at, tags. Continuously updating feed.
Coverage:
~6,900 tickers across US + ADRs of global companies
Cross-asset: equities, macro, geopolitics, commodities, crypto
Default sort by earliest_trigger_event_time DESC
Parameters:
tickers (optional): array of tickers — returns signals whose suggested_tickers overlaps any of these
sector (optional): array of sector strings — returns signals whose sector overlaps any of these
from_date (optional): ISO 8601 timestamp; filter earliest_trigger_event_time >= from_date
to_date (optional): ISO 8601 timestamp; filter earliest_trigger_event_time <= to_date
order_by (optional, default earliest_trigger_event_time): 'created_at' | 'earliest_trigger_event_time'
limit (optional, default 20, max 100): max results
offset (optional, default 0): pagination offset
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20, max 100. | |
| offset | No | Default 0. | |
| sector | No | Filter by sector (array overlap match). | |
| tickers | No | Filter by suggested_tickers (array overlap match). | |
| to_date | No | ISO 8601 timestamp; filter earliest_trigger_event_time <= to_date. | |
| order_by | No | Sort column (always DESC). Default: earliest_trigger_event_time. | |
| from_date | No | ISO 8601 timestamp; filter earliest_trigger_event_time >= from_date. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the feed is continuously updating, default sorting by earliest_trigger_event_time DESC, and array filters use overlap matching. It does not mention rate limits or authentication, but as a query tool this is acceptable. A full 5 would require explicit read-only guarantee or error handling notes.
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: usage guidance first, then output fields, coverage, and parameter details. It is slightly repetitive (first paragraph restates filtering), but overall concise and front-loaded. Every sentence adds value.
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, the description lists all returned fields and explains pagination, filtering, and coverage. It is complete for a list tool, though the meaning of 'score' and 'trigger_sources' could be further clarified. Absence of rate limits or error states is minor given the tool's simplicity.
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 3, but the description adds substantial value: it explains that tickers/sector filters return signals with overlapping suggested_tickers/sector, provides defaults for limit, offset, order_by, and clarifies that order_by always sorts descending. It also defines the ISO 8601 format for date parameters. This goes well beyond the schema's brief 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 retrieves recent news, events, and market-moving signals for tickers/sectors, and distinguishes itself from the sibling tool sec_report_search by specifying the latter is for SEC filing narratives. The verb 'list' is implied through the function name and parameter behavior.
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 when you need recent news, events, or market-moving signals' and directs users to sec_report_search for SEC filings. Also explains coverage, default sort order, and parameter behaviors like array overlap matching.
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!