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.5/5 across 9 of 9 tools scored.
Each tool has a well-defined, non-overlapping purpose. Descriptions explicitly warn about alternative tools (e.g., company_search vs run_sql vs sec_report_search vs signal_list), minimizing ambiguity.
All tool names follow a consistent snake_case pattern with clear verb_noun structure (e.g., company_search, get_table_schema, ticker_resolve). No mixing of conventions.
9 tools is an ideal scope for a financial data server. Each tool addresses a distinct high-value operation (search, SQL query, schema discovery, filing retrieval, news, ticker resolution) without bloat.
The tool surface covers the full workflow: company identification (company_search, ticker_resolve), data exploration (list_tables, get_table_schema), numerical querying (run_sql), fiscal period handling (fiscal_utility), narrative content (sec_report_search), and market events (signal_list). No obvious gaps.
Available Tools
9 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
Read-only PostgreSQL SELECT over financial / market / alt-data tables — returns structured rows.
Hard rules (query fails otherwise):
SELECT only, no CTE (
WITH ... AS) — use subqueries.Date/period columns are TEXT — compare as strings (
period_end >= '2024-01'). No::datecast, noINTERVALmath.No
ROUND(float8, int)— useCAST(x AS DECIMAL(10,2))when rounding.Filter structured tables by ticker (
WHERE ticker IN ('AAPL','MSFT'); screening: addticker NOT LIKE '%-%'to drop preferred stock). Alt-data is macro/industry — no ticker filter.
Before querying a table, call get_table_schema(table) — it returns that table's columns PLUS its required filters, gotchas, and ticker formats. For alt-data tables call list_tables(categories=[...]) to discover them.
Sibling tools: SEC filing narrative → sec_report_search; qualitative company discovery → company_search; recent news / market events → signal_list.
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
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?
With no annotations, the description fully bears the burden. It discloses read-only nature, hard query rules (no CTE, date as text, no ROUND), and table-specific filters. Lacks mention of rate limits or error handling, but otherwise transparent.
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 sections for rules, siblings, and table domains. Every sentence adds value, but slightly verbose; could tighten redundancy (e.g., 'Read-only' appears twice).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return type (structured rows) and enumerates tables by domain. References companion tools for schema and discovery, making it highly complete for a complex 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?
Only one parameter 'sql' with minimal schema description, but the tool description adds extensive semantic detail: SELECT-only, no CTE, date handling, filtering requirements, and usage of get_table_schema(). This far exceeds schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Read-only PostgreSQL SELECT' over specific tables, returning structured rows. It distinguishes from sibling tools by mentioning alternatives like sec_report_search, company_search, and signal_list for different use cases.
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 (financial/market/alt-data queries) and when not (narrative, company discovery, news). Provides hard rules and alternatives, and instructs to call get_table_schema() beforehand.
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 from SEC 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 SEC filings; returns matching passages.
Parameters:
query (required): natural-language search; phrase it as the concept or section name you want, e.g. "share repurchase authorization", "Risk Factors", "segment revenue". Run a few phrasings rather than one broad query.
ticker (required): the company whose filings to search.
filing_types (optional): array to restrict to specific types — 10-K (US annual), 10-Q (US quarterly), 8-K (US current/material events), 20-F (foreign annual), 6-K (foreign current), DEF 14A (proxy), S-1/F-1 (IPO), + amendments. OMIT to search all types — foreign issuers (e.g. BABA, TSM) file 20-F/6-K, so omitting avoids zero results.
period_start / period_end (optional): yyyy-mm window; set both to narrow to a date range, omit to search all history.
top_k (optional): max passages to return (default 5).
Scope: indexes ONLY company-filed reports — NOT institutional filings (13F-HR/13D/13G; for those use insider_and_institution_activities with source='institution'). Filings carry narrative, not structured numbers — for revenue/margins/EPS use financial_statements first.
Section targets (search the named section for the intent): non-GAAP / adjusted figures + reconciliations → earnings 8-K (Exhibit 99.1); dilution / SBC / buyback → "Shareholders' Equity" or "Capital Stock"; risk factors → "Risk Factors"; segment breakdown → "Segment Information"; management guidance → "Outlook" / "Guidance" in MD&A; exec comp / board → DEF 14A; accounting policies → "Critical Accounting Policies"; properties → "Properties".
| 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 provided, so description carries full burden. Describes behavior: semantic search over full text of company-filed SEC filings, returns matching passages. Also discloses scope limitations (company-filed only, not institutional). Provides section targets for common intents, which helps the agent understand output 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?
Description is long but well-organized with sections (parameters, scope, section targets). Front-loaded with purpose and usage. Every sentence adds value, though could be slightly more concise by grouping filing_type details. Nonetheless, structure aids readability for an agent.
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, so description should detail return structure. It only says 'returns matching passages' without describing format, metadata, or pagination. Also lacks error handling or edge cases (e.g., no results). Given complexity of SEC filings, more detail on output 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?
Adds significant meaning beyond input schema: advises on query phrasing (natural-language, concept names, multiple phrasings), explains filing_types with examples and advice (omit for foreign issuers), clarifies period format (yyyy-mm), and notes top_k default. Schema coverage is 67% but description compensates fully.
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?
Clear verb 'search' and resource 'SEC filings narrative content'. Distinguishes from sibling tools: explicitly says for financial numbers use run_sql, for institutional filings use insider_and_institution_activities. Also specifies returns 'matching passages'.
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 from SEC filings) and when not (financial numbers, institutional filings). Provides specific alternatives (run_sql, insider_and_institution_activities). Also gives usage advice: phrase query as concept, run multiple phrasings, omit filing_types for foreign issuers, etc.
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.
ticker_resolveAInspect
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" — omit to search both markets
Returns up to 5 matches ranked by prefix-hit first, then name length.
| 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'. Omit to search both. |
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 tool returns up to 5 matches ranked by prefix-hit then name length. However, it does not mention side effects, authentication, rate limits, or error behavior (e.g., no match), leaving some behavioral gaps.
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 54 words split into two tight paragraphs. The first paragraph front-loads purpose and usage guidance. The second paragraph efficiently covers inputs and return behavior. No filler or redundant 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 no output schema and no annotations, the description adequately covers input behavior and return format (max 5, ranking). It lacks error handling details (e.g., no match) but is sufficient for a simple lookup tool. Overall complete enough for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by providing examples ('Apple', 'AAPL', 'OpenAI') and clarifying that 'market' can be omitted to search both. This enriches understanding beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'resolve' and the resource (company name/brand/ticker substring to canonical ticker). It also distinguishes this tool from siblings by instructing to use it 'FIRST' before any ticker-keyed tool, implying that other tools like signal_list or sec_report_search operate on tickers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this FIRST when the user mentions a company by name/brand/nickname before running any ticker-keyed tool.' This provides clear context and ordering, though it does not list specific alternative tool names, it collectively references sibling tools.
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!