A-share filings: reductions, penalties, regulatory letters and stock halts. Source-linked facts.
Scored across 9 tools
The three passage tools (get_passage, get_earnings_passage, get_leadership_passage) have overlapping purposes and differ only by parent resource, which is easy to confuse. get_timeline also overlaps with get_earnings/get_leadership since all can return source mentions by date, though the resource-specific descriptions help somewhat.
Names mostly follow a predictable snake_case verb_noun pattern (get_*, list_*), with consistent suffixes like _passage and _companies. Minor inconsistency: list_deals does not name the resource (acquisitions) as the other list_* tools do.
Nine tools is well-scoped for a read-only stock-events research server covering earnings, leadership, and deals. Each tool earns its place, with no excessive or missing bulk.
The surface covers listing and reading earnings, leadership, and deal citations, plus timelines. A minor gap exists around deal detail retrieval beyond get_passage (e.g., no dedicated get_deal summary), but core research workflows are covered.
Read earnings disclosures for a ten-digit CIK; dates filter filing_date (YYYY-MM-DD).
Same-period sources are not distinct new earnings. CIK identifies the registrant;
financial subjects remain in the supported summary. Preserve periods, units and basis.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | ||
| end | No | ||
| start | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: dates filter on filing_date, same-period sources are not new earnings, and periods/units/basis must be preserved. However, phrases like 'financial subjects remain in the supported summary' are too opaque to convey a concrete behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core statement is front-loaded and short, which is good. But the remaining lines are fragmented into broken clauses ('CIK identifies the registrant; financial subjects remain in the supported summary') whose meaning is not recoverable, so not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained, and the three parameters are addressed. Gaps remain around ambiguous domain language ('supported summary', 'basis') and date-range semantics, which matter for a filtered-disclosure read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden and it largely does: cik is the ten-digit registrant identifier, and start/end filter on filing_date in YYYY-MM-DD form. It does not state whether the date range is inclusive, exclusive, or which bound is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Read earnings disclosures') scoped to a ten-digit CIK, which is enough to know what the tool retrieves. It does not name or contrast siblings like get_earnings_passage or list_earnings_companies, so the agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call it with a CIK, optionally narrowing by filing_date via start/end. There is no explicit when-to-use versus get_earnings_passage, nor any when-not guidance. The note that 'same-period sources are not distinct new earnings' is interpretation guidance rather than a routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a current earnings citation and neighbours for this CIK.
Same-period source mentions are not distinct new earnings.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | ||
| run | Yes | ||
| block | Yes | ||
| document | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered and the description doesn't need to restate it. The description does add one genuinely useful semantic hint – that same-period source mentions should not be treated as new earnings events – which is context not present in structured fields. However, it says nothing about how much surrounding context "neighbours" returns or how the four identifier inputs combine to locate the passage, which matters for a lookup whose failure mode is an empty or wrong passage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loads the purpose in the first sentence, with no filler or repetition. But brevity here shades into under-specification: the caveat sentence is cryptic in isolation and the space saved is not redeployed toward the addressing parameters that actually need explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be described, and annotations cover safety. What remains missing is essential for invocation: how cik/run/document/block are sourced and combined, and what "neighbours" bounds. For a four-required-parameter lookup with zero schema coverage, the definition is not complete enough for a reliable first call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and all four parameters (cik, run, document, block) are required, so the description carries the full burden of explaining them – and it largely fails. Only cik is obliquely referenced ("for this CIK"); run, document and block, which form an unexplained composite addressing scheme, are never mentioned. An agent has no way to learn from this text what a valid run/document/block value looks like or where to obtain them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Read a current earnings citation and neighbours for this CIK" gives a verb (read) and a resource (earnings citation/passage), so the general intent is graspable. But key terms are opaque: what a "citation" contains and what "neighbours" means (adjacent blocks? context window?) are never defined. It also does nothing to distinguish itself from the sibling tools get_earnings and get_passage, which an agent would have to disambiguate on its own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance at all: nothing explains when to call this versus get_earnings (the parent record) or get_passage (a generic passage fetch). The second line, "Same-period source mentions are not distinct new earnings," is a data-interpretation caveat, not a routing rule. An agent is left to infer the selection logic 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.
Read executive/board source mentions for a ten-digit registrant CIK.
Dates filter SEC filing_date (YYYY-MM-DD). Announced does not mean effective;
preserve role, employer, interim status, conditions and date qualifiers.
Registrant may differ from employer; repeated sources are not distinct changes.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | ||
| end | No | ||
| start | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is interpretive: dates filter SEC filing_date, announcements are not effective dates, registrant may differ from employer, and duplicate sources are not distinct changes. Those are genuinely useful domain caveats beyond the annotations, but it says nothing about result shape, volume, ordering, or limits, so it is solid rather than rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short lines, front-loaded with the core action and scope, then the parameter semantics, then the interpretation caveats. Every fragment carries information, though the phrasing is clipped to the point of reading like internal notes ('preserve role, employer, interim status...') rather than an instruction to the calling agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description is not obliged to explain return values, and it covers the essential inputs plus the interpretive pitfalls an agent would otherwise get wrong. The remaining gap is operational behavior - pagination, result ordering, or caps - which matters for a source-mention listing tool but is a minor omission given the schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load, and it largely does: it defines cik as a ten-digit registrant CIK and explains that start/end filter SEC filing_date in YYYY-MM-DD form. That supplies format and semantics the bare schema lacks, though it never clarifies inclusive/exclusive bounds or null/default behavior for the optional date parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Read executive/board source mentions') and scopes it to a 'ten-digit registrant CIK', so the agent knows this returns leadership-related source documents rather than prices or filings. It stops short of naming the sibling it most resembles (get_leadership_passage) or stating how the two differ, so differentiation is only implied by 'source mentions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit statement of when to use this tool versus get_leadership_passage, get_timeline, or list_leadership_companies. The cautions ('Announced does not mean effective', 'repeated sources are not distinct changes') frame how to interpret results but never say which query should route here, leaving the choice to inference 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.
Read a current leadership citation and neighbours for this registrant CIK.
The source may describe roles in another company; retain conditions and dates.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | ||
| run | Yes | ||
| block | Yes | ||
| document | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and side-effect behavior are covered. The description adds genuinely useful content context — that the cited passage may describe roles at a different company and that conditions/dates must be preserved — but says nothing about what 'neighbours' returns or how invalid run/document/block coordinates behave.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the action and the CIK scope front-loaded; nothing is wasted. The line-break/indentation formatting is slightly odd but does not impede comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema relieves the description of explaining return values, and annotations cover the safety profile. However, for a tool requiring four mandatory locator arguments with zero schema descriptions, the definition leaves an agent unable to construct a valid call without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across four required parameters, so the description carries the full explanatory burden and largely fails it: only cik is obliquely covered via 'registrant CIK'. The crucial coordinate parameters run, document, and block — which determine which passage is returned — receive no explanation of what they are or where to obtain them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Read a current leadership citation and neighbours') and ties it to a registrant CIK, which is enough to distinguish it as a passage-read tool. It does not, however, differentiate itself from the nearby get_passage or get_leadership siblings, and the meaning of 'citation' and 'neighbours' is left for the agent to guess.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus get_leadership, get_passage, or get_leadership_passage's alternatives. The second sentence ('The source may describe roles in another company; retain conditions and dates') is a data-handling caveat, not selection guidance, so the agent must infer the use case 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.
Read a citation returned by the selected deal, with neighbouring source paragraphs.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| deal | Yes | ||
| block | Yes | ||
| build | No | ||
| document | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful scope by saying it returns neighbouring source paragraphs, but it does not mention pagination, access constraints, or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted wording. It states the main action and the returned context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, four required, with 0% schema description coverage, so the description leaves significant gaps for correct invocation. Although an output schema and annotations reduce the burden for return values and safety, the description still does not explain the required identifiers well enough for an agent to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for five undocumented parameters. It only loosely connects to 'deal' and 'citation'; it does not explain what run, document, block, or build mean or how they relate to retrieving a passage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Read a citation' plus 'neighbouring source paragraphs.' This clearly distinguishes the operation from sibling tools like list_deals and get_timeline, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'a citation returned by the selected deal,' suggesting this tool is for inspecting a citation after a deal has been selected. However, it gives no explicit when-to-use guidance, exclusions, or comparison against get_timeline and list_deals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read source mentions by filing date (YYYY-MM-DD), including coverage and qualifiers.
Omit build for current results; explicit build requests historical results. Repeated mentions are not newly occurring events or notification changes.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| deal | Yes | ||
| build | No | ||
| start | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, idempotent, non-destructive), so the bar is lower. The description adds genuinely new behavior context: the build parameter switches between current and historical result sets, and repeated mentions should not be interpreted as new events or notification changes — a semantic caveat the annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the tool returns and followed by the two interpretive caveats. No filler, though the indented fragment style is slightly harder to scan than a single flowing paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and the annotations cover safety. The description supplies the non-obvious build semantics and the repeated-mentions caveat, which are the main sources of agent error; only the meaning of the required 'deal' identifier is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden. It explains build thoroughly and implies the date-format for the start/end filing-date range, but the required 'deal' parameter and the exact roles of start versus end are never explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Read source mentions by filing date'), plus the notion of coverage and qualifiers. It is clearly distinguishable from get_passage (single passage retrieval) and list_deals, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete operational guidance for the ambiguity-prone choice: omit build for current results, supply build for historical results. It also warns that repeated mentions are not newly occurring events. It stops short of stating when to prefer this over get_passage or list_deals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find astockevent acquisitions by name, verified ticker/alias or CIK; not all-market search.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and scope profile is fully covered by structured data. The description adds only the input-identity requirement and the non-exhaustive-search constraint; it says nothing about behavior when query is empty despite the schema defaulting to "".
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the positive capability front-loaded and the scope exclusion trailing. Every clause carries information, though the run-together token "astockevent" and the slightly awkward phrasing slightly reduce readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter, read-only lookup with an output schema present, the description covers what the tool does, what input forms are valid, and what it will not do. Nothing essential to correct invocation is missing, aside from empty-query behavior, which is minor given the default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% — the single "query" parameter is documented only as a title and default. The description compensates well by specifying the accepted value forms: a name, a verified ticker or alias, or a CIK number, which materially changes how the agent fills the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ("Find ... acquisitions") and enumerates the three identifier forms the lookup accepts (name, verified ticker/alias, CIK). It is clearly a targeted lookup rather than a generic listing, though the wording drifts from the tool name ("list_deals" vs "find acquisitions"), which costs a little precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The clause "not all-market search" tells the agent when this tool is inappropriate, which is real guidance. However, it names no alternative tool for broad or all-market discovery, and it never states the minimum required input, so the agent must infer that some identifier is expected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find saved earnings by name, verified ticker or CIK, not all-market coverage.
Same-period source mentions are not distinct new earnings.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral context with the dedup rule ("same-period source mentions are not distinct new earnings") and the saved-vs-all-market scope, but says nothing about ordering, pagination, or behavior when query is empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler, and the scope constraint is front-loaded. The second sentence is slightly elliptical ("are not distinct new earnings") but still earns its place as a dedup warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail is not needed, and the tool is low complexity with one optional parameter. However, the mismatched name/behavior (companies vs earnings) and the unstated empty-query semantics leave an agent uncertain about how to invoke it without arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single "query" parameter, so the description must carry the meaning, and it does partially by enumerating accepted identifier forms (name, verified ticker, CIK). It omits the fact that query is optional with an empty default and what an empty query returns, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says "Find saved earnings by name, verified ticker or CIK," which conveys the lookup inputs and the "saved" scope, but it is mismatched with the tool name list_earnings_companies (it never states that a list of companies is returned). The phrase "not all-market coverage" usefully scopes the resource, yet the core verb+resource pair remains ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"not all-market coverage" implies a boundary but names no alternative sibling (get_earnings, list_deals) for full-market or other lookups, so the agent must guess. The dedup note about same-period source mentions is guidance about results, not about when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find saved executive/board disclosures by name, verified ticker or CIK.
This is a processed subset, not all-market coverage or a current officer roster.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot convey: the result set is a processed subset with incomplete market coverage and non-current personnel. It stops short of describing pagination, result ordering, or freshness, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the lookup action and followed by the coverage caveat; nothing is filler. The only cost is that the scope caveat is slightly detached from the main clause and the phrasing is a touch indirect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-shape explanation is unnecessary, and the coverage caveat covers the main data-quality risk. What is missing is positioning relative to the eight siblings, especially get_leadership, which an agent would otherwise likely confuse with this list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single 'query' parameter, so the description must compensate. It does clarify the accepted identifier forms (name, verified ticker, CIK), which is the key semantic, but it says nothing about matching behavior (partial vs exact), the empty-string default, or what an omitted query returns. That is only partial compensation for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource ('Find saved executive/board disclosures') plus the search keys (name, verified ticker or CIK), so the agent knows it is a lookup over a curated leadership dataset. It does not name any sibling, and the noun 'disclosures' sits slightly awkwardly against the tool name 'list_leadership_companies', leaving mild ambiguity about whether it lists companies or filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives useful negative scoping ('not all-market coverage or a current officer roster'), which implicitly tells the agent when not to rely on it. However, there is no positive routing guidance against the obvious alternatives get_leadership, get_leadership_passage or list_earnings_companies, so the agent must infer when this list-level tool is preferable to the per-company getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_leadershipget_leadership_passagelist_leadership_companiesget_earningsget_earnings_passagelist_earnings_companiesget_entity_stateget_event_with_contextget_filing_parsedget_passageget_related_filingsget_timelinelist_company_filingslist_coveragelist_dealsscan_recent_eventswhats_newget_entity_stateget_event_with_contextget_filing_parsedget_related_filingslist_company_filingslist_coveragescan_recent_eventswhats_newChina A-share filings: why a number moved, does the trend continue, who supplies whom.
Insider, Congress, 13F and federal contract filings for US stocks, each linked to its source.
US stock filings, funds, insiders and Hyperliquid wallets, with sources and dates. Read-only.
Indian stocks: NSE/BSE filings read by AI with price reactions, fundamentals, IPOs and FPI flows.
Add one secure layer between your agents and this server.