Skip to main content
Glama

research_company

Read-onlyIdempotent

Company research in one call: structured financials, filing-text search per topic, and the analytical profile, run in parallel for one resolved company. Use for broad questions ("tell me about D.R. Horton", "why did KB Home's revenue decline?", "NVIDIA's key risks?"); use the individual tools for one narrow item (just the balance sheet, one filing's text).

Args: company: Name or ticker, fuzzy-matched ("DHI", "Apple"). topics: Filing-text topics to search (max 5; 3 when concise). Default: revenue trajectory, risks, outlook. year: Restrict the filing search to one fiscal year. years: Annual periods of financials (default 3, max 5). concise: Top hit per topic, short snippets, profile overview and risks only (about 70% smaller).

Returns company, financials (by_year, latest_period, data_quality_warnings; the same figures get_company_financials gives; latest_period.metrics_available: false / superseded_period when the newest period has no figures yet), filing_content by topic, profile, sources (cite their citation_markdown), source_policy, summary and integrity_warnings when a block was dropped. year is the fiscal year closing at period_end; period_label reads "FY2025" / "Q3/2025".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "company": "<company>"
    },
    "name": "research_company"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearNo
yearsNo
topicsNo
companyYes
conciseNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds genuinely non-obvious behavior: parallel execution, topic cap of 5 (3 when concise), ~70% size reduction for concise, and degradation signals like latest_period.metrics_available: false, superseded_period, and integrity_warnings when a block is dropped. The Returns paragraph overlaps substantially with the existing output schema, which keeps it from a 5.

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?

Front-loaded with purpose, then cleanly sectioned into Args and Returns, so an agent can skim the parts it needs. The Returns paragraph is the weak spot: it is long and restates structure the output schema already provides, so not every line earns its place.

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?

For a 5-parameter parallel aggregation tool, the description covers invocation (defaults, caps, fuzzy company resolution) and output semantics (data-quality and integrity warnings, superseded periods, citation_markdown on sources). Nothing an agent needs to call it correctly or interpret a degraded result is missing.

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 description coverage is 0%, so the description must carry all five parameters, and it does: company is fuzzy-matched by name or ticker with examples, topics has a max of 5 and stated defaults (revenue trajectory, risks, outlook), year restricts one fiscal year, years defaults to 3 and maxes at 5, concise is defined by what it actually changes. It even clarifies that year means the fiscal year closing at period_end and how period_label is formatted.

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?

States a specific verb+resource with scope: 'Company research in one call: structured financials, filing-text search per topic, and the analytical profile, run in parallel for one resolved company.' It also distinguishes itself from siblings by naming the narrow alternative (individual tools for just a balance sheet or one filing's text).

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?

Gives explicit when-to-use triggers with concrete example questions ('tell me about D.R. Horton', 'why did KB Home's revenue decline?') and an explicit when-not-to-use rule pointing to the individual tools for one narrow item. The routing decision is fully determined without opening another schema.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.