edgar-entity-mcp

Cross-company comparison (XBRL frames)

compare_companies

Read-onlyIdempotent

Rank and compare companies on any XBRL financial concept for a calendar period using SEC data. Filter by tickers/CIKs or view top values.

Instructions

Compare one XBRL concept across ALL reporting companies for a calendar period (SEC frames API), e.g. rank by revenue for CY2024, or compare specific companies. Period: CY2024 (annual duration), CY2024Q2 (quarter), CY2024Q4I (instant, required for balance-sheet items like Assets). Pass companies to filter to specific tickers/CIKs; otherwise returns the top limit by value.

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": {
      "tag": "<tag>",
      "period": "<period>"
    },
    "name": "compare_companies"
  }
}

Input Schema

Name	Required	Description	Default
`tag`	Yes	e.g. 'Revenues', 'NetIncomeLoss', 'Assets'
`unit`	No	USD, USD-per-shares, shares, pure	USD
`limit`	No
`order`	No		desc
`period`	Yes	CY2024, CY2024Q3, or CY2024Q4I
`taxonomy`	No		us-gaap
`companies`	No	Tickers or CIKs to include (default: all)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior, so safety is covered. The description adds useful behavior: period formats, that CY2024Q4I is required for instant balance-sheet items, and the default return rule (top limit by value unless companies filters). It omits error handling, rate limits, and authentication details.

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?

Single tightly written paragraph, front-loads purpose, then period formats, then filter and default return behavior. No redundant or filler sentences.

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 7-parameter read-only comparison tool with no output schema, the description covers purpose, period formats, filtering, and default return ordering adequately. It leaves output structure and taxonomy/unit nuances to the schema, but core invocation requirements are clear.

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 57%, and the description adds meaning beyond the schema for period syntax, tag examples, companies filtering, and limit/order return behavior. It does not clarify unit, taxonomy, or order defaults, which remain schema-only.

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 and resource: comparing one XBRL concept across all reporting companies for a calendar period. It gives concrete examples (rank by revenue for CY2024; compare specific companies) and distinguishes cross-company scope from siblings like get_xbrl_concept. An agent can identify the tool without opening the schema.

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?

Provides clear context: use for cross-company comparison of a single XBRL concept, with examples and period syntax. It explains filtering behavior via companies or the default top-limit ranking. However, it does not name alternatives such as get_xbrl_concept or get_financials, nor state when not to use this tool.

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

Deploy Server