filings-intel-mcp

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

Describes the output comprehensively but does not explicitly state that the operation is read-only or non-destructive. However, the description is accurate and covers the tool's behavior well given no 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?

Two sentences: first sentence states purpose and output, second gives usage guidance. Each sentence is essential and there is no redundancy.

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 annotations and no output schema, the description provides all necessary information: input, output fields, and usage context relative to sibling tools. Complete for a simple lookup 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?

Schema coverage is 100% and the schema already describes the 'query' parameter well. The description adds no further parameter-level detail beyond restating the input types.

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 the verb 'resolve' and the resource 'stock ticker or company name to SEC identity', listing specific output fields. Distinguishes from siblings by advising to start here before other calls.

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 tells the agent when to use this tool: 'Start here before other Filings Intel calls.' This provides clear context and direction for the workflow.

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

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

No annotations provided, and description only states it returns matching filings. Does not disclose rate limits, auth needs, side effects (though likely read-only), or any limitations like pagination or maximum results.

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?

Two well-structured sentences front-loading the main action and return fields. No wasted words, but could optionally mention the missing limit parameter briefly.

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?

Adequate for a search tool: states what it searches, what it returns, and optional filter. However, lacks details on output order, pagination, or error behavior. No output schema, so description carries burden, but is sufficient for basic use.

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 67%, missing description for 'limit'. The tool description does not compensate for this gap—'limit' is not mentioned. Description only restates schema info for form_type.

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?

Description clearly states it performs full-text search across EDGAR filings for keywords, and distinguishes from sibling tools like company_lookup or recent_filings by specifying its unique scope and return fields.

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?

Implies usage for keyword searches in filings, but lacks explicit guidance on when not to use or how it compares to siblings. No prerequisites or alternatives mentioned beyond the tool's purpose.

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

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

No annotations are provided, so the description carries the full burden. It implies a read operation ('Get reported financial facts') but lacks details on idempotency, auth requirements, rate limits, error handling, or data freshness. More explicit behavioral context is needed.

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 a single, dense sentence that front-loads the purpose. It is reasonably concise but could be broken into multiple sentences for easier parsing.

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

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

Given the tool's simplicity (2 params, no output schema, no annotations), the description covers core functionality adequately. However, it omits details about output format, error cases, and how it differs from sibling tools, which limits 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?

Schema coverage is 100%, but the description adds value by explaining the usage pattern: without 'concept', returns most recent values; with 'concept', returns full history. It also lists example us-gaap concepts, supplementing 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 retrieves financial facts (revenue, net income, etc.) from XBRL filings for a company. It distinguishes itself from siblings by focusing on financial data, not company lookup or insider transactions.

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 implies usage: use for key financial metrics, with an optional concept for full history. However, it does not explicitly state when to use alternatives or when not to use this tool, leaving cross-tool guidance implicit.

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

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

No annotations present, so description carries full burden. Describes it as listing 'recent' filings with dates/links, which is safe but lacks details on pagination, rate limits, or idempotency. No contradictions since no annotations exist.

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?

Two sentences, front-loaded with core purpose. Every clause adds value: specifies form types, submitters, and return fields. No redundant phrases.

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, but description declares return fields (dates, links) and scope (recent). Could mention if results are paginated or if there's a maximum limit, but adequately covers typical expectations for a list endpoint.

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 has 50% coverage: 'query' is described as 'Ticker, name, or CIK' in schema. Tool description does not add new meaning beyond what schema provides. 'limit' parameter gets no additional context; default is already in schema. Baseline of 3 appropriate.

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?

Uses specific verb 'List' and resource 'insider ownership filings (Form 3/4/5)'. Clearly distinguishes from sibling tools like 'filing_search' which covers broader filings, and 'recent_filings' which may include all types. States exact purpose and outputs.

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?

Implies usage for insider transactions but offers no explicit guidance on when to use this vs. siblings like 'company_lookup' or 'financials'. Does not mention when not to use or provide exclusion criteria.

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

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

No annotations are provided, so the description must convey behavior. It states outputs (filing dates, direct document links) but omits ordering (presumably most recent), pagination, or rate limits. The examples of form types help, but the behavior around the 'limit' parameter and result set completeness is unclear.

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 a single concise sentence that conveys purpose and options. It front-loades the verb and resource, then specifies form types and the optional filter. No extraneous words, though it could be slightly more structured with bullet points.

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 should detail return fields beyond filing dates and links (e.g., form type, company name). It does not mention result ordering, pagination, or error cases (e.g., invalid query). For a listing tool, this is insufficient for an agent to fully understand the response format.

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

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

Schema coverage is 67%, so the description partially supplements. It lists example form types (10-K, 10-Q, etc.) which duplicate the schema description of form_type. No extra context for 'query' beyond 'ticker, name, or CIK'. The 'limit' parameter lacks description entirely. The description adds minimal value over 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 lists a company's most recent SEC filings with filing dates and links. It specifies supported form types (10-K, 10-Q, 8-K, S-1) and distinguishes itself from sibling tools like filing_search (which likely does broader search) and company_lookup (which resolves names).

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?

No guidance on when to use this tool versus alternatives like filing_search or financials. It does not mention prerequisites or limitations (e.g., only recent filings, not historical search). The user must infer context from sibling tool names.

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