Free public MCP server for AI agents to research public companies using SEC filings, financial changes, material events, insider transactions, and structured company data.
Scored across 10 tools
Most tools target distinct SEC data products—filings, financials, insider trades, risk factors—and the descriptions make those boundaries clear. The main overlap is what_changed, which intentionally aggregates financial, filing, risk, and insider changes, so it could be confused with the more specific change tools, but its description clarifies it as the broad summary tool.
All names use snake_case and are readable, but the naming convention is mixed: most are noun phrases like financial_changes and latest_filings, two are verb phrases like search_company and research_company, and what_changed breaks the pattern entirely. This is not chaotic, but it lacks a single consistent naming scheme.
With 10 tools, the server is well within the ideal 3-15 range and each tool maps to a distinct SEC research workflow. The count feels intentional rather than padded or fragmented.
The tool surface covers the core SEC research journey: find a company, get a snapshot, pull financials, compare changes, review filings, monitor material events, insider trades, risk factors, and assemble a research package. The only notable gap is that filing content is linked rather than directly retrievable, and there is no keyword search across filings.
Get a compact, sourced SEC company and financial overview.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker, company name, or SEC CIK |
| Name | Required | Description |
|---|---|---|
| data | Yes |
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 adds useful context by indicating the data is SEC-sourced and the output is a compact overview rather than an exhaustive report, but it does not describe any limitations, caveats, or additional behavioral traits.
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 focused sentence with no filler. It front-loads the action and resource while including key qualifiers ('compact', 'sourced', 'SEC') that add meaning without bloating the text.
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 simple single-parameter read tool with an output schema, the description is reasonably complete. The main missing piece is explicit differentiation from closely related sibling tools, but the core mechanics and purpose are sufficiently conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'ticker' parameter already has a descriptive comment in the schema. The description adds no additional meaning about the parameter beyond confirming this is a company-level snapshot tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') and a defined deliverable: a compact, sourced SEC company and financial overview. It conveys the tool's scope as an at-a-glance snapshot, though it does not explicitly differentiate it from siblings like research_company or financials.
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 wording 'compact...overview' implies this tool is appropriate when a concise company and financial summary is needed. However, it provides no explicit guidance on when to prefer it over siblings such as financials, research_company, or search_company, nor does it state any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare normalized financial metrics across comparable SEC reporting periods.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | quarterly | |
| ticker | Yes | Ticker, company name, or SEC CIK |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It does add meaningful behavioral context by saying metrics are 'normalized' and periods are 'comparable', but it does not explain normalization methodology, limitations, or any side-effect profile beyond the inherently read-oriented verb 'Compare'.
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 concise, front-loaded sentence with no filler. Every word contributes to the tool's core purpose, and the structure makes the main action immediately clear.
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 is relatively simple, has an output schema, and the parameters are adequately covered by the schema. Still, the description is minimal: it does not mention what financial metrics are included, whether the output is a delta or a comparison table, or how it relates to siblings like financials and what_changed.
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 50%, but the only required parameter (ticker) is already documented and the optional period parameter has an enum and default. The description adds indirect context for period selection through 'reporting periods', but it does not provide new parameter-level semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Compare') and resource ('normalized financial metrics across comparable SEC reporting periods'). It clearly conveys what the tool does, though it does not explicitly differentiate itself from siblings like financials or what_changed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when normalized, period-over-period financial comparison is needed. However, it does not explicitly say when not to use it or which sibling tool to prefer for raw financial statements or other change-focused queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return normalized high-value SEC XBRL metrics, not raw taxonomy fields.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | latest | |
| ticker | Yes | Ticker, company name, or SEC CIK |
| Name | Required | Description |
|---|---|---|
| data | Yes |
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 reveals that results are normalized and curated ('high-value'), which is useful, but it does not mention the shape of returned data, period behavior, units, coverage, or limitations. This is a minimal behavioral sketch rather than a transparent description.
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 redundancy; the verb and resource appear first. The negative clause 'not raw taxonomy fields' is useful and earns its place. It could be richer, but as a concise statement it is well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and simple parameter set, an agent can infer the core call: pass a ticker and optionally a period. However, the large sibling list and lack of usage guidance create real selection ambiguity, and the absence of annotations leaves behavioral gaps. The definition is minimally viable but not complete.
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 only 50% — ticker has a meaningful description, but period has no description beyond its enum values. The tool description does not add semantics for period (latest/quarterly/annual) or explain how the normalization works. It names the data domain but does not compensate for the missing period documentation.
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 an explicit verb ('Return') and a specific resource ('normalized high-value SEC XBRL metrics'), and it clarifies that the tool does not expose raw taxonomy fields. This gives an agent a concrete idea of what the tool produces. It doesn't explicitly differentiate it from sibling tools like financial_changes or company_snapshot, so it stops short of a 5.
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 choose financials over alternatives such as financial_changes or company_snapshot, nor any conditions for use. The phrase 'not raw taxonomy fields' hints at scope but provides no actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalize recent Form 4 insider transactions and transaction codes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| period | No | Lookback such as 30d, 6m, or 1y | 90d |
| ticker | Yes | Ticker, company name, or SEC CIK |
| Name | Required | Description |
|---|---|---|
| data | Yes |
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 says 'Normalize' without disclosing whether this is a read-only transformation, how normalization behaves, what inputs are actually used, or any limitations. The behavior remains opaque.
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 concise sentence that front-loads the main purpose without fluff. It could be slightly more illustrative, but it is appropriately sized for a straightforward tool description.
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 does not need to explain return values. However, it gives no guidance on how the tool routes among siblings or what 'normalized' output looks like, leaving an agent to infer the full context from the name and schema.
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 partial (67%), with ticker and period already described in the schema. The description adds only a loose 'recent' connection to the period parameter and says nothing about limit, so it does not meaningfully compensate for the undocumented limit 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?
States a concrete action ('Normalize') and a specific resource ('Form 4 insider transactions and transaction codes'), which clearly distinguishes it from sibling tools focused on financials, company snapshots, or material events. It is not a tautology and gives an agent a solid idea of 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when recent, normalized insider-transaction data is needed, but it does not explicitly state when to prefer this tool over siblings like latest_filings or what_changed, nor does it mention exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a company’s latest SEC filings with source links.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes | Ticker, company name, or SEC CIK | |
| filing_types | No |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. The verb 'List' communicates a non-destructive read operation, and 'with source links' adds a small output detail, but the description does not disclose ordering, default number of results, or any limitations. It is minimally transparent but not misleading.
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 one sentence with no filler. The action, resource, and a relevant output trait ('source links') are front-loaded and immediately readable.
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?
Although an output schema exists, the description is under-specified for the tool landscape: it does not clarify how `latest_filings` relates to siblings like `what_changed` or `material_events`, and it leaves input semantics incomplete. The definition supports a simple ticker-only call but not confident tool selection among alternatives.
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 only 33% and the description adds no parameter-level detail. The `filing_types` parameter is completely unexplained — an agent cannot know what string values are valid — and `limit` semantics are left entirely to schema defaults. With low coverage, the description should compensate but does not.
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 uses a specific verb ('List') and resource ('a company's latest SEC filings with source links'), so the core purpose is clear. It is distinguishable from siblings like financials or insider_transactions, though it does not explicitly compare itself to them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool instead of siblings such as what_changed or material_events. The intended use is only implied by the name and basic action, with no exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize recent 8-K or 6-K event categories with filing evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Lookback such as 30d, 6m, or 1y | 90d |
| ticker | Yes | Ticker, company name, or SEC CIK |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It discloses that the output is a summary of event categories rather than a raw filing feed, and that it will include filing evidence. It does not explicitly declare read-only behavior or edge cases, but 'summarize' and the evidence framing make the non-mutating intent clear.
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 exactly one sentence with no filler or repeated schema information. It is front-loaded with the verb and object, and every word contributes to identifying the tool's purpose.
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 two-parameter tool with an output schema, the short description plus the schema is largely sufficient for an agent to invoke it correctly. The main missing piece is explicit guidance on when to choose this tool over latest_filings or what_changed, but that gap is already accounted for in usage_guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100: both ticker and period already have full descriptions, including the period pattern and default. The description adds no parameter-level detail beyond the loose connection between 'recent' and the period parameter, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Summarize') and a precise resource ('8-K or 6-K event categories') with a clear qualifier ('with filing evidence'). This makes the tool's purpose distinct from siblings like latest_filings, which would return raw filings rather than a category summary.
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 intended use is implied: use this when you need a summarized view of material event categories from recent 8-K or 6-K filings. However, it does not explicitly say when not to use it or name any alternative sibling, such as latest_filings for raw filing lists or what_changed for broader change detection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build one sourced SEC research package without investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Lookback such as 30d, 6m, or 1y | 90d |
| ticker | Yes | Ticker, company name, or SEC CIK |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full behavioral burden, yet it only discloses that the output is SEC-sourced and not investment advice. It does not explain what the package contains, how it is assembled, or whether this is a read-only aggregation. It is not misleading, but it is minimal.
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 one compact sentence and front-loads the core purpose. It contains no filler, though 'one sourced' reads awkwardly and slightly obscures meaning.
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 not be described, but the description leaves too much unspecified for an agent selecting among many siblings. Without any indication of what a 'research package' includes or when to prefer it over company_snapshot or latest_filings, the tool is underspecified for a no-annotation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description adds no parameter-specific context; both ticker and period are already fully documented in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a concrete verb ('Build') and names the resource ('sourced SEC research package'), which broadly distinguishes it from the narrower sibling tools like financials or insider_transactions. However, 'one sourced' is awkward and the exact contents of a 'research package' are left undefined, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus siblings such as company_snapshot, latest_filings, or what_changed. The phrase 'research package' weakly implies a comprehensive alternative, but there is no explicit context, 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.
Compare risk-factor wording in the two latest comparable SEC reports.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker, company name, or SEC CIK |
| Name | Required | Description |
|---|---|---|
| data | Yes |
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. 'Compare' implies a read-only analysis, but the description does not explain how 'comparable' is determined, what happens if fewer than two reports exist, or what limitations may apply. This leaves important 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tight sentence with no filler. The verb, target, and scope are front-loaded, making it easy for an agent to grasp quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter comparison tool with an output schema, the description provides the core action and scope adequately. It does not explain the selection logic behind 'comparable' reports, but the overall definition is sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the ticker parameter already documents that it accepts a ticker, company name, or SEC CIK. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Compare'), a precise resource ('risk-factor wording'), and a clear scope ('the two latest comparable SEC reports'). This distinguishes it from sibling tools like financial_changes or what_changed, which target different comparison subjects.
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 intended use case is implied: use when you need to compare risk-factor wording across the two latest comparable SEC reports. However, the description gives no explicit guidance about when not to use it or which sibling tool to prefer for financial or general changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find an SEC company, ticker, and CIK from a name or partial ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral information. 'Find' signals a non-mutating lookup, but the description does not disclose match behavior (exact vs. partial, multiple results), how the limit applies, or any external data source/rate-limit concerns.
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 entire description is one compact sentence with no filler. It leads with the action and output objects before the input condition, making it easy to scan and immediately act on.
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 simple identifier lookup with an output schema present, the description provides the essential query semantics and result objects without needing to restate return values. It is slightly incomplete because it does not mention the limit parameter or when siblings are preferable, but the tool is low-complexity.
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 the description only adds meaning for the required query parameter by specifying 'name or partial ticker'. The optional limit parameter is left to its schema name/default/min/max, so the description compensates for only half of the 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 names a specific verb ('Find') and concrete resources ('SEC company, ticker, and CIK'), and scopes the input to 'a name or partial ticker'. This clearly distinguishes it from sibling financial-data tools, which focus on snapshots or filings rather than identifier lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for resolving a name or partial ticker into SEC identifiers, which provides clear context. However, it never explicitly states when to use this tool instead of a sibling or when another tool would be preferable. Alternatives are not named, so the routing decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the most important recent financial, filing, risk, and insider changes with sources.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Lookback such as 30d, 6m, or 1y | 90d |
| ticker | Yes | Ticker, company name, or SEC CIK |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It mentions that results include sources and that changes are filtered to 'most important,' but it does not explain how importance is determined, how results are ordered or limited, whether data is read-only, or what the output structure will be beyond what the output schema may already provide.
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, efficient sentence with no filler. It front-loads the core action and resource, though it could be slightly more structured to mention the lookback period and source behavior without becoming verbose.
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 reduces the need to explain return values, and the schema covers both parameters. However, with several closely related sibling tools, the description lacks explicit routing guidance and clarity on what 'most important' means, leaving the agent to infer when this tool is the right choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the ticker and period parameters. The description adds no new parameter-level meaning beyond the general 'changes' context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') and identifies a resource: important recent changes across financial, filing, risk, and insider categories, with sources. This distinguishes it from narrower siblings like financial_changes, latest_filings, and risk_factor_changes, though it does not name the siblings explicitly and 'most important' remains somewhat subjective.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for getting an aggregated, sourced view of multiple change types, which gives some usage context. However, it does not explicitly say when to prefer this over financial_changes, latest_filings, insider_transactions, or risk_factor_changes, nor does it state any exclusions or alternative routes.
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.
company_snapshotfinancial_changesfinancialsinsider_transactionslatest_filingsmaterial_eventsresearch_companyrisk_factor_changessearch_companywhat_changed
Add one secure layer between your agents and this server.