Skip to main content
Glama

Drillr — The financial MCP for AI agents

by ai.drillr

Server Details

The financial MCP for AI agents - 90+ financial tables, SEC filings, signals, alt-data.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL
Repository
Little-Grebe-Inc/drillr-mcp-server
GitHub Stars
6
Server Listing
drillr-mcp-server

Available Tools

10 tools
ai_adoptionA
Read-only
Inspect

Search concrete enterprise AI applications disclosed in US company earnings calls from September 2023 to the present. Filter by ticker, partially match a company name, search for an application or workflow by name, or use since in YYYY-MM-DD format to include only observations updated on or after that date. Returns a data array ordered by update_date descending. Each result contains ticker, company_name, application_name, first_report_date, update_date, summary (an AI application summary), evolution_summary, business_position, deployment_stage, deployment_scope, value_type, metrics (application-related metrics), and evidence (supporting management quotes, with speaker and section when available). Use this tool to identify where and how a company applies AI, assess deployment maturity, scope, and disclosed value, and inspect the supporting evidence. Use no filters to browse the most recently updated observations. No matches return an empty data array.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoOne-based page number. Default 1.
limitNoResults per page. Default 10, max 10.
sinceNoOnly return observations with update_date on or after this date. Use YYYY-MM-DD.
tickerNoOptional US ticker filter, up to 10 symbols. Accepts one symbol or a list. Company names are not resolved.
company_nameNoCase-insensitive partial company-name match. Empty means no filter.
application_nameNoCase-insensitive partial application-name match. Empty means no filter.

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as read-only and non-destructive. The description adds meaningful behavioral detail beyond that: results are ordered by update_date descending, no matches return an empty data array, only observations from September 2023 onward are included, and the response shape is fully enumerated. This gives an agent strong expectations without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-organized: purpose, filters, return behavior, field list, use cases, and edge-case behavior. The enumeration of every returned field is somewhat long, but it is justified because no output schema exists. Every sentence earns its place, though it could be trimmed slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description fully compensates by naming every result field, describing ordering, specifying the date range, explaining empty results, and stating usage intent. Pagination and parameter constraints are covered by the schema, so the description is complete for an agent to call and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, so the schema already explains each parameter and its constraints. The description adds a helpful grouping of filter capabilities and the 'no filters' browsing pattern, but it does not materially add meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action ('Search'), a specific resource ('concrete enterprise AI applications disclosed in US company earnings calls'), and a clear date window (September 2023 to present). It also lists the fields returned, making the tool's scope unmistakable against its siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use cases: identify where/how a company applies AI, assess deployment maturity/scope/value, and inspect evidence. It also explains that no filters browses recent observations. It does not explicitly contrast with sibling search tools, but the use cases are clear enough for an agent to select this tool correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

filing_listA
Read-only
Inspect

Use to discover which SEC filings exist for a ticker before searching content. For the actual content use filing_search instead.

List indexed SEC filings for a given ticker with a summary header.

Coverage: US, Japan, and China A-shares. US bare (NVDA), Japan .T (6758.T), A-shares .SH/.SZ (600519.SH).

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; 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
tickerYesStock ticker, e.g. NVDA, 6758.T, 00700.HK, 600519.SH
filing_typesNoFilter 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.

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavior beyond that: market coverage limits (US, Japan, China A-shares only), the default filter that excludes ad-hoc 8-K/6-K, the 50-filing table cap, and the summary-plus-table return shape. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the directive and sibling routing before diving into supporting details. Each block (coverage, returns, filter semantics) carries non-redundant information the agent cannot infer from the schema, and the line breaks organize it cleanly. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Exceptionally complete for a tool with no output schema: the return shape is spelled out, filter modes are fully specified, and coverage is delimited. The one notable gap is the 50-filing cap — the description discloses the limit but doesn't say whether summary counts reflect all indexed filings or how to reach filings beyond the 50-row window.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds genuine meaning beyond it: it spells out the three modes of filing_types with per-market filing-type codes (10-K/10-Q/20-F/S-1/DEF 14A for US, 120/140/160 for JP, annual_report/quarterly_report for A-shares) and instructs the agent to source allowlist values from a prior unfiltered call's filing_type column. This is operational guidance the schema alone does not provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource ('discover which SEC filings exist for a ticker') with a clear scope. It also names the sibling it is not ('For the actual content use filing_search instead'), so an agent can distinguish it from filing_search, news_search, and company_search without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it ('before searching content') and names the alternative (filing_search) with the differentiating condition (discovery vs. content). The coverage and ticker-format guidance further constrain correct usage per market, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_table_schemaA
Read-only
Inspect

Use BEFORE run_sql when you're unsure which columns a table has.

Look up column definitions (name, type, description) for a data table.

ParametersJSON Schema
NameRequiredDescriptionDefault
table_nameYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by clarifying the output content (column definitions with name, type, description) and its role as a prerequisite to run_sql. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with no filler. The usage recommendation comes first, followed by a precise statement of what the tool returns.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only schema lookup with one parameter and a complete enum of tables, the description adequately covers return fields and timing. It could mention error or edge-case behavior, but those are not essential given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needed to compensate, but it only vaguely refers to 'a data table.' The enum in the schema lists the valid table names, but the description adds little meaning beyond what the parameter name already implies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Look up') with a clear resource ('column definitions') and even states what is returned ('name, type, description'). The 'Use BEFORE run_sql' clause helps distinguish this tool from the primary query sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use the tool ('BEFORE run_sql' when unsure which columns a table has) and names run_sql as the alternative. It does not fully discuss when not to use it or contrast it with list_tables, but the guidance is clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

industry_inflectionsA
Read-only
Inspect

Search industry inflections identified through structured research of earnings calls held by US-listed companies after July 2026, including the change mechanism, impact scope, market attention and affected companies.

All filters are optional and combine with AND. With no filters, returns the newest first page. Results are ordered by quarter descending. If nothing matches, returns the text No relevant industry inflections found.

Returns JSON as { "data": [...] }. Every result contains quarter, name (English title), regime_type (change mechanism), impact_scope, impact_degree (limited | significant | structural), attention_verdict (market-absorption judgment), change_summary (currently Chinese), first_seen (YYYY-MM-DD), and source_tickers (companies whose calls are primary evidence). When impact_companies is true, company_impacts contains items with ticker, relation, direction, magnitude, impact_stage, evidence_status, affected_business, and impact. A successful call costs 1 credit.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoOne-based page number. Default 1.
limitNoResults per page. Default 10, max 10.
tickerNoOptional company filter, up to 10 US ticker symbols. Returns themes where any supplied ticker is a source company or an affected company. Use symbols such as AAPL, not company names.
keywordNoOptional case-insensitive text contained in the theme name or research summary, up to 200 characters.
impact_companiesNoInclude the per-company company_impacts list. Default false.

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations by disclosing ordering, empty-result behavior, exact JSON shape, field details, and credit cost. It even notes that change_summary is currently Chinese. This gives the agent a complete behavioral model of the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence carries meaningful information: purpose, filtering semantics, ordering, output format, field definitions, conditional behavior, and cost. It is front-loaded with the core purpose and structured in a logical flow from behavior to return schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully documents the return structure, including all top-level fields and the conditional company_impacts subfields. It also covers pagination, ordering, empty results, data source time range, and credit cost, making it complete enough for an agent to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that filters combine with AND, describing the no-filter default behavior, and specifying what happens when impact_companies is true. This raises it above baseline but does not substantially deepen individual parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Search industry inflections identified through structured research of earnings calls held by US-listed companies after July 2026.' It also lists the semantic fields returned, making the tool's function unambiguous and easy to distinguish from siblings like news_search or filing_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: all filters are optional, combine with AND, no filters returns the newest first page, and results are ordered by quarter descending. It does not explicitly name alternatives or state when not to use this tool, but the context is strong enough for correct selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tablesA
Read-only
Inspect

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; omit categories, or pass ["all"], to get the category index instead.

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

ParametersJSON Schema
NameRequiredDescriptionDefault
categoriesNoAltdata category names (see tool description for the list). Omit, or pass "all", for the category index.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds batching limit (up to 5 categories), behavior when omitted or 'all', and what is returned (name, purpose, column names). No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with purpose first, then details, usage guidance, and categories. Slightly long but every sentence serves a purpose. Could be slightly more concise but effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description covers what is returned (name, purpose, column names) and directs to get_table_schema for types. Includes batching and categories. Complete for a listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with enum list and description. Description reinforces the categories list and adds batching instructions and behavior when omitted. Adds value beyond schema, so slightly above baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'List alternative-data tables under the given categories' with specific verb and resource. Distinguishes from siblings like get_table_schema and run_sql by explaining what each returns and when to use them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this BEFORE run_sql when you want to explore alt-data' and mentions get_table_schema for more details. Provides clear when-to-use and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_sqlA
Read-only
Inspect

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_end is 'YYYY-MM'. Compare as strings (period_end >= '2024-01'); a ::date cast on it fails.

  • Filter structured tables by ticker (WHERE ticker IN ('AAPL','MSFT'); screening: add ticker NOT LIKE '%-%' to drop preferred stock).

Core equity coverage: US, Japan, Hong Kong, China A-shares, and Korea. Tickers are US bare (AAPL), Japan .T (6758.T), Hong Kong .HK (00700.HK), A-shares .SH/.SZ (600519.SH), and Korea .KS/.KQ (005930.KS). financial_statements, company_snapshot, and price_volume_history span all five. Specialized tables may be narrower — call get_table_schema before treating 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

  • Executives: executive_profile, executive_compensation

  • Alt-data: macro / industry / trade / AI-supply-chain — call list_tables(categories=[...])

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYesPostgreSQL SELECT query

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses key behaviors beyond the annotations: SELECT-only restriction, no CTE support, period column type constraints (TEXT, not date, with specific comparison syntax), and ticker filtering requirements. It aligns with readOnlyHint=true and destructiveHint=false, and adds the nuance that empty results may not be findings without schema verification.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with clear sections: hard rules, coverage, tables by domain. It front-loads the most critical constraints (hard rules) before listing tables. Each section earns its place; the table listing is verbose but necessary for a query tool with heterogeneous tables. Slightly excessive length for a description, but effective organization prevents wasted space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is thorough for a tool with one parameter and no output schema: it explains coverage (US, Japan, HK, China, Korea), table categories, and query constraints. It references sibling tools (get_table_schema, list_tables) to fill gaps. However, it lacks details on return format (e.g., row limits, pagination, error handling for invalid SQL), which would be useful for a raw SQL tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers the 'sql' parameter 100% with a description 'PostgreSQL SELECT query'. The description adds value by providing example query patterns (ticker IN ('AAPL','MSFT'), ticker NOT LIKE '%-%' for screening) and table-specific usage notes, which are not in the schema. However, since the schema already adequately describes the parameter, the baseline is 3, with the description's examples lifting it to 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies 'PostgreSQL SELECT over financial / market / alt-data tables — returns structured rows', giving a clear verb (SELECT), resource (PostgreSQL tables), and scope (financial/market/alt-data). It distinguishes itself from sibling tools like get_table_schema, list_tables, and search tools by explicitly focusing on direct SQL querying over the database tables.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: it tells the agent to call get_table_schema before treating empty results as findings, lists tables by domain, and specifies hard rules for query construction (e.g., no CTEs, period columns as TEXT, filter by ticker). This clearly signals when to use this tool versus alternatives like list_tables or get_table_schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ticker_lookupA
Read-only
Inspect

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" | "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 (6758.T), A-share .SH/.SZ (600519.SH).

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesCompany name or ticker substring (case-insensitive). Matches historical names + tickers too.
marketNoOptional market filter: 'us' | 'jp' | 'cn'. Omit to search all markets.

TDQS

A3.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as read-only and non-destructive. The description adds valuable behavioral context beyond that: it returns up to 5 matches, ranks by prefix-hit first then name length, and explains market suffixes for returned symbols. This is exactly the kind of extra behavioral detail agents need.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loads purpose and usage guidance. The bullet list restates parameter information already covered by the schema, and the market line is both redundant and incomplete, so it is not maximally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by explaining result count, ranking, and symbol suffix formatting. However, it omits the valid 'hk' and 'kr' market values and does not mention historical-name matching (which appears only in the schema). Mostly complete but with meaningful gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description actively conflicts with the schema: it lists market options as 'us' | 'jp' | 'cn' while the schema enum also includes 'hk' and 'kr'. This omission is misleading for parameter selection. The query examples are useful but do not compensate for the inaccurate market enumeration.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Resolve') plus resource ('company name, brand, or ticker substring to canonical ticker(s)'), making the core purpose clear. It does not explicitly distinguish itself from the sibling company_search, so it stops short of a full 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guidance: 'Use this FIRST when the user mentions a company by name/brand/nickname before running any ticker-keyed tool.' It does not mention the sibling company_search or state when not to use it, so it lacks exclusions or a named alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 7 tool updates
    • Addedai_adoption
    • Addedfiling_list
    • Addedfiling_search
    • Addedindustry_inflections
    • Removedsec_report_list
    • Removedsec_report_search
    • Changedticker_lookup1 field changed
      • changedInput schema / properties / market / description
        Previous value: -"Optional market filter: 'us' | 'jp' | 'hk' | 'cn' | 'kr'. Omit to search all markets."New value: +"Optional market filter: 'us' | 'jp' | 'cn'. Omit to search all markets."
  2. 1 tool update
    • Removedfiscal_utility
  3. 1 tool update
    • Removedsearch_data_catalog
  4. 1 tool update
    • Addedsearch_data_catalog
  5. 1 tool update
    • Removedsearch_data_catalog
  6. 1 tool update
    • Addedsearch_data_catalog
  7. 2 tool updates
    • Changedcompany_search2 fields changed
      • changedInput schema / properties / market / anyOf
        Previous value: -[
-  {
-    "enum": [
-      "us",
-      "jp",
-      "hk",
-      "cn"
-    ],
-    "type": "string"
-  },
-  {
-    "items": {
-      "$ref": "#/properties/market/anyOf/0"
-    },
-    "maxItems": 4,
-    "type": "array"
-  }
-]New value: +[
+  {
+    "enum": [
+      "us",
+      "jp",
+      "hk",
+      "cn",
+      "kr"
+    ],
+    "type": "string"
+  },
+  {
+    "items": {
+      "$ref": "#/properties/market/anyOf/0"
+    },
+    "maxItems": 5,
+    "type": "array"
+  }
+]
      • changedInput schema / properties / market / description
        Previous value: -"Optional market filter. Pass one lowercase value or a list from 'us' | 'jp' | 'hk' | 'cn'. Omit or pass [] for all four; list order does not set priority."New value: +"Optional market filter. Pass one lowercase value or a list from 'us' | 'jp' | 'hk' | 'cn' | 'kr'. Omit or pass [] for all five; list order does not set priority."
    • Changedticker_lookup2 fields changed
      • changedInput schema / properties / market / description
        Previous value: -"Optional market filter: 'us' | 'jp' | 'hk' | 'cn'. Omit to search all markets."New value: +"Optional market filter: 'us' | 'jp' | 'hk' | 'cn' | 'kr'. Omit to search all markets."
      • changedInput schema / properties / market / enum
        Previous value: -[
-  "us",
-  "jp",
-  "hk",
-  "cn"
-]New value: +[
+  "us",
+  "jp",
+  "hk",
+  "cn",
+  "kr"
+]
  8. 1 tool update
    • Changedlist_tables4 fields changed
      • changedInput schema / properties / categories / description
        Previous value: -"Altdata category names (see tool description for the list)"New value: +"Altdata category names (see tool description for the list). Omit, or pass \"all\", for the category index."
      • changedInput schema / properties / categories / items / enum
        Previous value: -[
-  "Energy & Power",
-  "Data Centers",
-  "Semiconductors",
-  "Compute Pricing",
-  "Model Development",
-  "Inference Economics",
-  "Macro & Trade",
-  "Prediction Markets",
-  "Critical Minerals"
-]New value: +[
+  "Energy & Power",
+  "Data Centers",
+  "Semiconductors",
+  "Compute Pricing",
+  "Model Development",
+  "Inference Economics",
+  "Macro & Trade",
+  "Prediction Markets",
+  "Critical Minerals",
+  "all"
+]
      • removedInput schema / properties / categories / minItems
        Removed value: -1
      • removedInput schema / required
        Removed value: -[
-  "categories"
-]
  9. 2 tool updates
    • Changedcompany_search6 fields changed
      • addedInput schema / properties / market / anyOf
        Added value: +[
+  {
+    "enum": [
+      "us",
+      "jp",
+      "hk",
+      "cn"
+    ],
+    "type": "string"
+  },
+  {
+    "items": {
+      "$ref": "#/properties/market/anyOf/0"
+    },
+    "maxItems": 4,
+    "type": "array"
+  }
+]
      • changedInput schema / properties / market / description
        Previous value: -"Optional market filter: 'us' | 'jp' — the knowledge base covers US + Japan companies only. Omit to search both."New value: +"Optional market filter. Pass one lowercase value or a list from 'us' | 'jp' | 'hk' | 'cn'. Omit or pass [] for all four; list order does not set priority."
      • removedInput schema / properties / market / enum
        Removed value: -[
-  "us",
-  "jp"
-]
      • removedInput schema / properties / market / type
        Removed value: -"string"
      • changedInput schema / properties / query / description
        Previous value: -"natural language query"New value: +"Natural-language company description"
      • addedInput schema / properties / query / minLength
        Added value: +1
    • Changedfiscal_utility1 field changed
      • changedInput schema / properties / ticker / description
        Previous value: -"Stock ticker (e.g. AAPL, MSFT, NVDA)"New value: +"Stock ticker. Coverage is primarily US; sparse JP/HK; no China A-share configuration."
  10. 5 tool updates
    • Changedcompany_search1 field changed
      • addedInput schema / properties / market
        Added value: +{
+  "description": "Optional market filter: 'us' | 'jp' — the knowledge base covers US + Japan companies only. Omit to search both.",
+  "enum": [
+    "us",
+    "jp"
+  ],
+  "type": "string"
+}
    • Changednews_search1 field changed
      • changedInput schema / properties / ticker / description
        Previous value: -"Exact ticker symbol(s) — a single symbol, an array, or a comma-separated string; multiple tickers are an OR/overlap filter. Bare symbols only, no exchange suffix. Company names/brands are NOT resolved here; resolve a name via ticker_lookup/company_search first."New value: +"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."
    • Changedsec_report_list1 field changed
      • changedInput schema / properties / ticker / description
        Previous value: -"Stock ticker, e.g. NVDA, AAPL"New value: +"Stock ticker, e.g. NVDA, 6758.T, 00700.HK, 600519.SH"
    • Changedsec_report_search1 field changed
      • changedInput schema / properties / ticker / description
        Previous value: -"Stock ticker, e.g. NVDA, AAPL"New value: +"Stock ticker, e.g. NVDA, 6758.T, 00700.HK, 600519.SH"
    • Changedticker_lookup2 fields changed
      • changedInput schema / properties / market / description
        Previous value: -"Optional market filter: 'us' | 'jp'. Omit to search both."New value: +"Optional market filter: 'us' | 'jp' | 'hk' | 'cn'. Omit to search all markets."
      • changedInput schema / properties / market / enum
        Previous value: -[
-  "us",
-  "jp"
-]New value: +[
+  "us",
+  "jp",
+  "hk",
+  "cn"
+]
  11. 4 tool updates
    • Addednews_search
    • Removedsignal_list
    • Addedticker_lookup
    • Removedticker_resolve
  12. 1 tool update
    • Addedticker_resolve

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Login with GitHub to comment

Related MCP Connectors

Related MCP Servers

  • ko.io

    SharpLu
    A
    license
    Not graded
    quality
    B
    maintenance
    Wall Street data feed for AI agents, providing access to 100M+ source-traced SEC records, institutional holdings, insider trades, congress trading, and more via MCP tools.
    MIT

  • finance-mcp

    adididitagain
    A
    license
    A
    quality
    A
    maintenance
    Provides live financial data for any LLM agent, including stock quotes, crypto prices, SEC filings, XBRL financials, FX rates, and macro indicators, through ten MCP tools.
    11
    150
    1
    MIT

  • MCP Financial Data Gateway

    ranjittilekar
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides 10 financial data tools (market data, economic indicators, news, insider trades, and calendars) via a single MCP layer, enabling any MCP-compatible LLM to access diverse financial data through a unified interface.
    MIT

  • EdgarMCP

    birthday-tools
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides AI agents with clean, normalized access to financial data including company fundamentals, insider trades, SEC filings, macro series from FRED, real-time quotes, and ETF holdings.
    MIT
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Each tool targets a distinct retrieval task: company discovery, ticker resolution, filing metadata/content, SQL metadata/execution, news, AI adoption, and industry inflections. The only mild overlap is between ai_adoption and industry_inflections, both earnings-call derived, but their descriptions differentiate application-level insights from structural inflection analysis.

Naming Consistency3/5

All names are lowercase snake_case and readable, but the conventions are mixed: noun_verb forms like company_search and news_search, verb_noun forms like run_sql and list_tables, and bare noun phrases like ai_adoption and industry_inflections. A uniform verb_noun pattern would make the toolset more predictable.

Tool Count5/5

Ten tools is well-scoped for a financial data platform: search/discovery tools, filing tools, SQL metadata/execution tools, and a ticker resolver. Each tool earns its place, and there is no obvious redundancy or padding.

Completeness5/5

The toolset forms coherent workflows: ticker_lookup resolves entities, filing_list/filing_search handle SEC filings, list_tables/get_table_schema enable SQL discovery, and run_sql provides broad query coverage across market, fundamental, and alt-data domains. Cross-references between tools explicitly direct agents to the correct next step, leaving no critical dead ends.

Resources