SEC 10-K/10-Q sections, 8-K events and a free filing index, web-to-Markdown, domain profiles; x402
Scored across 5 tools
domain_enrich and scrape_markdown are clearly distinct, and the three SEC tools mostly separate cleanly (list vs. section extract vs. event text). However, sec_list_filings and sec_recent_events both surface 8-K data, so an agent could momentarily confuse discovery of filings with retrieval of 8-K event prose, though the descriptions do resolve this.
The three sec_* tools form a consistent namespace_noun pattern, but the set mixes conventions overall: domain_enrich is noun_verb while scrape_markdown is verb_noun, and no single predictable verb_noun scheme runs throughout. It remains readable but is not uniform.
Five tools is a reasonable, well-scoped set for a read-only utility suite spanning DNS profiling, web scraping and SEC research. Each tool earns its place, though a general-purpose 'suite' could feel slightly thin at five tools.
SEC coverage is strong (list filings, extract 10-K/10-Q sections, recent 8-K events), and domain enrichment plus scraping round out the read/analysis surface. Minor gaps exist, such as no general web/company search beyond a domain or ticker, but core workflows are covered.
Answers "Who hosts this company's email, and is it configured properly?" and "Which SaaS tools does this company use?". Profiles a domain from live DNS and its website: MX records and the inferred email provider (Google Workspace, Microsoft 365, …), SPF and DMARC configuration and policy, services the domain has verified ownership with (from TXT records: Google, Microsoft, Stripe, Atlassian, …), whether the website is reachable over HTTPS, and stack and security headers (Server, X-Powered-By, HSTS, CSP). Use it for lead enrichment, email deliverability checks, vendor due diligence or security reviews. You are only charged when a result is returned: invalid input (400) and upstream failures (4xx/5xx) are not settled. Costs $0.005 USDC per call via x402. Paid per call with x402 inside MCP (see the server instructions).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to profile, e.g. example.com. A full URL is accepted; its hostname is used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: billing model ($0.005 USDC via x402), the fact that only successful results are settled and that 400/4xx/5xx responses are not charged, and the x402 payment requirement inside MCP. Annotations already cover read-only/open-world/idempotency, so this adds genuinely new operational and cost context an agent needs before calling.
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?
Front-loads the two questions the tool answers, then the data sources and outputs, then use cases and billing. It is dense but each block is purposeful; the record-type enumeration is lengthy yet directly useful for judging relevance.
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 no output schema, the description compensates by enumerating the returned fields (MX/provider, SPF/DMARC, TXT services, HTTPS, headers). Combined with annotations covering safety and the description covering cost/settlement, an agent has everything needed to call it correctly.
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%, and the single `domain` parameter is fully documented in the schema (URL accepted, hostname used). The description adds no additional syntax or format detail beyond the schema, so the baseline 3 applies.
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 specific verb and resource (profiles a domain) and enumerates exactly what is returned: MX records, inferred email provider, SPF/DMARC policy, TXT-verified services, HTTPS reachability, and stack/security headers. An agent can distinguish this from every sibling (scrape_markdown, sec_* tools) without opening the schema, since none of them perform live DNS profiling.
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?
Gives concrete scenarios — lead enrichment, email deliverability checks, vendor due diligence, security reviews — which is clear usage context. It stops short of explicit when-not-to-use guidance or naming an alternative tool, so it does not reach the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use it when an agent needs to read a web page: an article, documentation, a blog post, a product or pricing page, a news story. Fetches a public web page and returns its main content as clean Markdown, ready to put in an LLM context: scripts, styles, navigation, headers, footers and sidebars are removed, the article body is extracted (Readability), and links are made absolute. Returns the page title, the final URL after redirects and the character count; output is capped at 100,000 characters. Use it to read articles, docs, blog posts or product pages. Pages that need JavaScript to render may return little content. You are only charged when a result is returned: invalid input (400) and upstream failures (4xx/5xx) are not settled. Costs $0.005 USDC per call via x402. Paid per call with x402 inside MCP (see the server instructions).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL of the page to convert, e.g. https://example.com/article. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only/idempotent/open-world, but the description adds substantial context they cannot: Readability-based extraction, absolute links, removal of nav/footer/sidebar, the 100k character cap, the JS-rendering failure mode, and detailed billing semantics (charged only on a returned result; 400 and upstream 4xx/5xx not settled; $0.005 USDC via x402).
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?
Front-loaded with the use case and outcome, and the billing/limit details are worth their space. It is slightly bloated by restating the use cases twice ('read a web page...' then 'Use it to read articles, docs, blog posts or product pages').
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?
No output schema exists, and the description compensates by describing the return payload (title, final URL, character count) plus the cap, the JS caveat, and the payment model. Nothing an agent needs to invoke it correctly is missing.
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?
Only one parameter with 100% schema description coverage, so the schema carries the semantics. The description reinforces that the page must be public and notes the final URL after redirects, but adds no syntax or format detail beyond the schema. Baseline 3 applies.
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 specific verb+resource ('Fetches a public web page and returns its main content as clean Markdown') and enumerates the content types it targets. An agent can immediately tell this is the general web-page reader, distinct from the SEC-filing and domain-enrichment siblings.
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?
Gives explicit triggering contexts ('Use it when an agent needs to read a web page: an article, documentation, a blog post...') and discloses a key limitation about JavaScript-rendered pages. It does not, however, name the sibling tools or state when to prefer them over this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answers questions like "What are Tesla's risk factors?", "What did Apple's MD&A say about margins?" or "How has Microsoft's cybersecurity disclosure changed since 2023?". Returns exactly one section of a US public company's 10-K (annual) or 10-Q (quarterly) report from SEC EDGAR as clean text, ready for an LLM: Risk Factors (Item 1A), Management's Discussion and Analysis (MD&A), Business, Legal Proceedings, Market Risk, or Cybersecurity. Look up by stock ticker or CIK. Defaults to the latest filing; pass fiscal_year (2001 on) for an earlier year's report, e.g. to compare how risk factors changed, or accession_number for an exact filing (the free sec_list_filings tool lists them, with the sections each one has). The table of contents, page numbers, hidden XBRL data and HTML are removed; tables are kept as readable rows. Includes the filing date, fiscal period, accession number and sec.gov link for citation. Use it for investment research, due diligence, competitor analysis or risk monitoring without downloading a 100-page filing. Sections up to 200,000 characters. If the filing's item only points elsewhere ("See Note 12"), you get 404 SECTION_INCORPORATED_BY_REFERENCE with that pointer, free. You are only charged when a result is returned: invalid input (400) and upstream failures (4xx/5xx) are not settled. Costs $0.02 USDC per call via x402. Paid per call with x402 inside MCP (see the server instructions).
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | SEC Central Index Key, e.g. 320193. Use this or `ticker`. | |
| form | No | Annual report (10-K, the default) or quarterly report (10-Q). With `accession_number`, taken from that filing. | |
| ticker | No | US stock ticker, e.g. AAPL, MSFT, BRK-B. Use this or `cik`. | |
| section | Yes | Which section to return: risk_factors, mda (Management's Discussion and Analysis), business, legal_proceedings, market_risk, or cybersecurity (10-K only, filings from late 2023 on). | |
| fiscal_year | No | Return the report whose fiscal period ends in this calendar year instead of the latest one, e.g. 2022 for Apple's 10-K for the year ended September 24, 2022. For a 10-Q, the latest quarter ending in that year. EDGAR has HTML filings from 2001 on. | |
| accession_number | No | Return the section from this exact 10-K or 10-Q filing of the company, e.g. 0000320193-22-000108. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, non-destructive, but the description adds substantial behavior: sections capped at 200,000 characters, cleanup of TOC/page numbers/XBRL/HTML with tables preserved as rows, the 404 SECTION_INCORPORATED_BY_REFERENCE outcome, and a full billing model ($0.02 USDC via x402, charged only on returned results, free on 400/4xx/5xx).
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?
Front-loaded with concrete question examples and the core 'returns one section' statement, and every paragraph carries needed content (lookup modes, cleanup, citation, limits, pricing). It runs long, but for a paid tool with a non-obvious billing model and cleanup semantics, the length is largely justified rather than padded.
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?
No output schema exists, yet the description explains the return shape (clean text section, tables as rows, citation metadata with filing date, fiscal period, accession number, sec.gov link), size limit, error semantics, and cost. An agent has everything needed to call and interpret results.
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 is 3. The description adds contextual meaning beyond the schema: fiscal_year is framed as '2001 on' and motivated by comparing risk-factor changes, and accession_number is linked to the free sec_list_filings tool that enumerates 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?
States a specific verb and resource: 'Returns exactly one section of a US public company's 10-K (annual) or 10-Q (quarterly) report from SEC EDGAR as clean text.' It explicitly enumerates the section types and distinguishes itself from the sibling sec_list_filings by name, so an agent can route correctly without opening schemas.
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?
Explicitly names when to use it (investment research, due diligence, competitor analysis, risk monitoring), how to select an earlier year via fiscal_year for comparison, and the alternative sec_list_filings for enumerating filings and their sections. It even describes the fallback behavior when a section is incorporated by reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, no payment needed. Lists a US public company's 10-K (annual), 10-Q (quarterly) and 8-K (material event) filings from SEC EDGAR, newest first: filing date, fiscal year and period, sec.gov link, the sections sec_filing_section can extract from each report (Risk Factors, MD&A, Business, Legal Proceedings, Market Risk, Cybersecurity), and the event items of each 8-K (earnings 2.02, executive changes 5.02, deals 1.01, cybersecurity incidents 1.05, …). Every filing carries next_call: the exact paid tool call, with arguments and price, that returns its text. Use it to check what exists before paying, to find a specific year or event, or to track new filings. Filter by form and date (back to 2001); up to 50 filings per call. Look up by stock ticker or CIK. Rate-limited per client.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | SEC Central Index Key, e.g. 320193. Use this or `ticker`. | |
| forms | No | Which filings to list: 10-K (annual), 10-Q (quarterly), 8-K (material events). Default: all three. | |
| limit | No | How many filings to return, newest first (1-50, default 20). | |
| since | No | Only filings filed on or after this date (YYYY-MM-DD). Reaches back to 2001. | |
| ticker | No | US stock ticker, e.g. AAPL, MSFT, BRK-B. Use this or `cik`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description adds context annotations cannot carry: it is free while the follow-up call is paid, results are newest-first, up to 50 per call, coverage reaches back to 2001, and the endpoint is rate-limited per client. That is meaningful behavioral disclosure beyond structured fields.
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?
Front-loaded with the key differentiator ('Free, no payment needed') and densely packed with useful facts, but it is a long, semicolon-chained block that mixes return-shape, usage, and limits in one breath. Slightly long, though nearly every clause 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?
With no output schema, the description carries the burden of describing returns and does so thoroughly: filing date, fiscal year/period, sec.gov link, extractable sections, 8-K event items, and the `next_call` object with arguments and price. An agent has everything needed to call and interpret this 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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning the schema lacks: filtering is 'back to 2001', the per-call cap is framed as 50, and lookup is by ticker OR CIK. It does not explain how form/date filters interact, but it does more than restate 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 states a specific verb (lists) and resource (SEC filings from EDGAR) and enumerates exactly which forms (10-K, 10-Q, 8-K) with what fields are returned. It also distinguishes itself from the sibling sec_filing_section by framing itself as the free discovery step that returns `next_call` for the paid extraction tool.
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 explicit when-to-use guidance: 'check what exists before paying, to find a specific year or event, or to track new filings,' and implicitly routes paid text retrieval to sec_filing_section via the `next_call` field. The free-vs-paid boundary is stated up front so the agent knows why to pick this over the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answers "What happened at this company lately?": did the CEO or CFO leave, what were the latest earnings, was there an acquisition, major contract or cyber incident. Returns a US public company's most recent 8-K filings from SEC EDGAR, newest first: the material events companies must report within four business days, such as earnings releases (Item 2.02), CEO, CFO and director changes (5.02), material agreements and acquisitions (1.01, 2.01), cybersecurity incidents (1.05), impairments, auditor changes and shareholder votes. Each event has its item codes with official titles, the 8-K text as clean prose, and the text of its press-release exhibits (EX-99), e.g. the full earnings release. Filter by item codes and filing date, or ask for one exact 8-K by accession_number (the free sec_list_filings tool lists them); up to 10 events per call. Look up by stock ticker or CIK. Use it for event monitoring, news and earnings agents, due diligence or trading research, with sec.gov links for citation. If no 8-K matches, you get 404 FILING_NOT_FOUND, free. You are only charged when a result is returned: invalid input (400) and upstream failures (4xx/5xx) are not settled. Costs $0.02 USDC per call via x402. Paid per call with x402 inside MCP (see the server instructions).
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | SEC Central Index Key, e.g. 320193. Use this or `ticker`. | |
| items | No | Only events reporting one of these 8-K items, e.g. ["5.02"] for executive and director changes, ["2.02"] for earnings releases, ["1.01", "2.01"] for deals, ["1.05"] for cybersecurity incidents. | |
| limit | No | How many events to return, newest first (1-10, default 5). | |
| since | No | Only events filed on or after this date (YYYY-MM-DD). | |
| ticker | No | US stock ticker, e.g. AAPL, MSFT, BRK-B. Use this or `cik`. | |
| accession_number | No | Return only this 8-K, e.g. one found with the free sec_list_filings tool. | |
| include_exhibits | No | Include the text of press-release exhibits (EX-99), e.g. the earnings release. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Unlike what annotations supply, the description discloses the pricing model ($0.02/call via x402), the free 404 FILING_NOT_FOUND path, the fact that invalid input and upstream failures are not settled, a 10-event cap, and that text is returned as clean prose with EX-99 exhibits. It also supplies the 4-business-day reporting context. Minor gap: no explicit rate limits or idempotency caveats beyond what annotations imply.
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 front-loads the agent's core question and then packs pricing, exhibits, filtering, and error semantics efficiently. It is long for one paragraph, but nearly every clause carries operational information; only minor streamlining is possible.
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 7-param, 0-required read-only tool with no output schema, the description covers what is returned (item codes with official titles, clean-prose 8-K text, EX-99 events), how it is filtered, how to identify a specific filing, cost and error handling. Nothing critical for correct invocation is missing.
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%, so the schema already documents every field, establishing a baseline of 3. The description adds value by explaining the item-code mechanism with concrete examples (5.02 executive changes, 2.02 earnings, 1.05 cyber), describing the accession-number route and its source, and confirming ticker/CIK lookup, which improves on the schema's short field descriptions.
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 plain-language question, states the specific resource (US public company 8-K filings from SEC EDGAR), and enumerates the concrete event types it returns. It clearly distinguishes itself from siblings like sec_list_filings (which it names as the free lister) and sec_filing_section.
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 explicit use cases (event monitoring, news/earnings agents, due diligence, trading research) and routes agents to sec_list_filings for accession numbers, and to ticker/CIK for lookup. It lacks explicit 'when not to use' guidance versus sec_filing_section, but the context is clear enough to select correctly.
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.
domain_enrichscrape_markdownsec_filing_sectionsec_list_filingssec_recent_eventsSEC EDGAR filings parsed: 8-K body-text classification, 13D activist tagging, S-3 ATM detection.
SEC-signed profiles for 8,000+ US public companies from EDGAR filings. Token-efficient.
SEC filings, XBRL earnings, Form 4 insiders for ~2,800 US SEC filers. x402 pay-per-call, no signup.
Normalized SEC EDGAR data for AI agents: XBRL financials, 10-K risk diffs, Form 4 insider trades.
Add one secure layer between your agents and this server.