arelle-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.1.0
Disambiguation3/5
Several tools have overlapping purposes (e.g., multiple fact extraction tools like xbrl_extract_facts, xbrl_fact_details, xbrl_company_facts), and the distinction between them may not be immediately clear to an agent. However, each tool has a specific use case described, reducing ambiguity somewhat.
Naming Consistency4/5
All tools start with 'xbrl_' and use snake_case, providing a consistent prefix. However, the naming pattern mixes verb-first (e.g., xbrl_load_filing) and noun-first (e.g., xbrl_anomaly_detection) approaches, leading to minor inconsistency.
Tool Count3/5
With 46 tools, the server is on the high end of tool counts. While the XBRL domain is complex and justifies many tools, there is some redundancy (e.g., multiple export formats) that could be consolidated.
Completeness4/5
The tool set covers a wide range of XBRL operations: loading, browsing, extraction, validation, comparison, and EDGAR-specific features. Minor gaps exist, such as no direct tool for modifying metadata, but overall the surface is comprehensive for its domain.
Average 3.8/5 across 46 of 46 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds minimal behavioral context beyond 'extract' and 'returns tables', which is consistent with annotations. No contradiction, but the description does not disclose potential pitfalls like missing tables or performance.
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 very concise, consisting of 3 sentences plus an args/returns line. It is front-loaded with the clear purpose. Every sentence adds some information, though the args list is redundant with the schema. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description only says 'Returns: str: JSON with table data', which is vague. It does not explain what structured row/column data means, error handling, or prerequisites (e.g., filing must be loaded). The tool has moderate complexity with filtering and limits, but the description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 compensate. It only lists parameter names ('Filing ID, optional search filter, table index, limits') without adding meaning. For instance, it omits that 'filing_id' must come from xbrl_load_filing, or that 'table_index' is 0-based. The schema does have some descriptions, but the description provides no added value.
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 'Extract HTML tables from the filing document' and 'Finds tables in the HTML content', clearly identifying the verb and resource. It distinguishes from siblings like xbrl_extract_facts and xbrl_get_raw_xml by focusing on HTML tables, but does not explicitly compare with xbrl_get_footnotes or similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional text search filter, table index, and limits, but provides no guidance on when to use this tool versus alternatives (e.g., xbrl_extract_text or xbrl_get_footnotes). There is no 'when not to use' or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that the tool returns a list of documents with types, sizes, and URLs, which is useful but does not cover error scenarios or output format details beyond a generic 'JSON' mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an 'Args:' and 'Returns:' section that are not well structured or formatted. While concise, it could be more organized and front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (listing document index) and the presence of annotations but no output schema, the description lacks detail on the return structure, pagination, or limitations. It is not fully complete for an agent to confidently invoke without prior knowledge.
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?
The input schema has 0% description coverage (only minimal field descriptions). The description merely restates 'CIK and accession number' without providing format details, examples, or usage notes, failing to compensate for the schema's lack of explanation.
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 clearly states the tool retrieves the full index of documents within a specific SEC filing, listing exhibits, schemas, instances, and other documents with types, sizes, and URLs. It uses a specific verb and resource, differentiating from siblings like xbrl_get_exhibits and xbrl_list_filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. It only implies that a valid CIK and accession number are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, non-destructive, and idempotent. The description adds that it reports mismatches but does not elaborate on side effects or error handling. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear one-sentence purpose, followed by a brief explanation and parameter list. The Args/Returns section adds only minor redundancy, but overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown), so return values are covered. However, the description lacks context for prerequisites (e.g., filing must be loaded via xbrl_load_filing), error conditions, or edge cases. Given the complexity of XBRL calculations, more guidance would be beneficial.
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?
The description merely lists parameter names from the schema ('Filing ID, optional concept filter, max results') without adding semantic meaning. Despite context indicating 0% schema description coverage, the description does not compensate by explaining parameter formats, defaults (max_results default=20, max=100), or how concept_name filters.
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 clearly states the tool verifies calculation consistency for totals and components, using specific verbs like 'verify' and 'compares'. It distinguishes from many sibling tools (e.g., xbrl_validate, xbrl_run_formula) by focusing on calculation relationships, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for calculation verification, but it does not explicitly state when to use it versus alternatives like xbrl_validate or xbrl_anomaly_detection. No when-not-to-use or prerequisite conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=false, and the description adds no behavioral details beyond stating it creates a new document. Missing info on side effects, overwrite behavior, or resource impact.
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 relatively short (two paragraphs) and includes structured Args/Returns sections. Some ambiguity in return type (XML vs JSON) slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic function and return format but lacks details on error handling, validation, or concurrency. Given the presence of an output schema, the omission of advanced context is acceptable but not exceptional.
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?
The input schema already provides full descriptions for each parameter (schema_ref, entity_id, entity_scheme, facts). The tool description only summarizes them without adding new semantic detail, so baseline score applies.
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 clearly states 'Create a new XBRL instance document from scratch' and details the output (XML as string). It is distinct from sibling tools which are primarily for reading or analyzing existing filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as when to modify an existing instance or when prerequisites are needed. The phrase 'from scratch' implies creation but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, non-destructive, and idempotent behavior. The description adds that it returns JSON with a concept list but does not disclose details like error handling, performance, or pagination. It adds some value beyond 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 short and front-loaded with the purpose, followed by a structured args/returns section. Every sentence is necessary, though it could be more organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and return type, but with many sibling tools, it lacks differentiating context. It does not explain the limit parameter or potential edge cases. An output schema exists, so return values are specified, but overall completeness is adequate.
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?
The input schema has detailed descriptions for each parameter, but the tool description only gives a brief summary. Schema description coverage is 0%, but the schema itself compensates. The description adds little beyond the schema.
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 the tool exports taxonomy concepts as structured data, with a specific verb and resource. However, it does not differentiate from sibling tools like xbrl_export_json or xbrl_concept_details, which may be confused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as xbrl_export_csv or xbrl_concept_details. The description only explains what it does, not the context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it returns liquidity, profitability, leverage, per-share ratios and interpretations. No contradictions, but doesn't disclose potential limitations like data availability for all ratios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively concise but contains an inaccuracy: 'Args: params: Filing ID' incorrectly names the parameter (actual parameter is filing_id inside the params object). This could mislead an AI agent. The structure is otherwise acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present (context signal), the description adequately summarizes return type and content. However, the misnamed parameter and lack of prerequisites details slightly reduce completeness. Adequate for a simple, single-parameter tool with good annotations.
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?
Only one parameter (filing_id) which is already described in the schema as 'The filing_id from xbrl_load_filing'. The description mentions 'params: Filing ID' but misnames the parameter (should be filing_id). It doesn't add meaningful information beyond the schema, but with >80% schema coverage, baseline 3 is appropriate.
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?
Describes computing standard financial ratios from a loaded filing, listing specific categories (liquidity, profitability, leverage, per-share). Verb 'compute' and resource 'ratios' are clear, but it does not explicitly distinguish from sibling analysis tools like xbrl_trend_analysis or xbrl_peer_comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the filing must be loaded via xbrl_load_filing, providing context. However, no explicit guidance on when to use this vs alternatives (e.g., trend analysis, anomaly detection) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by detailing the output format (<4K tokens JSON), content (company info, key metrics, etc.), and focus on LLM efficiency, enriching behavioral context beyond 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 short and front-loaded with the purpose. It includes Args and Returns sections, though the structure could be improved by separating behavior from parameter details. Overall efficient.
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?
Given the tool's complexity (single param, simple output), the description sufficiently covers return format and content. With output schema present, missing details are acceptable. Adequate for agent invocation.
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?
The description only vaguely mentions 'Filing ID and focus area' without elaborating on their semantics or constraints. Despite schema descriptions existing, the tool description fails to compensate for the 0% coverage, offering minimal parameter guidance.
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 ('Generate') and resource ('structured summary of a filing'), and highlights its LLM-optimized compact nature. However, it does not explicitly differentiate from the similar sibling tool 'xbrl_filing_summary', leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions being designed for LLM context windows but provides no guidance on when to use this tool versus alternatives (e.g., xbrl_filing_summary, xbrl_company_facts). No when-not or explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, non-destructive, and idempotent. The description adds no behavioral traits beyond stating it lists items; it does not explain what DTS means or any limitations. It does not contradict 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?
The description is very concise with two sentences plus Args/Returns. The first sentence front-loads the key purpose, and every word serves a purpose with no redundancy.
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 list tool with one parameter and a return string, the description provides essential information: what is listed and the return format. It is mostly complete, though details about the JSON structure could be added. An output schema is not provided, so the description compensates adequately.
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?
The input schema already provides a description for the 'filing_id' parameter ('The filing_id from xbrl_load_filing'). The description's mention of 'Filing ID' adds no new semantic value, so it meets the baseline for adequate schema coverage.
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 clearly states that the tool lists all formulas, assertions, and validation rules in a filing's DTS. It uses a specific verb ('List') and identifies the resource, distinguishing it from sibling tools like xbrl_run_formula and xbrl_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. No exclusions or context for selection are mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds what the output contains (JSON with comprehensive concept information) and does not contradict annotations. No additional behavioral details are provided beyond that.
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 concise with 6 sentences, front-loaded with the purpose. It uses a bullet-like listing for returned information, making it scannable. However, the Args and Returns section could be integrated more seamlessly.
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?
Given the output schema exists, the description adequately covers the return format. It explains the input parameters sufficiently. However, it lacks notes on error handling or cases where the concept is not found, which would improve completeness.
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?
The description mentions 'Filing ID and concept name' as parameters, adding minimal context beyond the schema's nested property descriptions. With 0% schema description coverage (top-level params missing description), the tool description compensates partially but still lacks depth.
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 clearly states the tool gets full details for a taxonomy concept, listing the specific information returned (labels, references, data type, etc.). It distinguishes itself from sibling tools like xbrl_browse_taxonomy or xbrl_fact_details by focusing on comprehensive concept introspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It mentions the required parameters (filing_id and concept_name) but does not indicate when this is preferable to related tools like xbrl_search_sec_concept or xbrl_fact_details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction. The description adds that it uses the presentation linkbase and fills from instance data, but does not disclose error handling, data freshness, or output size constraints.
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 short and front-loaded with the key purpose. However, the Args/Returns section is somewhat redundant given the schema. Overall, it is efficient but not perfectly 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?
Given the tool's moderate complexity and the presence of output schema (not shown but indicated), the description covers the main purpose, inputs, and output format. It could mention that the output is a formatted string, but it's sufficient for an agent to use correctly.
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?
The input schema already contains detailed descriptions for each parameter (e.g., statement type options, format). The tool's description merely repeats 'Filing ID, statement type, and format', adding no new semantic information beyond the schema. Schema coverage is effectively high, so baseline 3.
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 clearly states 'Render financial statements' and lists specific types (balance sheet, income statement, etc.), making the purpose clear. However, it does not explicitly differentiate from sibling tools like xbrl_smart_summary or xbrl_financial_ratios, which may also produce financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after loading a filing (mentioning 'filing_id' and 'presentation linkbase hierarchy'), but lacks explicit guidance on when to use this tool vs. other XBRL tools, or any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds the types of anomalies checked and the return format (JSON with list, severity, descriptions). However, it does not disclose additional behaviors like rate limits, authorization needs, or potential side effects beyond what annotations cover.
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 concise, with a clear list of checks and a structured Args/Returns format. The line 'Args: params: Filing ID.' is somewhat redundant but does not harm readability significantly.
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?
Given the tool's complexity (multiple anomaly checks) and the presence of an output schema (declared but not shown), the description covers the inputs, outputs, and key behaviors. It could be improved by specifying the output schema structure more precisely, but overall it provides sufficient context for an agent.
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?
Context indicates 0% schema description coverage, so the description must compensate. It states 'Filing ID' but is redundant with the schema's description 'filing_id from xbrl_load_filing'. It adds no extra meaning or format details, leaving the parameter underdefined.
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 clearly states it detects unusual patterns in filings and lists specific checks (negative values, extreme changes, calculation mismatches, missing concepts, zero values). This distinguishes it from sibling tools like xbrl_validate or xbrl_check_calculations, which focus on validation or calculation verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage after loading a filing (since it takes a filing_id), but does not mention scenarios where other tools should be preferred or provide decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. The description adds context about returning every value across periods/dimensions plus taxonomy definition, and specifies the return format as JSON.
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 concise, front-loaded with the purpose, and uses clear, structured language with no extraneous content.
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 covers input, output, and behavior adequately. With an output schema present, the return details are sufficiently described. Minor omission of performance considerations.
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?
Despite schema coverage being 0% per context, the description only briefly mentions 'Filing ID and concept name' and omits the optional period filter. The schema provides full descriptions, so the description adds little value.
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 clearly states the tool retrieves comprehensive details for a concept across all periods and dimensions. It distinguishes from siblings like xbrl_concept_details and xbrl_company_facts by emphasizing scope, but does not explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing all facts for a specific concept, but provides no explicit guidance on when to prefer this tool over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate openWorldHint=true and readOnlyHint=false, suggesting possible side effects. The description discloses the optional loading of the filing for analysis, which implies a state change. However, it does not detail what 'loading' entails (e.g., memory, workspace), nor does it mention permissions or rate limits, leaving some behavioral ambiguity.
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 concise, uses a clear structure (summary line, paragraph, Args/Returns), and avoids unnecessary text. It is front-loaded with the main action and includes all key elements, though the Args section could be slightly more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers the main purpose and parameters adequately. However, it omits error scenarios (e.g., filing not found, ticker resolution failure) and prerequisites (e.g., API key), leaving completeness gaps for a tool with multiple sub-parameters and potential edge cases.
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?
The input schema provides detailed descriptions for each parameter (cik, ticker, filing_type, date, load_filing). The tool description adds that one of cik/ticker must be provided and ticker auto-resolves, which adds semantic value beyond the schema. However, with schema coverage effectively high (descriptions present), baseline is 3, and the added value is modest.
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 clearly states the tool fetches an SEC EDGAR filing by CIK or ticker, specifies filing type, and returns metadata. It uses a specific verb (Fetch) and resource (SEC filing), distinguishing it from siblings like xbrl_list_filings or xbrl_company_facts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that either cik or ticker must be provided and that ticker resolves to CIK automatically, giving basic usage constraints. However, it does not compare this tool to alternatives (e.g., when to use list_filings instead) or provide when-not scenarios, which limits guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds minimal behavioral context (returns JSON, takes args). It does not contradict annotations, but does not provide additional behavioral insights beyond what annotations declare.
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 concise (8 lines), well-structured with a header sentence, context paragraph, and parameter listing. Every sentence serves a purpose without redundancy or verbosity.
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 covers the tool's purpose, input parameters (briefly), and return format. Schema provides detailed param descriptions, and an output schema exists (not shown but noted). Missing are prerequisites (e.g., use after xbrl_load_filing, though implied by filing_id description) and error handling, but overall completeness is high for a simple read tool.
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?
Schema descriptions already cover all parameters (filing_id, concept_name, limit) with clear descriptions. The tool description merely repeats a summary of args (filing ID, optional concept filter, limit) without adding new meaning. Baseline 3 is appropriate given schema coverage.
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 clearly states 'Extract footnotes linked to XBRL facts' with a specific verb and resource. It adds context about the purpose of footnotes in XBRL and distinguishes the tool from siblings by focusing solely on footnote extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not provide guidance on when to use it versus alternatives (e.g., xbrl_extract_facts for all facts). No when-not or alternative tool mentions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description adds useful but limited context: it specifies the source forms (3, 4, 5) and return fields (filer name, form type, filing date). However, it does not discuss pagination, rate limits, or the meaning of 'recent'.
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 concise with three short paragraphs, avoiding fluff. It front-loads purpose, then output details, then args/returns. Could be more structured but efficient.
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 1-parameter tool with annotations and an output schema, the description covers the essential aspects: source, input (CIK, limit), and output fields. It does not clarify 'recent' or date ranges, but overall sufficient.
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 description coverage is 0% for the top-level 'params' parameter, so the description must compensate. It states 'Args: params: Company CIK and limit' and describes output fields. This adds high-level meaning but does not detail the exact format or constraints already in the schema.
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 clearly states 'Get insider trading data from SEC Forms 3, 4, 5' with a specific verb and resource, and distinguishes from sibling tools like xbrl_edgar_company_info by focusing on insider trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus sibling tools such as xbrl_edgar_search or xbrl_edgar_filing_index. No when-not-to-use or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it returns a JSON array of serialized facts but does not elaborate on aspects like performance impact, concurrency, or error handling. The description is consistent 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is 4 lines, front-loading the main purpose. No wasted words, but the Args/Returns structure could be more compact. Still efficient and clear.
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?
Given the tool has an output schema (though not shown), the description specifies the return type as 'str: JSON array of serialized facts', which is sufficient. The tool is straightforward and the description covers its role and output format adequately.
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?
The tool's description summarizes the params argument as 'Filing ID, filters, and limit', which is vague. However, the input schema provides detailed descriptions for each nested property (filing_id, include_dimensions, numeric_only, limit). Since schema coverage is effectively 100% via schema descriptions, the description adds minimal value, scoring 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?
Description states 'Export all facts from a filing as structured JSON', which is a specific verb-resource pair and clearly distinguishes from sibling tools like xbrl_export_csv or xbrl_export_concepts by specifying the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions 'suitable for data pipelines, database import, or further processing', giving context but does not explicitly contrast with alternatives (e.g., xbrl_export_csv) or state when not to use. No exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. Description adds context about period count per filing type, which is useful but does not disclose any behavioral traits beyond annotations. No contradiction found.
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?
Description is concise, front-loaded with purpose, and structured clearly with Args and Returns sections. No redundant words or 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?
Given the moderate complexity, annotations cover safety, and output schema likely documents return structure, the description provides essential context (filing types, period count) and clarifies return format (JSON with per-concept period values and changes). Slightly lacking in explaining period granularity, but overall adequate.
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?
With 0% schema description coverage, the description must compensate. It mentions 'Filing ID and list of concepts' and shows default concepts, but does not explain the format of period identification, how changes are computed, or provide details beyond what is in the schema. This is insufficient to fully guide parameter usage.
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?
Description clearly states this tool analyzes trends across periods within a single filing, distinguishing from cross-filing comparison (xbrl_compare_filings) and ratio computation (xbrl_financial_ratios). It specifies filing types (10-K, 10-Q) and what it computes (absolute/percentage changes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies using this tool for intra-filing trend analysis but does not explicitly state when to avoid it or name alternative tools. Agent can infer context but lacks clear exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that the tool loads, validates, and closes in one operation, which is useful but minimal extra behavioral context. No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, followed by behavior, supported systems, and return value. It is mostly concise, though the Args and Returns sections could be trimmed since the schema and output schema already provide that detail.
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?
Given the rich annotations and schemas, the description covers purpose, behavior, parameters, and return values. However, it lacks guidance on selecting this tool over siblings like xbrl_validate_extended, leaving a minor gap in completeness.
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?
The input schema has 100% description coverage for parameters, each with detailed explanations. The description only mentions 'Filing path and validation options' generically, adding no new parameter-level meaning. Baseline 3 is appropriate.
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 clearly states it validates an XBRL/iXBRL filing against a disclosure system. It specifies the verb 'validate' and the resource, and distinguishes itself from siblings like xbrl_load_filing by noting it loads, validates, and closes in one operation. The listing of supported disclosure systems further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool does not require preloading and lists disclosure systems, giving some context. However, it does not explicitly compare to alternatives like xbrl_validate_extended or say when not to use this tool. No prerequisites or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the output (JSON with changes) and input (two filing IDs). No contradictory or hidden behaviors are present.
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 concise, front-loaded with purpose, and includes separate sections for args and returns. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the core purpose and output, it lacks context on when to use this tool over similar siblings (e.g., xbrl_compare_filings) and does not explain the DTS concept. The output schema exists, reducing the need for return value details, but overall completeness is adequate but not thorough.
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?
The description only states 'Two filing IDs' for the params parameter. The schema has 0% coverage for the top-level parameter, and the nested properties have descriptions, but the description does not clarify the parameter structure or roles (baseline vs comparison). This is insufficient to guide an agent.
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 clearly states the tool compares two taxonomy/filing schemas and specifies what is identified (added/removed/changed concepts, relationships, labels). It uses specific verbs and resources, and distinguishes from siblings like xbrl_compare_filings by focusing on structural schema comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing two DTS/filings but does not explicitly mention when not to use or provide alternatives. Given many sibling tools, it would benefit from stating exclusions or similar tools like xbrl_compare_filings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, non-destructive, idempotent operation. The description adds the return format (JSON string of summaries) and the scope 'currently loaded filings', which is helpful. However, it does not disclose edge cases or error behavior.
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 two short sentences with no superfluous words. It front-loads the main action and clearly indicates the return type.
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 tool has no parameters, annotations cover safety, and an output schema exists (context signal). The description provides basic return info, which is sufficient given the available structure. It could be more explicit about what 'basic info' includes, but the output schema likely covers that.
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 tool has no parameters, so the description cannot add meaning beyond what the schema provides. Per the rule, 0 parameters yields a baseline of 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 clearly states the verb 'list all currently loaded filings' and the resource (filings with IDs and basic info). It distinguishes itself from sibling tools that load, close, or summarize individual filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives such as xbrl_filing_summary or xbrl_company_facts. The agent is left to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not contradict them. It adds useful context: that the DTS includes both standard and extension concepts, and that results include pagination info.
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?
Description is two sentences plus an Args/Returns block. It is front-loaded with the core purpose. The Args/Returns section is slightly redundant given the schema, but not overly verbose.
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?
Given the tool's complexity (multiple filters, nested params), the description adequately explains scope and return format. Annotations cover safety and idempotency. The required filing_id is explained in the schema description.
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?
Schema descriptions already cover each parameter (filing_id, search, concept_type, etc.). The description merely summarizes filters as 'name, type, namespace, or whether concepts have facts', adding no new semantic detail beyond the schema.
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?
Description clearly states 'search and browse concepts in the filing's taxonomy (DTS)', specifying both the action and resource. It distinguishes from sibling tools like xbrl_concept_details or xbrl_search_sec_concept by focusing on the filing's own taxonomy set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage (filtering concepts) but provides no explicit when-to-use or when-not-to-use compared to alternatives. No exclusions or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by specifying the exact memory freed (30-60MB per filing). Annotations already indicate destructiveHint=true and idempotentHint=true, but the description provides specific impact details. It does not mention idempotency explicitly, but the annotations cover that.
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 extremely concise: two sentences plus Args/Returns. Every sentence adds value, with no wasted words. The main action and key outcome are front-loaded.
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 close operation with one parameter and an output schema, the description covers purpose, memory impact, and return type. It omits error cases or prerequisites (e.g., filing must be loaded), but annotations and schema provide some context. Overall, it is sufficiently complete for the tool's complexity.
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%, yet the tool description only repeats schema info ('params (FilingIdInput): The filing_id to close') without adding new semantics. The schema already describes the filing_id parameter, so the description fails to compensate for the low coverage.
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 clearly states the action 'close a loaded filing' and highlights the key benefit of freeing memory (30-60MB). This distinguishes it from sibling tools like xbrl_load_filing and xbrl_filing_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after loading a filing to free memory, but does not explicitly state when to use or not use this tool, nor mention alternatives. The context from siblings suggests a cleanup role, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds context about the return format (JSON) and the conceptual explanation of dimensions, 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 concise with 5 sentences, front-loading the main purpose and including an example. It could be slightly trimmed but is well-structured and efficient.
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?
Given the complexity of XBRL dimensions and the presence of an output schema, the description adequately explains the concept, input, and return format. Minor gaps like performance implications are not critical for a read-only tool with idempotentHint.
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?
Schema description coverage is 0% at the top level, but individual parameters in the schema have detailed descriptions (filing_id, dimension_name, max_members). The description restates 'Filing ID and optional dimension filter' without adding new semantic meaning beyond what the schema provides. Baseline 3 is appropriate.
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 clearly states 'Get the dimensional structure of a filing,' which is a specific verb and resource. It explains XBRL Dimensions, mentions returns (hypercubes, dimensions, axes, domains, members), and gives an example with ProductOrServiceAxis. This distinguishes it from sibling tools like xbrl_presentation_tree or xbrl_calculation_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving dimensional breakdowns but does not explicitly state when to use this tool versus alternatives. No exclusions or comparisons with siblings are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is read-only, non-destructive, and idempotent. The description adds context about full-text search and the JSON return format, which goes beyond annotations. However, it does not disclose pagination, rate limits, or behavior for empty queries, though these are partially covered by schema constraints.
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 concise, front-loads the main purpose, and includes structured Args/Returns sections. Every sentence adds value with no redundancy.
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?
Given the presence of an output schema and detailed input schema, the description adequately covers the tool's purpose and return format. It mentions optional filters and limits, which is sufficient for a search tool, though it could note result ordering or default sorting.
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 description coverage is 0% at the top level, but nested parameters have good descriptions. The tool description summarizes 'Search query, optional type/date filters, limit,' adding meaning beyond the schema by grouping and clarifying purpose. This compensates for the lack of a top-level description.
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?
Description clearly states it performs full-text search across SEC EDGAR filings by company name, keyword, or content, and returns matching filings with metadata. The title annotation 'Search SEC EDGAR' reinforces this, but it does not explicitly distinguish from siblings like xbrl_search_text or xbrl_edgar_bulk_facts, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for searching filings but provides no explicit guidance on when to use this tool versus alternatives. No when-not or exclusions are mentioned, so the agent must infer usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, non-destructive, and idempotent. The description adds no behavioral contradictions and confirms it returns a JSON list, but does not provide additional behavioral context beyond what annotations and the return type convey.
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 concise (6 lines) with clear sections for Args and Returns, and no unnecessary words. Every sentence adds value.
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 tool's simplicity (1 param, good annotations, output schema exists), the description covers the purpose, input, and output completely. No additional context is needed.
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?
The single parameter (filing_id) already has a description in the schema ('from xbrl_load_filing'). The description only repeats the parameter name without adding new semantics, so the description adds no value beyond the schema.
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 explicitly states 'Export the Discoverable Taxonomy Set (DTS) document map' and lists what it contains (schemas, linkbases, instance documents). This clearly distinguishes it from many sibling export tools (e.g., xbrl_export_concepts, xbrl_export_csv) which export different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (when needing the DTS document map) but lacks explicit guidance on when not to use or alternatives. No sibling tool directly competes, so the purpose is clear, but no comparative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds value by specifying that it returns all DEI facts as a JSON string, giving clear behavioral expectations. No contradictions 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?
The description is two sentences plus an Args/Returns section, all front-loaded with the primary purpose. It is concise and efficient, with no wasted words.
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?
An output schema exists (context says true), so the description need not detail return structure. It mentions the return type and content. However, it does not explicitly state the prerequisite that the filing_id comes from xbrl_load_filing, which the schema does. Overall, it is largely complete for a simple retrieval tool.
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?
The input schema has a description for the nested parameter 'filing_id' stating 'The filing_id from xbrl_load_filing'. The tool description merely says 'Filing ID', which adds no new meaning. With schema description coverage reported as 0%, the description fails to compensate, leaving the parameter's semantics underspecified.
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 clearly states the tool extracts complete cover page data (DEI facts) from a filing, listing specific data points like company name, CIK, ticker. It distinguishes itself from siblings by focusing specifically on 'cover page' data, which no other tool explicitly does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool over alternatives, such as xbrl_filing_summary or xbrl_get_exhibits. It implies usage for cover page extraction but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context by specifying the types of assertions run and the return format (pass/fail JSON). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short paragraphs; it front-loads the main purpose. The 'Args:' section is slightly redundant given the schema, but overall efficient.
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 covers what the tool does, the types of assertions, and the return format. With an existing output schema and rich annotations, this is sufficient for an agent to use the tool correctly. Could explicitly mention that the filing must be loaded first, but it's implied by the filing_id parameter.
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?
Although context signals indicate 0% schema description coverage, the input schema actually includes descriptions for both filing_id and trace. The description only briefly mentions 'Filing ID and trace option', adding little beyond the schema. Baseline of 3 is appropriate per guidelines.
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 clearly states the action ('Execute XBRL formulas') and the resource ('defined in the filing's linkbase'), and specifies the types of assertions (value, existence, consistency). It distinguishes from sibling tools like xbrl_list_formulas (which lists formulas) and validation tools like xbrl_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after loading a filing, but does not explicitly state when to use this tool versus alternatives like xbrl_validate or xbrl_list_formulas. There is no guidance on exclusions or prerequisites beyond the parameter description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only, non-destructive, idempotent behavior. The description confirms read-only access and adds that the tool returns a JSON string with trees, weights, and components. No contradictions.
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 brief, front-loaded with the purpose, and structured with an example and return type. Every sentence adds value with no redundancy.
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?
Given the complexity of XBRL calculation trees, the description explains the concept and return format. The output schema likely covers the JSON structure, so the description is sufficient. No critical gaps identified.
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?
The schema already documents each parameter well (filing_id, concept_name, role_filter). The description adds the weight explanation (+1/-1) not in schema, but otherwise adds little beyond what schema provides. Schema coverage is high, so baseline 3 is appropriate.
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 clearly states 'Get calculation relationships showing how totals are computed' with an explicit example (Assets = CurrentAssets + NoncurrentAssets). This distinguishes it from siblings like xbrl_presentation_tree and xbrl_check_calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding calculation relationships but lacks explicit when-to-use or when-not-to-use guidance. No mention of alternatives, though sibling tool names suggest other relationship types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: returns most recent value, no filing load required. Annotations already declare readOnly, idempotent, openWorld. Description does not contradict annotations and adds useful output format info.
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?
Extremely concise: two sentences plus a docstring that front-loads purpose. No wasted words.
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?
Covers input, output format, and behavioral nuance (no filing load). Has output schema, so return value description is sufficient. Could mention limitations like max 10 items, but not essential.
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?
Schema has descriptions for ciks and concepts, and description redundantly mentions 'List of CIKs, list of concepts, taxonomy'. Since schema description coverage is actually high (despite 0% signal), the description adds marginal value. Baseline 3 applies.
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 verb (download), resource (fact data for multiple concepts and companies), and output (matrix of company × concept with most recent value). Distinguishes from siblings like xbrl_company_facts which is likely single-company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context ('No filing load required') hinting at when to use, but lacks explicit when-to-use vs alternatives like xbrl_company_facts or xbrl_edgar_search. No when-not or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, non-destructive, and idempotent. The description adds value by detailing the output structure (JSON with specific fields) and input options (CIK or ticker), without contradicting annotations. One could note that auth or rate limits are not mentioned, but the safety profile is clear.
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 short, structured with clear sections (Returns, Args, Returns), and every sentence adds value. No superfluous words. It is efficiently front-loaded with the main purpose.
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?
Given the tool's simplicity and presence of an output schema, the description provides sufficient context: input options, return fields. It could mention reliance on SEC EDGAR, but overall it adequately completes the understanding for an agent or user.
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?
The description mentions 'CIK or ticker' as input, which maps to the two schema properties. Although the schema also provides descriptions ('SEC CIK number', 'Stock ticker symbol'), the description clarifies that either can be used. With schema coverage reported as 0%, the description partially compensates but lacks detail on formats or mutual exclusivity.
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 clearly states the tool retrieves a comprehensive company profile from SEC EDGAR, listing specific return fields (name, CIK, SIC code, etc.). This distinguishes it from sibling tools like xbrl_company_facts (which gets facts) and xbrl_edgar_search (broader search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs. alternatives. While the listed return fields imply usage for basic company info, no when-not or alternative guidance is provided, which is less helpful given the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds that it returns a CSV string and allows customizable columns, which is useful behavioral context beyond the 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 short (three sentences) and front-loads the purpose. However, the args line is somewhat vague (e.g., 'filters' not directly matching the schema's parameter names). Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the output format and parameters, but it does not explicitly note that the filing_id comes from xbrl_load_filing or the default limits (max 5000 rows). Given the many siblings, more contextual details would improve completeness.
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?
The input schema provides detailed descriptions for each parameter (e.g., 'The filing_id from xbrl_load_filing', 'Columns to include'). The tool description only lists parameter names without adding meaning beyond the schema, which already covers them well.
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 clearly states the verb 'Export', the resource 'facts', and the format 'CSV', distinguishing it from sibling tools like xbrl_export_json (JSON) and xbrl_export_concepts (concepts). The phrase 'for spreadsheet analysis' adds context.
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 implies when to use the tool (for spreadsheet analysis) but does not explicitly state when not to use it or name alternatives like xbrl_export_json or xbrl_export_concepts. Some context is provided, but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that results are paginated and include full fact details, which complements annotations but doesn't significantly expand beyond them.
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?
Description is well-structured with paragraphs for overview, filtering, and returns. It is concise without being terse, though could be slightly more compact.
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 tool's complexity (many filters, pagination) and the presence of an output schema, the description sufficiently covers what the tool does, its prerequisites, and the expected output format.
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?
Schema descriptions cover all parameter details (coverage is high), so the description adds no additional parameter-level info. Baseline 3 is appropriate.
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 clearly states the tool extracts and filters XBRL facts from a loaded filing, specifying verb, resource, and precondition. It distinguishes from siblings by focusing on filtering and pagination.
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?
Explicitly states prerequisite (filing must be loaded with xbrl_load_filing). Does not explicitly exclude scenarios or mention alternatives, but the precondition is a strong usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, destructiveHint, and idempotentHint. The description adds the return format (JSON string) and a list of included metadata fields, enhancing transparency without contradiction.
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 efficient: a one-sentence purpose, a bullet list of returned fields, and a clear Args/Returns format. No superfluous content.
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?
The description fully covers the tool's action, input, and output. Given the output schema exists, the list of metadata fields is sufficient for an agent to understand the return value.
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%, yet the description merely restates the schema's description for the only parameter ('filing_id from xbrl_load_filing'). It adds no new semantic value.
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 clearly states the tool retrieves detailed metadata about a loaded filing and lists specific attributes (entity name, CIK, etc.), differentiating it from sibling tools like xbrl_smart_summary or xbrl_fact_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after loading a filing but does not explicitly contrast with alternatives among the many sibling tools. It lacks when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context that the tool returns a JSON list with types and descriptions, and that the input 'filing_id' comes from xbrl_load_filing. No contradictions found.
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 concise with no redundant sentences. It front-loads the main purpose and provides essential details in a clear, structured format.
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 tool with good annotations and an output schema, the description sufficiently covers the input requirement and the return format. It doesn't detail the output schema but the context confirms one exists.
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?
The schema already documents the required 'filing_id' parameter with a description linking it to xbrl_load_filing. The description's 'Args: params: Filing ID' adds little beyond the schema. Schema coverage is effectively 100% despite the context signal of 0%, so baseline 3 is appropriate.
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 clearly states 'List exhibits attached to a filing' with examples of exhibit types like press releases and certifications. The title 'List Filing Exhibits' reinforces the purpose. It effectively distinguishes from sibling tools by specifying the exact action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after loading a filing but lacks explicit guidance on when to use this tool versus alternatives like xbrl_get_cover_page or xbrl_list_filings. No when-to-use or when-not-to-use conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent; description adds that positions are approximate and output is a JSON string with titles, positions, and sizes, providing additional behavioral details.
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 concise with three clear sections: bold statement, explanation, and structured args/returns. Each sentence adds value, though the args section is minimal.
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?
Combined with annotations and output schema description, the tool is well-documented. It covers input, output, and use case, but lacks edge cases or error conditions.
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?
The description only restates 'Filing ID' for the parameter, adding no extra meaning. Schema coverage is 0%, so the description fails to compensate with format or origin details.
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 clearly states it maps document structure and identifies major sections with positions and sizes, distinguishing it from sibling tools like presentation or calculation trees.
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 mentions usefulness for navigating large 10-K/10-Q documents, providing context. However, it doesn't explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which cover safety and idempotency. The description adds 'No filing load required' and 'Returns a ranked list,' confirming read-only behavior and output format. No contradictions exist, and the description adds modest behavioral context beyond 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 concise, with a clear header sentence, a useful behavioral note ('No filing load required'), and a bullet-like listing of args and returns. It is appropriately sized and front-loaded, though the arg list could be integrated more elegantly. No unnecessary 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?
Given the tool's complexity and the presence of an output schema, the description provides sufficient context: the API source, the output format (JSON with ranked list), and key behavioral trait (no filing load). It is complete for a read-only comparison tool, though it could mention potential error conditions or required permissions (e.g., valid period format).
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% for the top-level parameter, and the description only lists parameter names without adding meaning. While the nested schema includes some descriptions (e.g., concept, period format), the description does not compensate for the low coverage. It merely repeats parameter names, offering no additional clarification or examples.
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 clearly states the tool's purpose: 'Compare a concept across multiple companies using SEC EDGAR Frames API.' It specifies the action (compare), the resource (concept across companies), and the output (ranked list). This distinguishes it from sibling tools like xbrl_company_facts (single company facts) or xbrl_compare_filings (compare whole filings).
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 includes a key usage hint: 'No filing load required,' which informs when to use this tool (for quick cross-company comparisons without loading filings). It implies this tool is for high-level comparisons using pre-aggregated data. However, it does not explicitly state when not to use it or list alternatives, missing an opportunity for clearer guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds return format details (categorized results with severity filtering) but does not disclose any additional behavioral traits beyond these annotations. Value added is marginal.
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 concise (5 lines), front-loads the purpose, lists checks, then args and returns. No extraneous information. Efficient and well-structured.
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?
Given complexity and the presence of an output schema, the description adequately explains returned format. However, it lacks differentiation from the sibling 'xbrl_validate' tool and does not mention prerequisites (e.g., needing a loaded filing). Slightly incomplete.
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 description coverage is reported as 0% (though schema has descriptions), so the description carries the burden. It summarizes args (filing ID/path, checks, severity filter) and adds return context not in schema. However, it does not detail individual parameter formats beyond what the schema 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 clearly states 'Extended validation with granular control over which checks to run' and lists supported checks (xbrl21, calculations, etc.). This distinguishes it from the simpler 'xbrl_validate' sibling tool and other validation-related tools, providing a specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for extended validation but does not explicitly contrast with 'xbrl_validate' or other sibling tools. No guidance on when not to use or alternatives is provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, open-world. The description adds that it doesn't require a prior filing load and returns a summary, which is consistent and adds context.
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?
Three concise paragraphs: purpose, return summary, and args/returns documentation. Front-loaded with the main action. No wasted words.
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?
Output schema exists, so return details are not needed. Description adequately explains purpose and behavior. However, given many siblings, a brief note on when to use this vs. other XBRL tools would increase completeness.
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?
Schema descriptions cover parameters well (cik, concept_filter, limit). The description adds minimal parameter info beyond schema, but does not compensate for the 0% coverage in the schema commentary (though schema actually has descriptions). Baseline 3 is appropriate.
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 clearly states it gets all XBRL facts for a company from SEC EDGAR, returns a summary of concepts across all filings, and does not require loading a filing first. This distinguishes it from siblings like xbrl_extract_facts or xbrl_edgar_bulk_facts.
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 explains it does not require loading a filing first, but does not explicitly compare to siblings or state when not to use it. Implicitly it's for broad overview; more explicit guidance would improve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations by clarifying that it extracts human-readable text (not XBRL data) and explaining the max_chars limit. Annotations already indicate readOnlyHint and idempotentHint, which are consistent. No contradictions.
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 well-structured and concise: it leads with the main purpose, lists sections, provides usage context, then specifies args/returns. Every sentence adds value without redundancy.
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?
Given the presence of a detailed input schema and an output schema, the description covers the essential behavior. It explains the type of text extracted and section options but could mention error handling or prerequisites (e.g., filing must be loaded).
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?
While the input schema provides detailed descriptions for each parameter, the tool's description only briefly mentions 'Filing ID, section name, and max characters'. Since schema coverage is effectively high (descriptions in schema), the description adds minimal extra meaning.
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 clearly states it extracts clean text from a specific section of a loaded filing, distinguishes between human-readable text and XBRL data, and lists the exact sections available. It is specific and differentiates from siblings like xbrl_extract_facts (facts) and xbrl_get_raw_xml.
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 provides explicit use cases like MD&A analysis and risk assessment, which guide the agent on when to invoke. However, it does not explicitly state when not to use it or mention alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint; the description adds context about XPath capability, consistent with annotations and not contradictory.
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?
Concise two-paragraph structure with front-loaded purpose, no unnecessary information, and clear Args/Returns format.
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?
Covers main use case and parameters, mentions XPath and return type string; relies on schema for parameter details but lacks error conditions or prerequisites.
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?
The description briefly lists parameters (Filing ID, optional XPath, max chars) but adds no detail beyond what the input schema already provides; however, the schema descriptions are comprehensive.
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 explicitly states it accesses raw XML/HTML and allows XPath queries, distinguishing it as a fallback for advanced extraction not covered by other tools.
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 says it is useful when other tools don't cover a specific need, providing clear context for when to use it as a fallback, though it does not explicitly list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds useful context: it uses the SEC companyconcept API and returns JSON with historical values, periods, and units. No contradictions are present.
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 very concise, at only about 5 sentences. The purpose is front-loaded, and every sentence adds value: specifying the API, what it returns, and the independence from loading a filing.
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 tool has an output schema (mentioned in context), and the description explains the return value as 'JSON with historical values, periods, and units,' which is sufficient. For a moderate-complexity search tool with rich annotations, this description provides complete context for usage without unnecessary detail.
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?
Schema description coverage is 0%, meaning the description does not repeat parameter definitions. The description lists the three required fields (CIK, concept name, taxonomy) in the Args section but lacks detailed syntax, examples, or constraints like the default taxonomy value or format rules. Given the low coverage, the description provides minimal compensation.
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 clearly states it searches SEC EDGAR for a specific XBRL concept across all filings, returning historical values like Assets or Revenue. This is a specific verb+resource combination that distinguishes it from sibling tools like xbrl_concept_details or xbrl_company_facts.
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 explicitly says 'Does NOT require loading a filing first,' providing clear context for when this tool is appropriate. However, it does not explicitly mention when not to use it or name alternatives among the 44 siblings, so it misses some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, etc. Description adds that search is full-text and returns passages with context, aligning with read-only behavior. No contradictions.
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?
Concise three-paragraph structure with clear purpose, usage context, and return type. Every sentence adds value without redundancy.
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?
Covers purpose, scope, parameters, and return type. With output schema present, the description adequately complements structured data, though could benefit from more explicit usage guidance.
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?
Description only lists parameter names ('Filed ID, search query, context size, max results') without adding meaning beyond schema, which already has descriptions for each property (e.g., 'The filing_id from xbrl_load_filing').
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?
Description clearly states 'Full-text search within a loaded filing's content' and specifies it searches entire document text (not just XBRL facts), distinguishing it from other XBRL tools like xbrl_fact_details.
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 context on when to use (searching for guidance, forward-looking statements) and implies scope difference from XBRL-specific searches, but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds that it returns a JSON with values and percentages and accepts an optional dimension filter, providing behavioral context beyond annotations without contradicting them.
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 concise with 6 sentences, well-structured with separate sections for purpose, args, and returns. No unnecessary words or fluff.
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 covers purpose, parameters, and return type. While it could mention that a loaded filing is required (implied by param description), it is otherwise complete for this tool, especially with existing output schema.
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 0% for the top-level 'params' parameter, but the sub-properties have descriptions. The description summarizes the parameters as 'Filing ID, concept name, optional dimension filter,' adding context that compensates for the missing top-level description and clarifying the optional nature of dimension filter.
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 clearly states 'Extract dimensional breakdowns for a concept' and explains that it shows how totals break down by segments, geographies, etc., which distinguishes it from sibling tools like xbrl_fact_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for dimensional breakdowns but does not explicitly state when to use this tool vs alternatives or mention when not to use it. No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. Description adds that the tool returns JSON with added/removed/changed facts and counts, which is consistent and adds value beyond 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?
Very concise: a one-line summary, followed by clear bullet points explaining behavior, use case, prerequisite, args, and return. No redundant information.
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 presence of a detailed input schema and an output schema (as indicated by context signals), the description covers all essential aspects: purpose, prerequisite, input, and return format.
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?
The input schema provides full descriptions for the two filing IDs. The description only rephrases 'Two filing IDs to compare.' With 100% schema coverage, the baseline of 3 is appropriate.
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 clearly states the tool compares two loaded XBRL filings and identifies added, removed, and changed facts. It distinguishes from sibling tools like xbrl_dts_comparison by focusing on fact differences in filings.
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?
Explicitly states prerequisite (filings must be loaded via xbrl_load_filing) and typical use case (analyzing quarterly/annual changes). Does not explicitly list when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about the presentation linkbase and how roles map to statements, which enhances understanding of the tool's behavior beyond the 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?
The description is concise and well-structured: a single-sentence purpose, followed by contextual info, parameter usage, and an 'Args:'/'Returns:' block. No fluff, all sentences add value.
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 input complexity (nested object), the presence of an output schema, and clear annotations, the description adequately covers what the tool does, how to use it, and what it returns. No critical gaps.
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?
Schema description coverage is 0%, but the description explains key parameters: role_filter (substring match examples), max_depth (range and default), and list_roles_only (boolean behavior). However, the filing_id parameter is minimally described, and not all properties are fully detailed.
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 starts with a clear verb+resource statement: 'Get the presentation hierarchy (financial statement structure).' It differentiates from siblings like xbrl_calculation_tree by specifying 'presentation' vs. calculation relationships. Further details on role_filter and list_roles_only solidify purpose.
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 provides guidance on using role_filter to get a specific statement and list_roles_only to see available statements. However, it does not explicitly contrast with similar tools like xbrl_render_statement or xbrl_calculation_tree, leaving some ambiguity about when to prefer this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate not read-only and not destructive. Description adds the entry point behavior and explains return of a filing_id for subsequent use. No contradictions 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?
Concise at 4 sentences, each adding critical information. Front-loaded with action and context, no fluff.
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 many sibling tools, the description adequately positions this as the entry point. Covers input types, return value, and usage order. Output schema exists, so return explanation is sufficient.
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 main parameter 'params' is an object with properties described in the schema; however, schema description coverage is 0% for the top-level. The tool description summarizes the purpose of the parameter and its fields, adding value beyond the schema.
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 it loads XBRL/iXBRL filings, specifies accepted input types (local paths, HTTP/HTTPS URLs, ZIP archives), and describes return value (filing_id and summary). Distinguishes itself from siblings by being the entry point.
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?
Explicitly instructs to call this first before other tools, establishing a clear usage order. Does not mention when not to use or alternative methods for already loaded filings, but entry point status makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Arelle-MCP MCP server](https://glama.ai/mcp/servers/TheKingHippopotamus/Arelle-MCP/badges/card.svg)](https://glama.ai/mcp/servers/TheKingHippopotamus/Arelle-MCP)

Score Badge

Copy to your README.md:

[![Arelle-MCP MCP server](https://glama.ai/mcp/servers/TheKingHippopotamus/Arelle-MCP/badges/score.svg)](https://glama.ai/mcp/servers/TheKingHippopotamus/Arelle-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheKingHippopotamus/Arelle-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server