Company filing/CVE snapshots, status and optional feedback. Remote MCP or local stdio. Free Phase A.
Scored across 3 tools
Each tool targets a distinct domain: company filing evidence, CVE evidence, and optional feedback submission. There is no meaningful overlap between the two snapshot tools or the feedback tool.
The two evidence tools follow a clear `<domain>_snapshot` pattern, while the feedback tool uses a verb-based `submit_` prefix. This is a minor stylistic deviation but remains predictable and readable.
Three tools is well-scoped for the stated purpose of returning focused evidence snapshots and collecting feedback. Each tool earns its place without unnecessary bulk.
The server covers both stated evidence domains—company filing events and CVE data—and includes a feedback tool for handling missing evidence. The snapshot descriptions clearly define boundaries, and no critical operation appears missing for the intended workflow.
Use for current SEC filing-event state for a known ticker. Returns issuer/CIK, filing dates and source links with explicit source timestamps, coverage and expiry. Not financial-statement extraction, earnings transcripts or broad equity research.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | status returns selected fields from the same cached source packet; Phase A is free. | |
| ticker | Yes | ||
| max_age | No | Alias for max_age_seconds; no forced refresh. | |
| history_days | No | Positive history depth is an unsupported-capability signal, not implemented history. | |
| changed_since | No | With view=status: a previous facts.state_hash. Compares selected state, not timestamp history. Unknown on source failures. | |
| desired_fields | No | Comma-separated allowlisted field names; at most four. Preference only; supported requests still return the complete packet. Supported: issuer_identity, latest_filing, recent_filing_events, filing_source_links. Research-only: earnings_history, capital_structure, guidance_changes. | |
| compare_sources | No | true requests unsupported comparative source reconciliation. | |
| max_age_seconds | No | Optional declared maximum age. Too-old evidence returns 409; does not force upstream refresh. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | |
| facts | Yes | |
| query | Yes | |
| status | No | |
| changes | Yes | |
| sources | Yes | |
| coverage | Yes | |
| data_hash | Yes | |
| packet_key | Yes | |
| terms_hash | Yes | |
| result_hash | Yes | |
| valid_until | Yes | |
| buyer_assent | Yes | |
| generated_at | Yes | |
| product_mode | Yes | |
| terms_version | Yes | |
| packet_version | No | |
| schema_version | Yes | |
| feedback_request | No | |
| methodology_hash | Yes | |
| validation_metrics | Yes | |
| available_capability | No | |
| requested_capability | No | |
| requested_capabilities | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only, idempotent, and non-destructive signals, so the description adds useful context by promising explicit source timestamps, coverage, and expiry. This helps an agent understand freshness and scope beyond the annotation booleans. It does not disclose unknown-ticker failure behavior, but that is not critical given the schema and output schema.
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 two sentences with the core use case front-loaded and exclusions placed after. There is no repetition of schema details and no filler; every sentence contributes decision-useful information.
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 rich schema, enums, output schema, and annotations, the description provides the essential decision context without duplicating structured data. It covers what the tool is for, what it returns, and what it is not for, which is sufficient for correct selection and 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 description coverage is 88%, and the parameters already carry detailed descriptions for view, max_age, history_days, changed_since, desired_fields, compare_sources, and max_age_seconds. The description adds no parameter-level semantic guidance beyond 'known ticker,' but with high schema coverage, 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 states a specific purpose: 'Use for current SEC filing-event state for a known ticker' and names concrete outputs such as issuer/CIK, filing dates, and source links. It also distinguishes itself by explicitly excluding financial-statement extraction, earnings transcripts, and broad equity research.
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 a clear when-to-use trigger ('Use for current SEC filing-event state for a known ticker') and explicit non-goals ('Not financial-statement extraction, earnings transcripts or broad equity research'). It does not name a specific alternative tool to route to, but the exclusions are concrete enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for current evidence on a known CVE ID. Returns NVD status, CISA KEV membership, FIRST EPSS and advisory links with explicit source timestamps, coverage and expiry. Not asset applicability or validated remediation.
| Name | Required | Description | Default |
|---|---|---|---|
| cve | Yes | ||
| view | No | status returns selected fields from the same cached source packet; Phase A is free. | |
| max_age | No | Alias for max_age_seconds; no forced refresh. | |
| history_days | No | Positive history depth is an unsupported-capability signal, not implemented history. | |
| changed_since | No | With view=status: a previous facts.state_hash. Compares selected state, not timestamp history. Unknown on source failures. | |
| desired_fields | No | Comma-separated allowlisted field names; at most four. Preference only; supported requests still return the complete packet. Supported: nvd_status, nvd_dates, cvss, cisa_kev, epss, vendor_advisory_links. Research-only: affected_versions, patch_status, severity_history. | |
| compare_sources | No | true requests unsupported comparative source reconciliation. | |
| max_age_seconds | No | Optional declared maximum age. Too-old evidence returns 409; does not force upstream refresh. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | |
| facts | Yes | |
| query | Yes | |
| status | No | |
| changes | Yes | |
| sources | Yes | |
| coverage | Yes | |
| data_hash | Yes | |
| packet_key | Yes | |
| terms_hash | Yes | |
| result_hash | Yes | |
| valid_until | Yes | |
| buyer_assent | Yes | |
| generated_at | Yes | |
| product_mode | Yes | |
| terms_version | Yes | |
| packet_version | No | |
| schema_version | Yes | |
| feedback_request | No | |
| methodology_hash | Yes | |
| validation_metrics | Yes | |
| available_capability | No | |
| requested_capability | No | |
| requested_capabilities | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds valuable behavioral context beyond annotations: it mentions explicit source timestamps, coverage, and expiry, and it clarifies that the tool returns cached evidence with a declared maximum age (409 on too-old evidence). It also discloses that some parameters are 'unsupported-capability signals' (history_days, compare_sources) and that desired_fields is a preference only, which is important behavioral transparency. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. The first sentence front-loads the core purpose and the key data domains, and the second sentence immediately clarifies scope exclusions. Every word earns its place, and the structure is ideal for an agent scanning 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?
Given the tool's complexity (8 parameters, 4 enums, output schema present) and the rich annotations, the description is largely complete. It covers the core purpose, the data returned, the source timestamps/coverage/expiry, and the negative scope. The output schema exists, so return values need not be described. The only minor gap is that it does not explicitly mention the caching/409 behavior in the description (though max_age_seconds schema does), and it does not name sibling tools for routing. Still, for an evidence-lookup tool with strong annotations and schema, this is a high level of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, so the schema already documents most parameters well. The description adds meaning by clarifying the overall semantics: it frames the tool as returning a 'cached source packet' with timestamps, coverage, and expiry, which helps interpret parameters like max_age, changed_since, and desired_fields. It also explicitly states that desired_fields is a preference and that history_days is not implemented history. This adds value beyond the schema, though the description does not need to repeat every parameter detail given the high schema coverage.
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 ('Use for current evidence on a known CVE ID') and a specific resource (CVE ID), and enumerates the exact data domains returned (NVD status, CISA KEV, FIRST EPSS, advisory links). It also explicitly distinguishes what it is not ('Not asset applicability or validated remediation'), which differentiates it from potential sibling tools like company_snapshot. This is a clear, specific, and well-scoped purpose statement.
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 clearly indicates when to use the tool: when you need current evidence on a known CVE ID, and it explicitly states what it is not for ('Not asset applicability or validated remediation'). However, it does not explicitly name alternative tools or provide a when-not-to-use condition beyond the negative scope. The sibling tools (company_snapshot, submit_fishnet_feedback) are not referenced, so the guidance is clear but not fully comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Optionally submit what you would have done next without enough Fishnet evidence. Use the packet feedback token and bounded schema. Writes feedback telemetry only; no payment, trading or other action. Never submitted automatically. Free text is classified then discarded; omit personal data and prompts.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| importance | No | ||
| packet_key | Yes | ||
| usage_reason | No | ||
| feedback_type | Yes | ||
| desired_fields | No | ||
| packet_version | Yes | ||
| schema_version | Yes | ||
| packet_endpoint | Yes | ||
| desired_capability | No | ||
| short_request_text | No | At most 240 UTF-8 bytes; no personal data, URLs, credentials or full prompts. Classified coarsely then discarded. | |
| desired_capabilities | No | ||
| desired_history_days | No | ||
| expected_calls_per_day | No | Self-reported future frequency; not measured use. | |
| max_acceptable_price_usd | No | Self-reported price, at most six decimal places; never payment evidence. | |
| desired_freshness_seconds | No | ||
| next_action_without_fishnet | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite all annotations being false, the description discloses key side effects: 'Writes feedback telemetry only; no payment, trading or other action,' 'Never submitted automatically,' and 'free text is classified then discarded.' This goes beyond the annotations by explaining the data handling and side-effect scope, which is valuable for an agent.
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 two sentences with no redundant words, front-loading the purpose and critical constraints. It is appropriately concise, though it could be arranged with bullet points for even quicker scanning, which is why it does not receive a 5.
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 complex tool with 17 parameters and no output schema, the description is too sparse. It does not explain how to choose the various feedback types, what the token represents, or what schemas are 'bounded.' This leaves significant gaps that an agent must fill via the schema alone, which many parameters lack descriptions for.
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 18%, so the description must carry the burden of explaining parameters, but it only mentions the 'packet feedback token' and 'free text' (likely short_request_text). It does not explain the meaning or selection of the many enum-driven parameters like feedback_type, usage_reason, or desired_capabilities, leaving agents to rely solely on the enum names without additional context.
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 explicitly states the tool 'submits what you would have done next without enough Fishnet evidence,' clearly indicating its purpose as a feedback mechanism. It distinguishes itself from sibling snapshot tools by emphasizing it 'writes feedback telemetry only' and involves no payment/trading, making it unambiguous 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 provides a clear trigger condition: use when there is 'without enough Fishnet evidence.' It also states it is 'optional' and 'never submitted automatically,' and warns against including personal data. However, it does not explicitly contrast with the snapshot tools, so an agent must infer when to prefer this over its siblings, slightly reducing the clarity of when-not-to-use.
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_snapshotcve_snapshotsubmit_fishnet_feedbackQuery SEC EDGAR filings, XBRL financials, and company data through MCP. STDIO & Streamable HTTP.
Companies House MCP — UK statutory company registry (BYO key)
NVD MCP — wraps the NIST National Vulnerability Database API (free, no auth)
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
