sec

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool as a read operation ('Get') and specifies the return data, but does not disclose important behavioral traits such as rate limits, authentication requirements, error handling, or data freshness. For a tool with no annotations, this leaves significant gaps in understanding how it behaves in practice.

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

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

The description is front-loaded with the core purpose in the first sentence and efficiently adds details about the return data in the second. It avoids unnecessary words and stays focused on the tool's functionality. However, it could be slightly more structured by explicitly separating usage guidelines or behavioral notes, but overall it is concise and well-organized.

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

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

Given the tool's complexity (single parameter, no output schema, no annotations), the description adequately covers the purpose and return data. However, it lacks details on behavioral aspects like error handling or data scope, and without an output schema, it does not fully explain the structure of returned values. It is minimally viable but has clear gaps in providing a complete context for effective use.

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

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

The input schema has 100% description coverage, with the single parameter 'cik' fully documented in the schema. The description adds minimal value beyond the schema by reiterating the use of CIK but does not provide additional context like format examples or edge cases. Since schema coverage is high, the baseline score of 3 is appropriate, as the description does not significantly enhance parameter understanding.

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

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

The description clearly states the specific action ('Get XBRL financial facts') and resource ('for a company using its CIK number'), distinguishing it from sibling tools like 'get_company_filings' and 'search_companies' by focusing on financial data extraction rather than filings or search. It explicitly mentions the type of data returned ('structured financial data including revenue, net income, total assets, and other reported metrics over time'), making the purpose highly specific and well-defined.

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

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

The description implies usage by stating it retrieves financial facts for a company using a CIK number, which suggests it should be used when detailed financial metrics are needed. However, it does not explicitly state when to use this tool versus alternatives like 'get_company_filings' or 'search_companies', nor does it provide exclusions or prerequisites. The guidance is present but lacks explicit comparison or context for tool selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool returns (filing dates, form types, accession numbers) and mentions optional filtering, which adds useful context. However, it lacks details on rate limits, authentication needs, or pagination behavior, leaving gaps for a mutation-free read operation.

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

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

The description is appropriately sized and front-loaded, with two concise sentences that efficiently convey the tool's purpose and key features. Every sentence earns its place by adding specific information without redundancy.

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

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is mostly complete. It covers the purpose, usage, and return values adequately. However, the lack of output schema means it could benefit from more detail on response structure or error handling, slightly reducing completeness.

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

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

The schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value by reiterating the optional filtering and providing examples (e.g., '10-K'), but does not significantly enhance the parameter semantics beyond what the schema provides, meeting the baseline of 3.

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

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

The description clearly states the tool's purpose with specific verb ('Get') and resource ('SEC filings for a company'), and distinguishes it from siblings by specifying it retrieves filings rather than facts (get_company_facts) or company searches (search_companies). The mention of CIK number and filtering by form type adds specificity.

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

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

The description provides clear context for when to use this tool (to get SEC filings for a company using CIK), and it implies an alternative by mentioning optional filtering by form type. However, it does not explicitly state when not to use it or name specific sibling alternatives, which prevents a score of 5.

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

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

With no annotations provided, the description carries full burden. It discloses the search behavior and that it returns 'matching company names and their CIK numbers', but lacks details on rate limits, authentication needs, result limits, or error conditions that would be helpful for a search tool.

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

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

Two sentences with zero waste: the first states purpose and parameters, the second explains the return value and its downstream use. Every element serves a clear purpose in helping the agent understand and use the tool.

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

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

For a single-parameter search tool with no annotations and no output schema, the description provides adequate context about what it does and why the output matters. It could be more complete by mentioning result format or limitations, but covers the essentials given the tool's relative simplicity.

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

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

Schema description coverage is 100%, so the schema already documents the single 'query' parameter thoroughly. The description adds minimal value beyond the schema by mentioning 'name or ticker symbol' and the example format, which is already covered in the schema description.

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

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

The description clearly states the specific action ('Search SEC EDGAR'), resource ('companies'), and method ('by name or ticker symbol'), distinguishing it from siblings like get_company_facts and get_company_filings which likely retrieve different data types rather than performing searches.

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

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

It provides clear context for when to use this tool ('Search SEC EDGAR for companies by name or ticker symbol') and mentions the output's purpose ('CIK numbers, which are needed for other SEC tools'), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools.

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