Clous MCP server
OfficialServer Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools target distinct SEC datasets with clear names, but clusters like search_financials/search_financial_statements/get_company_financials and search_proxy_officers/search_board_members could confuse an agent. Overall, the purpose of each tool is identifiable, but some overlap exists.
Naming Consistency4/5The dominant pattern is verb_noun (search_*, get_*, list_*, create_*, update_*, delete_*), but a few tools deviate: 'full_text_search' reverses the order, 'cyber_incidents' is a bare noun, and 'resolve_entity' uses a non-standard verb. These are minor relative to the many consistent names.
Tool Count2/5With 49 tools, the server exceeds the 25-tool threshold that marks 'too many'. While the breadth reflects a comprehensive SEC data platform, the sheer number burdens an agent with selection overhead, and many search_* tools could be consolidated.
Completeness5/5The tool surface covers a wide range of SEC datasets (filings, financials, insider activity, funds, governance, enforcement, patents) plus account management and monitoring. It provides thorough lifecycle coverage including create/update/delete for monitors and webhooks, leaving no obvious dead ends.
Average 3.4/5 across 49 of 49 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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.jsonto 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
- Behavior1/5
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 only mentions the basic search action and does not disclose pagination behavior, output format, authentication requirements, or any restrictions, making it inadequate for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise with no filler, but it is under-specified for a tool with six parameters. The brevity reflects a lack of essential information rather than efficient completeness, so it is more comparable to under-specification than to well-structured conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is grossly inadequate given the tool's complexity. With no output schema, no annotations, and six parameters, it fails to explain return values, pagination, filter semantics, or use cases. The agent cannot correctly select or invoke this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the six parameters. Schema description coverage is only 33% (limit and cursor have descriptions), leaving q, state, industry, and min_amount undocumented in both the schema and the description. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action 'search' and the resource 'Form D private-placement capital raises' with a specific filing type, distinguishing it from sibling search tools like search_filings or full_text_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 search_filings or full_text_search. There is no mention of preferred use cases, exclusions, or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
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 merely states 'Delete a monitor by id' without mentioning that the action is destructive, irreversible, or any side effects. No context about permissions, cascading effects, or error behavior is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence and is succinct. However, its brevity borders on under-specification; while not as tersely vague as 'Process', it omits essential usage and transparency details that a fuller but still concise description would include.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one parameter, no output schema, no annotations) and the absence of any behavioral context in the description, it is severely incomplete. The agent is left without information about return values, error cases, or the consequences of deletion, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter, monitor_id (string, required), with 0% schema description coverage. The description only adds 'by id', which is redundant with the parameter name, and provides no additional meaning about the format, constraints, or purpose of the id beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a monitor by id' uses a specific verb (delete) and resource (monitor), clearly distinguishing it from sibling tools like create_monitor, get_monitor, and update_monitor. The mention of 'by id' clarifies the primary input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over alternatives or any prerequisites. There is no mention of what happens if the monitor does not exist or whether deletion is reversible, leaving the agent without 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?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'search', implying a read-only operation, but does not mention pagination behavior, required filters, or whether the operation is safe. This lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no wasted words. However, it is terse to the point of under-specification, though that is more of a completeness issue than a conciseness one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no output schema, and no annotations, a one-sentence description is grossly insufficient. It does not explain return values, filtering options, or how to use the many parameters, making it inadequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information. Schema coverage is only 27%, leaving 8 of 11 parameters undocumented in the schema. The description does nothing to compensate for this low coverage, providing zero insight into parameters like issuer, person, or filed_from.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for 13D/13G beneficial-ownership filings, which is a specific verb and resource. This distinguishes it from general search tools like search_filings, 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 Guidelines2/5Does 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 the many sibling search tools, nor any conditions or prerequisites. The description only states the action without 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?
The description only says 'curated feed,' which hints at a pre-filtered list but does not disclose how the feed behaves, such as pagination, filtering, or any side effects. Since no annotations are provided, the description carries the full burden but fails to explain important behavioral traits like authentication, rate limits, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is easy to read and front-loaded with the tool's primary purpose. It contains no fluff, though it is quite sparse. The conciseness is effective, but the brevity contributes to incomplete coverage of other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 5 parameters, no annotations, and no output schema, yet the description provides no information about parameters, return values, or additional behavior. The description is far too minimal for an agent to correctly use the tool, making it contextually incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. Schema coverage is only 40%, with only limit and cursor having descriptions, leaving ciks, date_to, and date_from undocumented. The description fails to compensate for these gaps, offering no additional meaning for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a curated feed of SEC 8-K Item 1.05 material cybersecurity-incident disclosures, using a specific verb (curated feed) and resource (SEC 8-K Item 1.05). This distinguishes it from sibling tools like search_filings or get_8k_events by focusing on a specific filing type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool compared to alternatives such as search_filings or get_8k_events, nor does it state any exclusions or prerequisites. The intended context is only implied by the name and description.
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states 'Search', which implies a read operation, but gives no details about pagination behavior, ILIKE pattern semantics, default limits, or whether any filters are mutually exclusive. It also omits that the schema uses partial matching for assignee/title, a behavioral trait not apparent from the schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the core purpose. However, it is concise to the point of under-specification, omitting important behavioral and usage details; still, as far as structure and length, it is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters, no output schema, and no annotations, the description is far too thin to fully contextualize the tool. It does not mention pagination, cursor usage, or what the response contains. Compared to the sibling set (including full_text_search and many other search tools), there is no guidance on how this fits into the broader tool ecosystem, making the description incomplete for a search tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 31%, and the description does not compensate. It names a few fields (assignee, title, grant date) but adds no detail beyond the existing schema descriptions. It also introduces 'classification' which is not a parameter, and leaves the meaning of fields like kind_code, cursor, and application_number unexplained. The description adds minimal value over the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: 'Search USPTO patent grants' and lists key search fields (assignee, title, classification, grant date). It clearly identifies the domain as patent grants, distinguishing it from siblings like search_filings or full_text_search. However, it mentions 'classification' as a searchable field while no such parameter exists in the schema, slightly undermining precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives. It does not mention exclusions, prerequisites, or why search_patent_grants should be chosen over full_text_search or search_filings. The intended use case is only implied by the resource name.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'search' which implies a read-only operation, but does not disclose pagination, defaults, filtering behavior, or response format. This is significantly minimal for a tool with nine parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is front-loaded with the action, and the parenthetical adds useful context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nine filter parameters and no output schema or annotations, a one-line description is grossly insufficient. It does not explain the intended use case, filter combinations, pagination protocol, or what constitutes a Form 144 notice. The tool is highly under-specified for an AI agent to invoke reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 22%, and the description mentions zero parameters. It does not clarify the meaning or use of issuer_cik, min_shares, sale_date_from/to, class_of_securities, or other filters. The description adds no value beyond the schema, which itself has sparse descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Form 144 proposed-sale notices, with a parenthetical explaining it covers insiders' intent to sell restricted/control stock. This uses a specific verb + resource and differentiates it from sibling tools like search_insider_transactions or search_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/5Does 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. The description only implies usage by naming Form 144, but it does not mention scenarios, exclusions, or how it differs from related search tools like search_insider_transactions.
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?
No annotations are provided, so the description carries full burden. It mentions the nature of events ('typed, evidence-backed') but doesn't disclose pagination behavior, default ordering, response format, or any filtering constraints beyond the schema. This is sparse for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the core purpose and gives illustrative examples. No wasted words; it communicates efficiently what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 optional parameters, no output schema, and no annotations, the description is too sparse. It doesn't explain how to use the cursor/limit for pagination, what the response contains, or any specifics about filtering. The user would need to infer too much from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), so the baseline is 3. The description adds marginal value by giving examples of event types ('executive changes, new filings, insider sells') which helps understand the event_type parameter, but it doesn't explain any parameters beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and resource ('the events feed'), and further clarifies the domain: typed, evidence-backed SEC business-change events with examples. This distinguishes it from filing search tools, though it doesn't explicitly differentiate from closely related siblings like get_event or get_8k_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With many sibling tools (search_filings, get_8k_events, get_event), the absence of exclusions or alternative recommendations is a clear gap.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the purpose and offers no information about pagination, filtering behavior, authentication requirements, return format, or other notable behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key action and resource. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters, no output schema, and no annotations, this one-sentence description is woefully incomplete. It does not explain pagination, filter combinations, result structure, or any operational details needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 31% (4 of 13 parameters have descriptions), and the tool description adds no parameter-level meaning. It fails to explain the numerous undocumented parameters like bc_scope, ia_scope, cal_date_from, or firm_count_min, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Search') and a specific resource ('IAPD/BrokerCheck individual investment-adviser representatives and brokers'). It distinguishes this tool from sibling tools like search_broker_dealers or search_advisers by focusing on individual representatives and brokers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for finding individual investment-adviser representatives and brokers, but it does not explicitly state when to use this tool over alternatives or provide exclusions. Context is clear but not fully articulated.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states the tool returns a 'structured' offering but does not mention that it is a read-only retrieval, what the response format looks like, or any edge cases. This is a significant gap for a get tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the resource and content. Every word earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description need not be exhaustive. It provides some context about the data content, but lacks explicit statements about what the return value contains or how to invoke it (e.g., by accession number). The absence of annotations increases the burden, which is only partially met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the 'accession' parameter is clearly described as a Form C accession number. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a Reg CF Form C crowdfunding offering and lists its key contents (issuer, offering terms, financial disclosures). The verb 'get' is implicit via the tool name, and the noun phrase successfully distinguishes this from sibling search tools, though it 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that the user must have an accession number, nor does it suggest using search_filings to locate filings. No prerequisites or context 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?
No annotations are provided, so the description must carry behavioral disclosure. It only mentions the manager→security position relationship, but does not disclose pagination behavior, filtering nuances, sorting, or any side effects. This is minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the key verb and resource. Every word contributes meaning, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 optional parameters, no output schema, and no annotations, yet the description is extremely sparse. It does not explain how parameters combine, what data is returned, or how pagination works, leaving significant gaps for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (limit and cursor are described), and the description adds no parameter details. Six parameters exist, including cusip, issuer, manager, and min_value, none of which are explained in the description. The description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 13F institutional holdings, using the specific verb 'search' and identifying the resource. The parenthetical '(manager → security positions)' clarifies the data structure and distinguishes it from sibling tools like search_13f_managers or search_fund_holdings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for 13F holdings queries but provides no explicit guidance on when to prefer this tool over alternatives like search_13f_managers or search_fund_holdings. No exclusions or alternative references are given.
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?
No annotations are provided, and the description only says 'Search,' which implies a read-only operation but does not disclose behavioral details such as pagination, rate limits, or data coverage. It does not contradict annotations because none exist, but it fails to add any meaningful behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. Every word contributes, and there is no unnecessary verbosity or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, no output schema, and no annotations, the description is too minimal to be contextually complete. It lacks information about parameter usage, output structure, or typical query patterns, making it difficult for an agent to invoke the tool correctly without additional guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the parameters (q, state, aum_min, limit, cursor). With only 40% schema description coverage, the properties q, state, and aum_min lack schema descriptions, and the description does not compensate. The parameter names are somewhat self-explanatory, but the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for 'Form ADV registered investment advisers,' which is a specific resource type and distinguishes it from sibling tools like search_broker_dealers or search_private_funds. It uses an explicit verb ('search') with a precise object, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives. It does not mention any exclusions, prerequisites, or comparisons with sibling search tools, leaving the agent without context for selection.
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?
With no annotations, the description must disclose behavioral traits, but it only states the search intent. It does not explicitly say whether the operation is read-only, describe the return format, or mention any limitations such as pagination or rate limits. The implied read-only nature of 'search' is insufficient without explicit confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and resource. Every word is meaningful with no unnecessary detail, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no output schema, and no annotations, yet the description is only one sentence. It does not explain what the results look like, how filtering works, or when to choose this tool over related search tools, leaving significant gaps in context for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 57%, leaving crd, sec_number, and control_person undocumented in the schema. The description adds no details about these parameters or how they relate to the search, so it fails to compensate for the gaps in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches private-fund ownership/control relationships, specifically on Form ADV. This precise verb+resource combination distinguishes it from broader search tools like search_filings and full_text_search, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as search_private_fund_stats or search_advisers. There is no mention of use cases, exclusions, or comparison to sibling tools, leaving the agent without selection criteria.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only lists searchable fields. It does not mention pagination behavior, date range inclusivity, result format, or any filters like limit or cursor, so the agent has little insight into how the tool behaves beyond the basic search action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently communicates the core purpose and key search dimensions, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having six parameters, no output schema, and no annotations, the description provides only a one-line summary. It omits essential operational details such as pagination via cursor, default limits, result structure, and the nature of the date filters, making the tool incomplete for reliable autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description merely restates 'company name, release number, and date' without adding meaning for the undocumented parameters (date_from, date_to, release_number). It fails to explain date formats, range semantics, or how wildcard patterns work for company, leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('Search') and its specific resource ('SEC trading-suspension orders'), and it names the main search facets (company name, release number, date). This distinguishes it from sibling search tools like search_filings or search_enforcement by focusing on a unique SEC document type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus other search tools, nor any exclusions or prerequisites. The description only states what the tool does, leaving the agent to infer its appropriate context from the name alone.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only adds 'every reported concept' as a behavioral trait, but does not mention pagination, output format, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the essential purpose. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations exist, so the description should provide more operational context. It only gives a high-level data type without clarifying return structure or use cases, making it inadequate for a tool with this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so the description does not need to compensate. The description adds no extra parameter meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource ('Structured XBRL financial facts'), the scope ('one company by CIK'), and the action is implied by the name 'get'. It distinguishes from sibling search tools by focusing on XBRL concepts rather than general 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/5Does 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 like search_financials or search_financial_statements. The description only states what it does, not the conditions or scenarios for choosing it.
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?
No annotations are provided, so the description must carry the full burden. It merely says 'List' which implies a read operation, but does not disclose pagination behavior, ordering, scoping (beyond the optional endpoint_id), or what fields the delivery log entries contain. Significant behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It front-loads the verb and resource, conveying the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description is insufficiently complete. It does not explain what the webhook delivery log contains, how results are ordered, how pagination works, or even that it is a read-only operation. For a list tool, more context is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (limit and endpoint_id), so the description adds little beyond what the schema already specifies. With 100% schema coverage, the baseline of 3 is appropriate; the description does not enrich the parameters' meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List') and resource ('webhook delivery log'), and it is distinct from sibling tools like list_webhook_endpoints, which list endpoints rather than delivery logs. The purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool compared to alternatives. It does not mention scenarios, exclusions, or related tools such as list_webhook_endpoints or create_webhook_endpoint. The usage context is only implied by the name.
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?
Since no annotations are provided, the description carries the full burden of disclosing behavioral traits. It only states the search action and fails to mention pagination, filtering semantics, read-only nature, or any side effects, which is inadequate for a 9-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler words. It is effectively front-loaded and appropriately concise for the information it conveys, though its brevity contributes to under-specification in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotations, the description needs to provide more operational context. It fails to explain what 'extracted' means, how pagination works, what filters are available, or what the response contains, leaving the agent with insufficient information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 56%, and the description itself mentions no parameters. Fields like ein, sec_cik, source_type, and min_confidence remain completely unexplained in both the schema and the description. The description adds no value beyond the partial schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and the specific resource ('extracted board members / directors') with an explicit scope ('across organizations'). This distinguishes it from sibling tools like search_proxy_officers or search_insider_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when searching for board members or directors, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools. The usage context is inferable but not stated.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, how pagination works, whether results are aggregated at the fund level, or what 'tab' refers to in the Form PF context. The description only says 'search', which is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose and scope. Every word contributes value, with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 8-parameter search tool with no output schema, no annotations, and only 25% schema coverage. The description fails to explain the data source structure (Form PF tabs/metrics), pagination behavior, result format, or any relationships to sibling tools. It is grossly incomplete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only limit and cursor are explained). The description adds the phrase 'per quarter, tab, and metric' which loosely maps to quarter_end_date, tab_name, and metric_key, but does not define these parameters, nor does it explain row_key, min_value, or max_value. This is insufficient given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' and clearly identifies the resource: 'aggregate private-fund statistics from Form PF', further scoped by 'per quarter, tab, and metric'. This distinguishes it from sibling tools like search_filings or search_private_funds, which target different data sets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (Form PF statistics search) but does not explicitly state when to choose this tool over alternatives like search_filings or search_fund_holdings, nor does it provide exclusions or prerequisites. The 'per quarter, tab, and metric' hint gives some sense of intended use, but no direct comparison to siblings.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention that this is a read-only operation, what the response shape looks like, or any pagination behavior. It only restates the search capability already implied by the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It effectively communicates the core purpose and main filter dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no output schema, and no annotations. The description is too minimal to provide complete guidance for an agent to correctly invoke it, especially for the undocumented min/max amount parameters and expected result format. The moderate schema coverage does not compensate for the lack of contextual detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description names fiscal year, amount, and summary as filter criteria, which partially maps to the parameters. However, it does not explain the min/max amount fields or the ILIKE pattern matching for award_order_no and public_summary. Schema coverage is 57%, so the description adds some meaning but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches SEC whistleblower award orders, a specific and identifiable resource. It also mentions the searchable dimensions (fiscal year, amount, summary), which distinguishes it from other SEC search 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/5Does 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 the many sibling search tools, nor does it mention any alternatives or exclusions. The usage context is only implied by the tool's name and the description's basic purpose.
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?
With no annotations, the description carries the transparency burden. It discloses the scope ('body of every filing since 2001') and that it is a full-text search, but it omits details like pagination behavior, result format, or rate limits. The coverage note adds some value but leaves significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no redundant or unnecessary information. It is efficiently worded while still conveying the essential scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and many sibling search tools, the description is too sparse. It fails to explain what the tool returns (e.g., filing matches with snippets), how pagination works, or how it relates to search_filings, making it difficult for an agent to confidently select it without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any meaning beyond the schema's parameter descriptions. While schema coverage is 71% (q, ciks, forms, limit, cursor are described), date_from and date_to lack descriptions, and the tool description gives no context for any parameter usage, such as how to combine filters or what the required 'q' means.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('search') and resource ('body of every EDGAR filing since 2001'), clearly distinguishing it from sibling tools like search_filings that likely target metadata. The 'full-text' qualifier and date coverage make the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention search_filings for metadata searches or any scenario-specific recommendations, leaving the agent to infer usage 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic search action and does not disclose behavioral traits such as pagination behavior (despite schema having limit/cursor), the nature of returned data, any read-only status, or rate limits. The description is too minimal to inform agents about side effects, response format, or operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. It is appropriately brief and contains no redundant or filler content. It earns its place by capturing the essence without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 18 parameters, no output schema, and no annotations. The description provides only the basic subject and does not explain N-PORT context, return value structure, pagination, or differentiation from 13F holdings. Given the tool's complexity, this minimal description is inadequate for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 28% (5 of 18 parameters), so the description must compensate for the many undocumented parameters (e.g., isin, cusip, series_id, report_date). The description provides no parameter-specific information at all, merely naming the resource. It fails to clarify the meaning or usage of the remaining parameters, leaving agents to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Search'), a resource ('N-PORT registered-fund portfolio holdings'), and a clarifying parenthetical ('mutual funds / ETFs → security positions') that distinguishes it from related tools like search_13f_holdings. It unambiguously identifies the domain and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying that this searches N-PORT registered-fund portfolio holdings, which implies it is for mutual fund/ETF security positions, distinct from 13F holdings. However, it does not explicitly state when not to use it or name alternative tools, so it lacks explicit exclusions.
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?
There are no annotations, so the description carries the full burden for behavioral disclosure. It only states the search action, but does not mention expected return format, pagination behavior, or whether results are filtered by default. For a search tool, this is acceptable but minimal; no safety or side-effect context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key verb and resource. It avoids filler and provides illustrative examples without excess length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no annotations, and no output schema. The description gives only the basic purpose and does not explain parameter usage, result shape, or pagination. This is insufficient for an agent to invoke the tool correctly with complex queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the tool description does not compensate. It alludes to 'role' via examples but does not explain any of the 8 parameters. Half the parameters (e.g., filer_cik, provider_cik, is_affiliated) lack descriptions in both schema and tool description, leaving the agent to guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' and identifies a clear resource: 'N-CEN registered-fund service providers'. It also lists examples of provider types (custodians, advisers, administrators), making the tool's focus unambiguous and distinct from sibling search tools that target other entity types (e.g., advisers, broker-dealers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when searching for N-CEN service providers, but it does not explicitly contrast with sibling tools or provide exclusions. Given the large set of sibling search tools, some guidance on when this specific tool is preferred would be helpful, but the resource name is self-explanatory.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool searches by certain fields and omits important behaviors such as ILIKE wildcard semantics, pagination behavior, default page size, or return format. This lacks the depth needed for an agent to anticipate how the tool actually behaves at runtime.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary verb and resource, followed by a concise list of filtering dimensions. Every word earns its place; there is no fluff or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, zero annotations, and no output schema, the one-sentence description is insufficient. It does not explain pagination, response structure, or edge cases like wildcard usage, making it incomplete for an agent to confidently invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with date_to, date_from, action_type, and release_number left undocumented in the schema. The description lists 'date' generally and mentions action type, but it adds no format constraints, allowed values, or date-range semantics, and it omits release_number entirely. Thus it under-compensates for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource structure: 'Search SEC litigation releases' and enumerates the key filters (defendant, title, action type, date). This clearly distinguishes the tool from sibling search tools like search_enforcement or search_filings, which target different SEC data domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the resource name and the listed filters, suggesting it should be used when an agent needs to find SEC litigation releases. However, it provides no explicit guidance on when to prefer this tool over alternatives such as search_enforcement or full_text_search, and no exclusions are mentioned.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action and document types but does not disclose return format, whether item names or codes are accepted, error behavior, or any limitations. The description essentially restates the tool's purpose without adding behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the action, object, and document types in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must be more comprehensive. It does not specify what the tool returns, how accession should be determined, or resolve the mismatch between 'named item' and the schema's item codes (e.g., '1A', '5.02'). The tool description leaves enough ambiguity that an agent might invoke it incorrectly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents the 'item' parameter with examples but leaves 'accession' undocumented. The description partially compensates by referring to 'named item' and providing examples like Risk Factors and MD&A, which align with the schema examples. However, it does not explain what accession refers to, and there is ambiguity between named labels and item codes (e.g., '5.02'), so the description adds only modest value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Extract' and clearly identifies the resource ('a named item') and source ('10-K/10-Q/8-K primary document'), with concrete examples like Risk Factors and MD&A. This clearly distinguishes it from sibling search/list tools by focusing on section extraction from a specific filing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides helpful context that this tool works on 10-K/10-Q/8-K primary documents, implying it should be used when a specific section of an identified filing is needed. However, it does not explicitly state when to use this over alternatives such as full_text_search or list_filing_documents, nor does it mention any exclusions or prerequisites.
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?
With no annotations, the description must carry behavioral disclosure. It only restates the fetch action and the lookup key, failing to mention output format, error handling, permissions, or any other behavioral traits. This provides no guidance beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, front-loaded with the verb and resource. It is maximally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one simple required parameter and no output schema, the description is minimally adequate to identify the operation. However, it lacks detail about the return structure or any special behavior, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines monitor_id as a string with no description, and the tool description only says 'by id,' adding no meaningful context. With 0% schema coverage, the description needed to explain the parameter but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single monitor by id' uses a specific verb and resource, clearly indicating the operation returns one monitor. It distinguishes itself from sibling tools like list_monitors (which lists) and create/update/delete monitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: to fetch a specific monitor when its ID is known. It does not explicitly state exclusions or alternatives, but the context is clear for a straightforward getter.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does state that all live datasets are included and that they are 'public', which hints at access permissions. However, it fails to mention pagination, ordering, potential response size, or any rate limits or latency implications, which are important for a tool that returns an entire catalog.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core concept ('Dataset catalog + freshness') and then lists the specific fields returned. There is no fluff. However, the typo 'Clous' and the abbreviated phrase 'catalog + freshness' slightly reduce clarity, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with no parameters and no output schema, the description covers the essential return elements (endpoint, record count, last sync). It gives a clear picture of what the tool provides, but it does not explain issues like pagination or how it fits with sibling tools. Given the simplicity, the description is largely sufficient but leaves a few gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema is empty. The description appropriately focuses on what the output will contain (endpoint, record count, last sync), which helps set expectations for the return payload. With no parameters, the baseline is 4, and the description aligns well by explaining the result semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a dataset catalog that lists every live Clous dataset with its endpoint, record count, and last sync. It distinguishes from sibling search tools by emphasizing the broad catalog scope. However, it uses the noun phrase 'Dataset catalog' rather than an explicit verb like 'list' or 'retrieve', making the purpose slightly less direct than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: this tool is meant for discovering available datasets. But there is no explicit guidance on when to use it versus alternatives like search_filings or get_company_financials. No exclusions, prerequisites, or alternative tool references are given, so guidance is weaker than a clear when-to-use statement.
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?
With no annotations, the description carries the transparency burden. It discloses the output row granularity ('one row per reported fact') but does not mention pagination, filters, read-only nature, or what data each row contains. This adds some context but leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the primary action and resource, though it could be expanded with usage guidance without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 14-parameter search tool with no annotations and no output schema. The description only provides minimal output granularity but does not explain pagination, available filters, or return structure. It is insufficient for an agent to use the tool correctly without relying on the schema's partial descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 36% (5/14 params described), so the description must compensate. It does not. The description fails to mention key filter dimensions like company, concept, fiscal year, or period, which are represented in the schema but undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' and clearly identifies the resource: 'XBRL company-facts financial concepts across companies.' The parenthetical '(one row per reported fact)' clarifies output granularity, distinguishing it from sibling tools like get_company_financials or search_filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies cross-company search via 'across companies,' but does not explicitly state when to use it over alternatives such as get_company_financials or full_text_search. No exclusions or alternative references are provided, leaving the usage context only implicit.
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only mentions the resource type and filter dimensions, but does not disclose pagination (though limit/cursor exist in schema), rate limits, data coverage limitations, or result format behavior. Significant behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word contributes meaning, and it is appropriately sized for the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 12 parameters, no output schema, and no annotations, yet the description only states basic purpose. It omits context about pagination, result structure, or when to use which filters. Given the complexity, the description is insufficient for an agent to fully understand the tool's behavior and capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema documents most parameters. The description adds minimal value by summarizing key filters (company, tag, period), but it does not explain undocumented parameters like sic, max_value, or min_value. Since coverage is high but not >80%, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'structured XBRL financial-statement facts' using 'company, tag, and period', which is a specific verb+resource. It distinguishes from sibling tools like search_filings and full_text_search by specifying the XBRL Financial Statement Data Sets 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying search dimensions (company, tag, period), but it does not explicitly state when to use this versus alternatives, nor provide any when-not guidance. No exclusions or alternative tool references are mentioned.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Search' which implies a safe read, but it does not describe pagination behavior, return shape, filtering semantics, or any side effects. The description adds no behavioral nuance beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately specifies the action and target, with no filler or redundancy. It is appropriately concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters and no output schema or annotations, this description is materially incomplete. It does not describe the response structure, the meaning of customer relationship summaries, or the search/filter behavior. Siblings and schema partially help, but the description alone leaves critical gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, so the description must compensate for undocumented parameters. It does provide thematic context (firm services, fees, conflicts, disciplinary history) that maps to some params like disciplinary_history_flag and min_professionals, but it does not explain six of the ten parameters (e.g., form_sub_type, filed_after, firm_crd, etc.), leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' with a specific resource ('Form CRS customer relationship summaries') and enumerates key content facets (firm services, fees, conflicts, disciplinary history), distinguishing it from generic search tools like search_filings or full_text_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for finding Form CRS summaries but provides no explicit guidance on when to prefer this over siblings like search_advisers or search_broker_dealers, nor any exclusions or prerequisites. Context signals show many sibling search tools, so usage context is only implied.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool performs updates but does not disclose whether updates are partial or full replacements, what effects pausing/resuming has, permission requirements, idempotency, or side effects on other resources. The description is too terse to convey critical behavioral traits for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear structure. It lists the actionable fields in a compact, scannable format without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is under-specified. It does not clarify whether unspecified fields are preserved or reset, what the response contains, or any prerequisites (e.g., webhook endpoint must exist). The absence of behavioral details and the partial parameter coverage leave the tool insufficiently documented for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does map 'rename' to the name parameter and 'pause/resume' to the status enum, and mentions signals/materiality/webhook. However, it does not define what 'signals' or 'webhook_endpoint_id' mean or how they interact, leaving significant ambiguity for parameters beyond their names. It adds some value but does not fully compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Update') and resource ('a monitor'), and enumerates the updatable attributes (status, name, signals, materiality, webhook). This distinguishes it from sibling tools like create_monitor, get_monitor, and delete_monitor, which serve different lifecycle stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when modifying an existing monitor, listing the fields that can be changed. However, it does not explicitly contrast with create_monitor or state when not to use it, so the guidance is implied rather than explicit. The context is clear but lacks explicit exclusions or named alternatives.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explain match semantics, return format, pagination behavior, or whether partial/fuzzy matching is supported, leaving significant ambiguity for a lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the core purpose and avoids redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain return values and behavior. It does not describe the response structure, pagination (though cursor is in schema), or how the various optional filters interact. The tool has 8 parameters, but the description covers only the primary lookup keys, leaving the rest unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 38%, so the description must compensate. It mentions CIK, ticker, and name but does not clarify that 'q' likely handles name searches, nor does it address undocumented parameters like entity_type and state_of_incorp. The description adds minimal parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves and looks up companies in the entity directory by CIK, ticker, or name. It specifies a concrete verb ('resolve'), resource ('companies in entity directory'), and search keys, which distinguishes it from the many sibling search 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when you need to resolve a company by CIK, ticker, or name. It does not explicitly mention when not to use it or name alternatives, but the context is sufficient for a lookup tool.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds context that records are extracted from proxy statements and mentions compensation components, but it omits details like pagination behavior, result ordering, or filtering semantics. The description is not misleading but lacks depth for a search tool with many parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that is front-loaded with the core action and resource. Every word contributes meaningful information, avoiding unnecessary detail while conveying the essential domain and data scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with no output schema, no annotations, and only 40% schema description coverage, this description is far too sparse. It fails to clarify the many filter options (e.g., filer_cik, accession_number), pagination via cursor, or how results are structured. The agent would be left guessing about basic usage and capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, leaving six parameters completely undocumented. The description does not explain any of the filter parameters (e.g., min_total_usd, fiscal_year) beyond what the schema already provides. It merely mentions 'salary, bonus, awards, total' as data fields, which does not map clearly to the schema parameters, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'executive-compensation records extracted from proxy statements' and lists the key data fields (salary, bonus, awards, total). This specific verb+resource scope distinguishes it from sibling search tools like search_insider_transactions or search_proxy_officers, which target different data domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for executive-compensation data but provides no explicit guidance on when to use this tool versus alternatives. There are no exclusionary conditions or references to sibling tools, leaving the agent to infer appropriate use from the domain alone.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only explains the record type. It does not describe pagination, filter options, return format, or other side effects, leaving much to the user's assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 optional parameters and no output schema, the description is too thin. It does not explain filtering capabilities, pagination via cursor, or any other operational context, making it minimally viable for a complex search endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, and the description does not compensate by explaining the undocumented parameters (filer_cik, form_type, filing_date_*). The mention of 10-K/10-Q adds an example for late_for_form but little else, as that parameter already has a schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and clearly identifies the resource ('NT records'), while explaining the domain (Form 12b-25 for late 10-K/10-Q). This distinguishes it from broader siblings like search_filings and full_text_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by focusing on NT late filings, giving clear context. However, it does not explicitly mention alternatives or exclusions, so it stops short of full guidance.
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?
No annotations are provided, so the description must convey behavioral traits. It only states the basic purpose without disclosing search behavior, pagination specifics, authentication, or any limitations. Since this is a search/read tool, the lack of such disclosure leaves the agent uninformed about expected 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states the tool's purpose without unnecessary detail. It is front-loaded with the key action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no annotations, and no output schema, the description is insufficient. It does not explain return format, pagination, or clarify the many undocumented parameters. This is a complex tool needing more elaboration to be fully usable by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 56% (5 of 9 parameters have descriptions). The tool description adds no parameter-level meaning beyond the schema. Undocumented parameters like cik, min_age, is_independent, and accession_number remain unexplained, and the description does not compensate for these gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and identifies a precise resource ('executive officers and directors disclosed in proxy statements (DEF 14A)'). This clearly distinguishes it from sibling search tools like search_board_members or search_compensation by referencing the filing type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: searching for officers/directors specifically in proxy statements. It does not explicitly mention alternatives or exclusions, but the context is sufficient to infer appropriate usage given the sibling tool names.
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?
No annotations are provided, so the description carries the full burden. It only states the registration action and the endpoint's purpose, but does not disclose permissions, validation behavior, idempotency, or what happens on success/failure. This is a minimal behavioral disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence beginning with the action verb 'Register'. It contains no filler or redundant information, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and incomplete parameter coverage, the description should explain more. It omits return value, permissions, behavior for duplicate endpoints, and the optional 'description' parameter, leaving the agent under-informed about the full scope of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'url' with 'must be https://', which the description reinforces but does not add much beyond that. The optional 'description' parameter has no schema description and the tool description does not explain it. With 50% schema coverage, the description partially compensates by providing webhook context, but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Register' with a clear resource 'https webhook endpoint' and states its purpose 'to deliver monitor matches to.' This distinguishes it from sibling tools like create_monitor and list_webhook_endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to deliver monitor matches to' provides clear context for when this tool should be used, implying it is for setting up delivery of monitor results. It does not explicitly mention exclusions or alternatives, but the context is sufficient for basic 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?
With no annotations, the description carries the full transparency burden. It discloses the output structure (per meeting: issuer/CUSIP, matter, shares voted, vote, recommendation) and scope ('for a filing'), but does not mention pagination behavior, data availability, or that it is read-only. This is moderate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the key information, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one required parameter and no output schema, the description adequately conveys the input (a filing) and the output structure. It does not explain pagination defaults, but those are defined in the schema. Overall, it is complete enough for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions, so baseline is 3. The description adds 'per meeting' context but does not elaborate on accession format, cursor usage, or limit semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's resource: structured N-PX fund proxy-voting records for a filing, with specific fields. Although it lacks an explicit imperative verb, the name 'get_proxy_votes' and the content description make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving N-PX proxy-voting records for a specific filing, but it gives no explicit guidance on when to prefer it over sibling tools such as search_fund_holdings or extract_filing_section. No exclusions or alternatives are mentioned.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('List') and the resource, but omits details on return format, pagination, authentication requirements, or side effects. For a read operation, this is minimal but acceptable for a simple list; however, it does not proactively disclose any behaviors beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word earns its place, and there is no redundancy or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description is functionally complete: it states what is listed (webhook endpoints) and for whom (your registered). While it does not describe the output structure or potential edge cases, these are less critical for a simple read operation. The description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty. The description adds the qualifier 'your registered', which clarifies scope by indicating that it lists the caller's own endpoints. Given the 0-parameter baseline of 4, the description adequately satisfies this dimension without needing to explain parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('your registered webhook endpoints'), unambiguously identifying the tool's function. It distinguishes itself from sibling tools like 'create_webhook_endpoint' and 'list_webhook_deliveries' by focusing on the listing of endpoints rather than creation or delivery logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives. There is no mention of typical use cases, prerequisites, or scenarios where another tool like 'create_webhook_endpoint' or 'list_webhook_deliveries' would be more appropriate. The agent must infer usage solely from the tool name.
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?
No annotations are provided, so the description carries the full burden. It only implies a read-only search without disclosing pagination behavior, return format, or any side effects. The description adds minimal behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the verb and resource, and omits any unnecessary words. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the search returns (e.g., manager profiles, matching criteria). It does not, and it also lacks information about sorting, pagination mechanics beyond the schema, or any nuances. For a search tool with 4 parameters, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage of all 4 parameters with detailed descriptions, so the baseline is 3. The description repeats the parameter purposes ('by name', 'minimum reported AUM') without adding new meaning, and there are no additional constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('search') and resource ('13F institutional investment managers'), with scoping details ('by name, with minimum reported AUM') that clearly distinguishes it from siblings like search_13f_holdings. It fully specifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes that this tool is for searching managers (not holdings or filings) by name and AUM filter. However, it does not explicitly state when not to use it or name alternative tools, so it misses the full exclusions. The context is clear enough for an agent to decide.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the search functionality and does not mention whether it is read-only, paginated, or has any side effects, leaving the agent to infer from the tool name 'search'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists the key search dimensions with no wasted words. It is compact and immediately conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no annotations, and no output schema, the description is too brief. It does not cover pagination, all filter parameters (case_number), or any behavioral details, making it insufficient for full invocation without additional schema inspection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to several schema parameters by listing them as search filters (agency, action_kind, date, penalty), partially compensating for the low schema coverage. However, it omits case_number and pagination parameters, and does not explain the exact semantics of the date range or penalty minimum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches SEC/agency enforcement actions, specifying key filter dimensions (respondent, agency, action kind, date, penalty). It distinguishes from siblings like search_litigation and search_filings by focusing on enforcement actions rather than general filings or court cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for searching enforcement actions, making it evident when to use it. However, it does not explicitly mention alternatives or when not to use it, though the scope is well-defined.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the search action but does not mention pagination behavior, rate limits, result format, whether it returns metadata or full text, or any other behavioral traits. For a search tool, this is a notable gap; the description provides no information beyond the verb 'search'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the verb and resource, then succinctly lists the main filters. There is no redundancy or filler, making it an efficient and well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 optional parameters and no output schema or annotations, yet the description does not mention pagination via cursor/limit, additional filters like is_xbrl or sic, or what the search returns. This is incomplete guidance for a tool with this complexity, leaving important invocation details to the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with every parameter having a description. The tool description adds a high-level summary of key filters (CIK, form type, date range, keyword) but does not add meaning beyond what the schema already provides. Given the high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Search'), a specific resource ('EDGAR filing index'), and scope ('across all form types'), which distinguishes it from more specialized sibling search tools like search_insider_transactions or search_13f_holdings. It also lists concrete filter dimensions (CIK, form type, date range, keyword), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is the tool to use for broad searches of the EDGAR filing index across all form types. It does not explicitly name alternatives or state when not to use it, but the phrase 'across all form types' effectively differentiates it from more narrowly scoped sibling searches, providing implied usage guidance.
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?
With no annotations provided, the description alone must convey behavioral traits. It only states that it searches, implying a read-only operation, but fails to disclose pagination behavior (despite cursor and limit parameters), the scope of results (e.g., whether it returns both derivative and non-derivative trades), or the output format. There is no mention of rate limits, ordering, or any constraints. The single sentence provides minimal behavioral insight beyond the verb 'Search'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It immediately states the action, the subject matter, and the major filtering dimensions. Every word contributes to surface-level understanding, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 13 parameters, no output schema, and no annotations, making the description the only source of guidance. It fails to mention pagination (despite cursor/limit params), result shape, default behaviors, or relationships to other tools like get_insider_filing. For a search tool of this complexity, the one-line description is insufficient for an agent to invoke it correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38%, so the description must compensate. It does add domain context by specifying the SEC form types (3/4/5) and names the main filter categories (issuer, owner, transaction code, date, value). However, it does not clarify all 13 parameters, resolve ambiguities like issuer vs. issuer_cik, or explain date formats or the meaning of value (min_value_usd). This partial compensation earns a medium score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search'), specifies the exact resource ('Form 3/4/5 insider transactions'), and lists the key search dimensions (issuer, owner, transaction code, date, and value). This clearly distinguishes it from sibling tools like get_insider_filing (which retrieves a single filing) and search_filings (general SEC filings), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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: when searching insider transaction filings by the listed criteria. It does not explicitly mention alternatives or when NOT to use it, but the strong domain framing ('Form 3/4/5 insider transactions') implicitly sets it apart from other search tools. No exclusions or alternative references are given, but the intended use case is evident.
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?
With no annotations, the description carries the full burden. It discloses that the monitor 'fires' on matching events and optionally uses webhooks, which is useful behavioral context. However, it does not detail side effects, permissions, activation state, or what happens without a webhook endpoint. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the main verb and object, and every word contributes meaning. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema, the description is reasonably complete. It covers the core concept, target types, and webhook option. It does not explain signals/materiality filtering or lifecycle details, but these are covered in the schema. The description offers enough context for an agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds a high-level frame ('standing watch', 'matching events') that helps contextualize parameters like signals and target_type, but it does not add specific parameter-level meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a monitor: a standing watch on a ticker/CIK/company/form/event type that fires (and optionally webhooks) on matching events.' It uses a specific verb ('Create'), identifies the resource ('monitor'), and explains the function, distinguishing it from sibling tools like update_monitor or delete_monitor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—this is the tool for creating monitors—but does not explicitly contrast with alternatives or provide exclusions. It also does not mention prerequisites like creating a webhook endpoint first. Usage context is clear but not fully elaborated.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It states the tool classifies items and returns excerpts, which is useful for a read operation, but it does not mention output format, error handling, or any limitations. It is adequate but not rich in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the core action and includes relevant examples in parentheses, making it both concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema, so the description must clarify the return value. It does mention excerpts, giving some sense of output, but lacks detail on exact return structure or edge cases. Given the low complexity, this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'accession' is fully described in the schema as '8-K accession number,' giving 100% schema coverage. The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Classify' and identifies the resource as 'the numbered items an 8-K reports,' with concrete examples (5.02, 4.01, 2.02) and states excerpts are included. This clearly distinguishes it from sibling tools like extract_filing_section or search_filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for classifying 8-K items, but it does not provide explicit when-to-use guidance, mention alternatives, or state when not to use it. This meets the 'implied usage' level but not the 'clear context with exclusions' level.
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?
No annotations are provided, so the description carries the full burden. It adds the behavioral hint that the response includes 'full evidence,' but does not disclose error handling, authentication, or other potential side effects. For a simple read operation this is minimal but not absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the verb and resource, with no unnecessary words or repetition. It is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter get-by-id tool, the description covers the core purpose and hints at the return value ('with full evidence'). Without an output schema, the exact nature of 'full evidence' is vague, but the tool is simple enough that this is mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% (event_id is described as 'Event id.'), so the description does not need to add parameter details. However, it also does not provide any additional context about the parameter beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'a single event by id' and adds 'with full evidence' to distinguish it from list_events or other search tools. This leaves no ambiguity about what the tool 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied (fetch a specific event by its id), but the description does not explicitly state when to use this tool versus list_events or other alternatives. There is no mention of exclusions or prerequisites.
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?
With no annotations provided, the description carries the full burden. It discloses the returned content (subsidiaries with name and jurisdiction), but does not mention that it is a read-only operation, whether it returns an empty array if no Exhibit 21, or any error conditions. The behavior is minimally transparent but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 12 words. It clearly states the key information without any filler or repetition, making it exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description provides sufficient context: it identifies the source (10-K Exhibit 21) and the output fields (name and jurisdiction). It could be more explicit about the return format (e.g., an array of objects), but this is a minor gap given the simplicity and high parameter clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'accession' parameter, described as '10-K accession number.' The description reinforces that the accession refers to a 10-K and that data comes from Exhibit 21, but does not add syntax or format details beyond the schema. Baseline 3 is appropriate due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns subsidiaries disclosed in a 10-K's Exhibit 21, including name and jurisdiction. It uses a specific noun phrase that implies a retrieval action, and it is distinct from all sibling tools, which focus on other filing content or search operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need subsidiaries from a 10-K Exhibit 21 and have an accession number. However, it does not explicitly mention when to use this over alternatives like extract_filing_section, nor does it provide any exclusion criteria. Usage is implied rather than explicitly guided.
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?
With no annotations, the description carries the full burden for behavioral disclosure. It clearly indicates a read-only listing operation and specifies the returned attributes, but it does not mention pagination, error behavior, permissions, or other potential edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and output. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description adequately explains the return value and purpose. No output schema exists, so the description appropriately covers the response contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter ('accession'). The description adds no additional parameter-level detail beyond the schema's existing description, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a resource ('a filing's document manifest'), clearly distinguishing this tool from sibling search and extraction tools. It also details the output contents (file, type, size, direct URL), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a filing's document manifest is needed, but it does not explicitly state when to prefer it over alternatives or mention related tools. No exclusions or alternative comparisons 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the granularity ('every trade'), the included components (owners, holdings, footnotes), and characterizes the data as 'structured'. It does not discuss failure modes or authentication, but for a simple read-only tool this provides solid transparency about what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence using an em dash to efficiently list the included components. Every word adds value: it names the resource, scope, and contents without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description adequately conveys what the response will contain. It is slightly incomplete in that it does not mention the need to first obtain an accession from a search or address invalid accession behavior, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the only parameter, accession, as 'Filing accession number,' achieving 100% coverage. The description adds the context that the accession refers specifically to a Form 3/4/5 ownership filing, but it does not add format, source, or usage details beyond the schema. Since schema coverage is complete, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns 'full structured detail of a single Form 3/4/5 ownership filing' and enumerates specific contents (owners, every trade, holdings, footnotes). This clearly distinguishes it from sibling search tools like search_filings or search_insider_transactions, which retrieve lists or summaries rather than a single filing's complete detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you have an accession number and need the complete detail of a single ownership filing. However, there is no explicit comparison to alternatives such as extract_filing_section or search_insider_transactions, nor any statement about when not to use it or a prerequisite to first obtain an accession via a search tool.
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?
With no annotations, the description carries the burden. It states the tool lists monitors, but does not disclose behaviors like pagination, ordering, or response format. For a simple list operation, the description is minimally adequate but lacks additional behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb and resource. It wastes no words and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is extremely simple with no parameters and no output schema. The description tells you what it does and whose monitors it lists, which is sufficient for this low-complexity tool. It could mention return details, but the simplicity keeps it complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. No parameter information is needed beyond what the schema provides, which is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists monitors (standing watches) on your account. The verb 'list' and the resource 'monitors' are specific, and it is easily distinguished from sibling tools like get_monitor or create_monitor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context that it lists monitors on your account, implying use for viewing your existing monitors. However, it does not explicitly state when to use this over get_monitor or provide exclusions, so usage is only implied.
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?
No annotations are provided, so the description must convey behavior. It clearly indicates a read-only query by stating 'remaining credits,' and 'configured API key' gives a credential context. However, it doesn't explicitly state no side effects, auth requirements, or rate-limit implications; the tool name and semantics imply safety but the description itself doesn't disclose it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler. The front-loaded 'Plan and remaining credits' immediately conveys output; the qualifier 'for the configured API key' adds necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, zero-parameter read tool with no output schema. The description sufficiently communicates the tool's purpose and output contents (plan, remaining credits). It could add return format or units, but given the low complexity and no sibling overlap, it's complete for practical selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, with 100% schema coverage by default. The description uses the phrase 'configured API key' to clarify which account is referenced (the one already configured), adding a semantic hint beyond the empty schema, though it's not a parameter. Baseline of 4 for zero-param tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'get' with resource 'account' and description 'Plan and remaining credits for the configured API key' clearly identifies purpose. No sibling tool covers account/API key info, so differentiation is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description establishes clear context: use when you need plan/credit status for the configured API key. It doesn't explicitly name alternatives or exclusions, but no sibling tool overlaps, so this is adequate.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'searches' (implying read-only) and identifies the data source (Form BD), but it does not mention pagination, result ordering, or any other behavioral nuances. The description provides the essentials but lacks richer 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the tool's essence immediately and efficiently, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (9 optional params, no output schema), the description is largely sufficient. It covers the tool's domain, data source, and primary query fields. It lacks explicit mention of pagination or return value shape, but these are partially covered by the schema (cursor, limit) and are generally implied for a search tool. Overall, it provides enough context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (3 of 9 params have descriptions), so the description must compensate. It does so by naming the primary search dimensions: CRD, name, status, and office location, which maps to bd_crd, name, status, and main_office_city/state/country. This adds valuable meaning beyond the schema. However, sec_number is not mentioned, and limit/cursor are left to the schema, which is acceptable since they already have descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('Search'), the resource ('registered broker-dealers (Form BD)'), and key search dimensions (CRD, name, status, office location). This distinguishes it from sibling search tools like search_advisers or search_filings by naming the exact entity type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies its use case: when an agent needs to find broker-dealer registration data. It provides explicit context for the tool's purpose but does not explicitly name alternatives or state when not to use it, so it does not fully earn a 5.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/clousai/Mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server