Computed SEC, Federal Register, federal funding and research-momentum signals
Scored across 5 tools
The main tools (search, get, list, balance) are clearly distinct, but answerpool_sec_company overlaps with answerpool_get since get can run SEC products too. The descriptions mitigate this by framing sec_company as a one-call convenience wrapper.
All names share the answerpool_ prefix and use snake_case, but verb patterns are inconsistent: list_products and search_catalog are verb_noun, while credit_balance, get, and sec_company are noun or verb-only. The generic answerpool_get is also less descriptive than the others.
Five tools is well-scoped for a product gateway: discover, execute, list, check balance, plus one convenience wrapper. Each tool serves a clear role without bloat.
The tool surface covers the full user journey: find the right product, list all products, execute any product, and check credits. The SEC snapshot is a bonus convenience; no critical workflow appears missing.
Check the remaining credit balance for your API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this by stating it only checks a balance, and adds the useful context that the balance is tied to the API key. No side effects, auth requirements, or rate-limit concerns need to be disclosed for this read-only operation.
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, direct sentence with no filler. It front-loads the action and resource, making it immediately scannable and useful for an 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?
This is a minimal, zero-parameter read-only tool with an output schema and annotations already covering safety. The description fully states what the tool does, and there are no missing prerequisites, side effects, or alternative routing concerns that an agent would need.
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?
The tool accepts zero parameters, so there is no parameter semantic burden on the description. The schema fully covers the empty parameter set, and the description appropriately focuses on the result rather than inputs.
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 ('Check') and clearly identifies the resource ('remaining credit balance for your API key'). It is unambiguous and distinct from sibling tools, which focus on data retrieval, funding signals, or catalog searches rather than account balance.
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 makes clear that this tool is for checking the credit balance associated with the caller's API key. No explicit alternative is named, but the context is self-evident and the tool's zero-parameter nature reduces ambiguity about when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RUN ANY of the 137 AnswerPool products by id — this plus answerpool_search_catalog is the main path, and every product is reachable this way. Find an id with answerpool_search_catalog, then pass its inputs as a JSON object, e.g. {"product_id": "weather_alerts", "params": {"area": "CA"}}. Covers SEC filings, fundamentals and insider activity, Federal Register rulemaking, federal procurement and grants, NIH, clinical trials, FDA recalls and adverse events, US macro indicators, weather and severe-weather alerts, known-exploited vulnerabilities, research-topic momentum and entity resolution. Each product's input and output schema is in the catalog entry. Free products need no key; paid ones debit a prepaid credit key and are never charged on failure. Pass sample=true to see a real answer from any product free before paying.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | ||
| sample | No | ||
| product_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and non-destructive; the description adds valuable non-obvious behavior: paid products debit a prepaid credit key, failures are never charged, sample=true returns a free real answer, and each product's schema lives in the catalog. It also enumerates the broad coverage domains and clarifies that every product is reachable by id. 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 longer than minimal, but each block earns its place: primary action, workflow, example, coverage list, catalog schema pointer, billing behavior, and sample option. The coverage list is somewhat long, but it is useful for a broad dispatch tool; the most actionable instructions are front-loaded.
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 generic gateway over 137 products, this is complete: it explains how to discover ids, how to pass params, where per-product input/output schemas live, billing behavior, and how to sample before paying. The output schema is intentionally delegated to the catalog, and annotations already cover the safety profile.
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?
With schema description coverage at 0%, the description fully compensates. It explains product_id is found via answerpool_search_catalog, params is a JSON object (with a concrete weather_alerts example), and sample is a boolean that returns a free real answer. The example ties all three parameters together in one usable shape.
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 starts with the specific action 'RUN ANY of the 137 AnswerPool products by id' and clearly distinguishes this execution tool from answerpool_search_catalog, which is used to find ids. It is not a tautology of the title; it communicates that this is the universal gateway to all products.
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 explicitly describes the intended workflow: use answerpool_search_catalog to find an id, then call this tool with product_id and params, calling it the 'main path.' It does not, however, discuss when to prefer specialized siblings like answerpool_sec_company or when to use answerpool_list_products, so exclusions are not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all AnswerPool products with prices, inputs and when to use each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about what the listing contains (prices, inputs, usage guidance) but does not disclose additional behaviors such as pagination, ordering, or completeness limits. This is acceptable given the simple read-only nature.
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?
A single, front-loaded sentence states the action, scope, and expected content. Every word contributes meaning, and there is no redundant or filler 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 zero-parameter, read-only listing tool with an output schema and safety annotations, the description is fully adequate. It tells the agent what will be returned and none of the structured metadata needs further elaboration.
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?
The tool has zero parameters, so the schema fully documents the input surface. The description's mention of 'inputs' refers to product-level inputs described in the output, not call parameters. No parameter documentation burden exists, so the baseline of 4 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?
The description clearly states the tool lists all AnswerPool products and specifies the contents (prices, inputs, when to use each). This distinguishes it from sibling tools like answerpool_credit_balance or answerpool_search_catalog, which target different resources.
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 used for discovering product information but does not explicitly say when to prefer it over siblings or when not to use it. The context is reasonably clear because it is a standalone listing tool, but no alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FIND THE RIGHT DATA PRODUCT. Search 130+ computed products across SEC filings and fundamentals, federal regulation, procurement and grants, NIH, clinical trials, FDA recalls and adverse events, US macro indicators, weather and severe-weather alerts, known-exploited software vulnerabilities, research topics, and cross-domain entity resolution. Returns matching product ids with price, inputs and a free sample_url showing a real answer from that product; pass a product id to answerpool_get. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| free_only | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so safety is covered. The description adds that it returns product ids with price, inputs, and a sample_url, and explicitly notes it is 'Free'. This gives the agent useful behavioral context beyond the 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 front-loaded with an imperative 'FIND THE RIGHT DATA PRODUCT' and lists domains compactly. It is somewhat dense but each sentence serves a purpose—scope, output, and routing. No redundant filler.
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 values are covered elsewhere. However, the description does not explain the input parameters (query, limit, free_only) which are undocumented in the schema. For a search tool, an agent needs to know how to construct a query. The description gives domain hints but no parameter semantics, leaving an incomplete picture.
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 explain parameters. It only vaguely touches on 'free' in the last sentence, which loosely relates to free_only, but does not explain limit, query, or free_only explicitly. The agent is left to infer what query should contain or what limit controls.
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 the verb 'Search' and the resource 'catalog', enumerates the domains covered, and explicitly differentiates from the sibling tool answerpool_get by instructing to pass a product id there. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear workflow: search for products, then pass the product id to answerpool_get. This implies when to use this tool (discovery) versus get (retrieval), though it does not explicitly mention when to prefer list_products over search. The guidance is sufficient for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call SEC snapshot of a US public company: recent filings, indexed events, insider activity, key XBRL facts (revenue, income, cash). $0.02/call.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | ||
| ticker | No |
| Name | Required | Description |
|---|---|---|
| cik | Yes | Registrant's SEC Central Index Key, 10 digits zero-padded (e.g. 0000320193), resolved from the ticker when one was supplied. Use this form in other views. |
| sic | Yes | Standard Industrial Classification code for the registrant's primary industry as assigned by the SEC, typically 4 digits (e.g. 3571); null when EDGAR has none. |
| name | Yes | Registrant name as published on EDGAR's submissions record; empty string when EDGAR carries no name for the CIK. |
| as_of | Yes | ISO-8601 UTC timestamp with milliseconds (e.g. 2026-09-03T14:05:00.000Z) at which this snapshot was assembled. EDGAR is queried live, so it is the read time rather than a fixed data cut-off. |
| facts | Yes | XBRL financial series keyed by revenue, net_income, total_assets, cash, operating_cash_flow and shares_outstanding; each is up to the 8 most recent periods ordered oldest to newest. A key is absent when the registrant reports no matching concept, and the map is empty when XBRL company facts are unavailable. |
| sources | Yes | Public EDGAR API URLs this snapshot was compiled from, keyed `submissions` and `companyfacts`. Re-fetching them reproduces the underlying facts. |
| tickers | Yes | Every exchange ticker EDGAR lists for this registrant, uppercase, in EDGAR's own order. Empty for private, unlisted or deregistered filers. |
| method_id | No | Identifier and version of the rule set behind the flags and scores in `events_30d`. It changes when the method changes; results carrying different method_ids are not directly comparable. |
| disclaimer | No | Fixed notice that this snapshot is compiled from public SEC filings and is not investment advice. |
| events_30d | Yes | Events derived from this registrant's filings over the last 30 days, most recent first, capped at 50. Empty when nothing was filed or our event index does not yet cover the period. |
| insider_90d | Yes | Form 4 insider-trading summary for the last 90 days: `filings` (insider events counted), `buy_usd` and `sell_usd` (open-market purchase and sale value in whole US dollars) and `net_usd` (buy_usd minus sell_usd, negative on net selling). |
| recent_filings | Yes | Up to the 15 most recent filings of any form from EDGAR's submissions record, most recent first. Each element has `form`, `filed` (ISO-8601 filing date), `accession`, `description` (primary document description, may be empty) and `url` (index page). |
| fiscal_year_end | Yes | Registrant's fiscal year end as a four-character MMDD string (e.g. 0930 for 30 September); null when EDGAR has none on record. |
| sic_description | Yes | Industry title EDGAR pairs with `sic` (e.g. Electronic Computers); null whenever `sic` is null. |
| state_of_incorporation | Yes | Jurisdiction the registrant is incorporated in as a two-character code — a US state code such as DE, or an SEC country code. This is not the business address; null when EDGAR has none. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint false, covering the safety profile. The description adds useful context about output contents and the $0.02/call cost, but it does not disclose edge cases such as behavior when both cik and ticker are provided or when no match is found.
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?
A single front-loaded sentence conveys the core purpose, key content categories, and cost with no filler. Every phrase 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?
The description and output schema cover what the tool returns, but an agent still lacks guidance on how to identify the company via cik or ticker, whether one is required, or how conflicts are resolved. The omitted parameter-usage detail leaves the callable contract incomplete.
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 parameter descriptions are completely absent (0% coverage), and the description does not compensate by explaining cik or ticker, their formats, or that at least one appears needed despite both being nullable. The parameter names are somewhat self-explanatory, but the description adds no direct semantics.
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 identifies the resource as a one-call SEC snapshot for US public companies and enumerates the specific data types (filings, events, insider activity, XBRL facts). This distinguishes it from sibling tools like catalog search or credit balance.
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 a use case for SEC company data but provides no explicit when-to-use guidance, no alternatives, and no mention that cik or ticker must be supplied. It does not say when this tool should be chosen over siblings or when it should not.
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.
answerpool_get1 field changedInput schema / properties / sampleAdded value: +{
+ "default": false,
+ "title": "Sample",
+ "type": "boolean"
+}answerpool_funding_signalsanswerpool_reg_rulesanswerpool_sec_company5 fields changedOutput schema / $defsAdded value: +{
+ "Event": {
+ "properties": {
+ "accession": {
+ "description": "SEC accession number of the filing the event was derived from, in dashed form 0000000000-00-000000. Identifies the filing uniquely on EDGAR.",
+ "title": "Accession",
+ "type": "string"
+ },
+ "cik": {
+ "description": "SEC Central Index Key of the issuer, 10 digits zero-padded (e.g. 0000320193). For ownership and Form D events this is the issuer, never the reporting insider.",
+ "title": "Cik",
+ "type": "string"
+ },
+ "company": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Issuer or registrant name as carried on the filing; null when the source feed supplied no name.",
+ "title": "Company"
+ },
+ "event_id": {
+ "description": "Stable identifier for this event row, formatted `ev_` followed by 20 hex characters. Unique across the feed and safe to use for de-duplication between calls.",
+ "title": "Event Id",
+ "type": "string"
+ },
+ "event_type": {
+ "description": "Kind of event: `form_8k` (8-K current report), `insider_transaction` (ownership form reporting buys or sells) or `private_offering` (Form D exempt offering).",
+ "title": "Event Type",
+ "type": "string"
+ },
+ "filing_url": {
+ "description": "Absolute sec.gov URL of the filing's EDGAR index page, from which every document in the filing can be reached. Use it to verify the event against the source.",
+ "title": "Filing Url",
+ "type": "string"
+ },
+ "flags": {
+ "description": "Analytical tags derived for this filing (e.g. distress, leadership_change, large_insider_buy), sorted and de-duplicated; empty when nothing was flagged. The `sec_flag_glossary` view defines every flag we emit.",
+ "items": {
+ "type": "string"
+ },
+ "title": "Flags",
+ "type": "array"
+ },
+ "form": {
+ "description": "EDGAR form type of the source filing. The event index covers 8-K, D and the insider ownership forms, which are all recorded as `4`.",
+ "title": "Form",
+ "type": "string"
+ },
+ "occurred_at": {
+ "description": "When the filing became public on EDGAR: the filing date (ISO-8601 YYYY-MM-DD) for 8-K events, an ISO-8601 timestamp to the second for ownership and Form D events. This is the filing moment, not the date of the underlying transaction or event.",
+ "title": "Occurred At",
+ "type": "string"
+ },
+ "payload": {
+ "additionalProperties": true,
+ "description": "Form-specific detail. `form_8k` carries `items` (8-K item codes) and `labels`; `insider_transaction` carries `owner`, `buy_usd`, `sell_usd`, `n_buys`, `n_sells`; `private_offering` carries `total_offering_usd`, `sold_usd`, `investors`, `industry_group`, `state`, `is_amendment`. All USD amounts are whole dollars.",
+ "title": "Payload",
+ "type": "object"
+ },
+ "score": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "How notable this event is, 0 to 1, where higher means the flags on it are more materially significant; an event with no flags scores 0. Null when the row carries no score.",
+ "title": "Score"
+ },
+ "ticker": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Uppercase US exchange ticker for the issuer when one is known from the SEC ticker file; null for unlisted issuers, which is common on Form D.",
+ "title": "Ticker"
+ }
+ },
+ "required": [
+ "event_id",
+ "accession",
+ "cik",
+ "ticker",
+ "company",
+ "form",
+ "event_type",
+ "occurred_at",
+ "flags",
+ "score",
+ "payload",
+ "filing_url"
+ ],
+ "title": "Event",
+ "type": "object"
+ },
+ "FactPoint": {
+ "properties": {
+ "end": {
+ "description": "Last day of the period the figure covers, ISO-8601 YYYY-MM-DD, as tagged in the filing's XBRL: the measurement instant for balance-sheet items, the period end for flow items. This is a reporting-period boundary, not the filing date.",
+ "title": "End",
+ "type": "string"
+ },
+ "form": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "EDGAR form the figure was reported on. Only annual (10-K) and quarterly (10-Q) reports are included, so other form types never appear here.",
+ "title": "Form"
+ },
+ "fp": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Fiscal period the filing assigned to the figure: FY for a full year, or Q1, Q2, Q3 or Q4 for a quarter.",
+ "title": "Fp"
+ },
+ "fy": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Fiscal year the filing assigned to the figure (e.g. 2025). This is the registrant's own fiscal-year label and need not match the calendar year of `end`.",
+ "title": "Fy"
+ },
+ "value": {
+ "description": "Value exactly as reported, in the concept's native XBRL unit: US dollars for the monetary series and shares for shares_outstanding. Never rescaled or restated by us.",
+ "title": "Value",
+ "type": "number"
+ }
+ },
+ "required": [
+ "end",
+ "value"
+ ],
+ "title": "FactPoint",
+ "type": "object"
+ }
+}Output schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "as_of": {
+ "description": "ISO-8601 UTC timestamp with milliseconds (e.g. 2026-09-03T14:05:00.000Z) at which this snapshot was assembled. EDGAR is queried live, so it is the read time rather than a fixed data cut-off.",
+ "title": "As Of",
+ "type": "string"
+ },
+ "cik": {
+ "description": "Registrant's SEC Central Index Key, 10 digits zero-padded (e.g. 0000320193), resolved from the ticker when one was supplied. Use this form in other views.",
+ "title": "Cik",
+ "type": "string"
+ },
+ "disclaimer": {
+ "default": "Compiled from public SEC filings; not investment advice.",
+ "description": "Fixed notice that this snapshot is compiled from public SEC filings and is not investment advice.",
+ "title": "Disclaimer",
+ "type": "string"
+ },
+ "events_30d": {
+ "description": "Events derived from this registrant's filings over the last 30 days, most recent first, capped at 50. Empty when nothing was filed or our event index does not yet cover the period.",
+ "items": {
+ "$ref": "#/$defs/Event"
+ },
+ "title": "Events 30D",
+ "type": "array"
+ },
+ "facts": {
+ "additionalProperties": {
+ "items": {
+ "$ref": "#/$defs/FactPoint"
+ },
+ "type": "array"
+ },
+ "description": "XBRL financial series keyed by revenue, net_income, total_assets, cash, operating_cash_flow and shares_outstanding; each is up to the 8 most recent periods ordered oldest to newest. A key is absent when the registrant reports no matching concept, and the map is empty when XBRL company facts are unavailable.",
+ "title": "Facts",
+ "type": "object"
+ },
+ "fiscal_year_end": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Registrant's fiscal year end as a four-character MMDD string (e.g. 0930 for 30 September); null when EDGAR has none on record.",
+ "title": "Fiscal Year End"
+ },
+ "insider_90d": {
+ "additionalProperties": true,
+ "description": "Form 4 insider-trading summary for the last 90 days: `filings` (insider events counted), `buy_usd` and `sell_usd` (open-market purchase and sale value in whole US dollars) and `net_usd` (buy_usd minus sell_usd, negative on net selling).",
+ "title": "Insider 90D",
+ "type": "object"
+ },
+ "method_id": {
+ "default": "sec_events_rules_v1",
+ "description": "Identifier and version of the rule set behind the flags and scores in `events_30d`. It changes when the method changes; results carrying different method_ids are not directly comparable.",
+ "title": "Method Id",
+ "type": "string"
+ },
+ "name": {
+ "description": "Registrant name as published on EDGAR's submissions record; empty string when EDGAR carries no name for the CIK.",
+ "title": "Name",
+ "type": "string"
+ },
+ "recent_filings": {
+ "description": "Up to the 15 most recent filings of any form from EDGAR's submissions record, most recent first. Each element has `form`, `filed` (ISO-8601 filing date), `accession`, `description` (primary document description, may be empty) and `url` (index page).",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "title": "Recent Filings",
+ "type": "array"
+ },
+ "sic": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Standard Industrial Classification code for the registrant's primary industry as assigned by the SEC, typically 4 digits (e.g. 3571); null when EDGAR has none.",
+ "title": "Sic"
+ },
+ "sic_description": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Industry title EDGAR pairs with `sic` (e.g. Electronic Computers); null whenever `sic` is null.",
+ "title": "Sic Description"
+ },
+ "sources": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "description": "Public EDGAR API URLs this snapshot was compiled from, keyed `submissions` and `companyfacts`. Re-fetching them reproduces the underlying facts.",
+ "title": "Sources",
+ "type": "object"
+ },
+ "state_of_incorporation": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Jurisdiction the registrant is incorporated in as a two-character code — a US state code such as DE, or an SEC country code. This is not the business address; null when EDGAR has none.",
+ "title": "State Of Incorporation"
+ },
+ "tickers": {
+ "description": "Every exchange ticker EDGAR lists for this registrant, uppercase, in EDGAR's own order. Empty for private, unlisted or deregistered filers.",
+ "items": {
+ "type": "string"
+ },
+ "title": "Tickers",
+ "type": "array"
+ }
+}Output schema / requiredAdded value: +[
+ "cik",
+ "name",
+ "tickers",
+ "sic",
+ "sic_description",
+ "state_of_incorporation",
+ "fiscal_year_end",
+ "recent_filings",
+ "events_30d",
+ "insider_90d",
+ "facts",
+ "sources",
+ "as_of"
+]Output schema / titlePrevious value: -"answerpool_sec_companyDictOutput"New value: +"CompanyOutput"answerpool_sec_eventsanswerpool_technology_emerginganswerpool_technology_lookupanswerpool_technology_momentumanswerpool_getanswerpool_search_cataloganswerpool_credit_balanceanswerpool_funding_signalsanswerpool_list_productsanswerpool_reg_rulesanswerpool_sec_companyanswerpool_sec_eventsanswerpool_technology_emerginganswerpool_technology_lookupanswerpool_technology_momentumcredit_balancefunding_signalslist_productsreg_rulessec_companysec_eventstechnology_emergingtechnology_lookuptechnology_momentumcredit_balancefunding_signalslist_productsreg_rulessec_companysec_eventstechnology_emergingtechnology_lookuptechnology_momentumFederal government contracts and USAspending procurement exposure for SEC-listed companies.
Twelve US filing and career-site streams in one schema: SEC, FDA, NIH, contracts, Congress, hiring
Twelve US filing and career-site streams in one schema: SEC, FDA, NIH, contracts, Congress, hiring
Cited, confidence-stamped patent intelligence over US university tech-transfer out-licensing.
Add one secure layer between your agents and this server.