A
licenseA
qualityA
maintenanceAdaptive Epistemic Triage & Recall Engine (AETRE) — Bayesian Value-of-Information (VOI) and queueing operations engine for academic peer review, grant study sections, and venture capital dealflow.
4
20
AGPL 3.0
AnswerPool (formerly CortexAssay)
Server Details
Renamed to AnswerPool; see io.github.blakeyounger/answerpool. SEC, Federal Register, funding
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
5 toolsanswerpool_credit_balanceCredit balanceARead-onlyInspect
Check the remaining credit balance for your API key.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.5/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
answerpool_getGet any AnswerPool productARead-onlyInspect
RUN ANY of the 133 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | ||
| product_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and non-destructive behavior, and the description adds meaningful behavioral context: paid products debit a prepaid credit key and are never charged on failure. It also discloses the broad product coverage, which helps the agent predict what kind of data will be returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action and routes the call after catalog lookup. The domain list and billing note are long but earned, since they tell the agent what to expect and what a paid call may cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic accessor with 133 possible products, the description covers the full call cycle: lookup, constructing the request, locating schemas, and billing behavior. An output schema exists for the response, so the lack of an explicit return-format description is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by showing the exact JSON shape (product_id plus params), explaining that product_id comes from the catalog search, and pointing to the catalog entry for each product's input and output schema. It does not enumerate every param, but that is delegated appropriately to the catalog.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('RUN ANY ... by id') and a concrete resource ('the 133 AnswerPool products'), and immediately distinguishes this accessor from answerpool_search_catalog by describing it as the main execution path after lookup. This makes the tool's purpose unmistakable relative to its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit workflow: find an id with answerpool_search_catalog, then pass the product inputs as a JSON object, with a concrete example. It does not spell out negative exclusions for other siblings, so it stops short of a full when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
answerpool_list_productsList productsARead-onlyInspect
List all AnswerPool products with prices, inputs and when to use each.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.1/5.0
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
answerpool_search_catalogSearch the AnswerPool catalogARead-onlyInspect
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 and inputs; pass a product id to answerpool_get. Free.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| free_only | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, so the description only needs to add value beyond that. It does so by revealing that the tool returns matching product ids with price and inputs, and that it is free. This gives useful behavioral context without contradicting 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently organized: a purpose statement, an enumerative scope list, the return behavior, and a workflow hint. The domain list is long but informative and earns its place. The all-caps opener is stylistically noisy but does not hurt clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return structures. It covers search scope, return contents, pricing, and the follow-up tool. It lacks explicit guidance on the free_only and limit parameters and does not contrast with answerpool_list_products, but overall it is reasonably complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description carries the full burden for explaining parameter semantics. It implicitly explains 'query' by describing the searchable domains, but it does not mention 'limit' or 'free_only' at all. The description fails to compensate for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching the AnswerPool catalog across 130+ computed products in many domains. It specifies the verb 'search', the resource 'catalog', and the return payload (product ids, price, inputs), plus the follow-up action (pass product id to answerpool_get). This distinguishes it from sibling tools like answerpool_get and answerpool_list_products, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'FIND THE RIGHT DATA PRODUCT' and explains the workflow of searching then passing a product id to answerpool_get. It does not explicitly state when not to use this tool or mention alternative siblings like answerpool_list_products, but the intended use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
answerpool_sec_companySEC company snapshotBRead-onlyInspect
One-call SEC snapshot of a US public company: recent filings, indexed events, insider activity, key XBRL facts (revenue, income, cash). $0.02/call.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | ||
| ticker | No |
Output Schema
ParametersJSON Schema
| 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. |
TDQS
B3.2/5.0
Behavior3/5
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 operational context ($0.02/call, aggregated contents), but it does not disclose data freshness, identifier precedence, or behavior when both parameters are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense, front-loaded sentence covers purpose, scope, contents, and cost with no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values and annotations cover safety, but the description is incomplete where it matters most: it never specifies how to identify the company via the two nullable parameters. An agent cannot reliably know whether cik, ticker, or both are needed to make a valid call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate: it never explains that cik and ticker are the lookup identifiers, whether at least one is required, or what happens if both are supplied. The parameter names are recognizable, but the crucial input contract is absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('SEC snapshot of a US public company') and enumerates the contents (filings, indexed events, insider activity, XBRL facts), which distinguishes it from the unrelated sibling tools. It lacks an explicit action verb like 'retrieves' or 'gets,' though 'one-call snapshot' makes the intent obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the tool is for a consolidated SEC snapshot and limits scope to US public companies, giving some eligibility context. However, it provides no explicit when-to-use guidance, no alternatives, and no statement of when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
7 tool updates
- Removed
answerpool_funding_signals - Removed
answerpool_reg_rules - Changed
answerpool_sec_company5 fields changed- added
Output 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" + } +} - removed
Output schema / additionalPropertiesRemoved value: -true - added
Output 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" + } +} - added
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" +] - changed
Output schema / titlePrevious value: -"answerpool_sec_companyDictOutput"New value: +"CompanyOutput"
- Removed
answerpool_sec_events - Removed
answerpool_technology_emerging - Removed
answerpool_technology_lookup - Removed
answerpool_technology_momentum
20 tool updates
- Added
answerpool_credit_balance - Added
answerpool_funding_signals - Added
answerpool_get - Added
answerpool_list_products - Added
answerpool_reg_rules - Added
answerpool_search_catalog - Added
answerpool_sec_company - Added
answerpool_sec_events - Added
answerpool_technology_emerging - Added
answerpool_technology_lookup - Added
answerpool_technology_momentum - Removed
credit_balance - Removed
funding_signals - Removed
list_products - Removed
reg_rules - Removed
sec_company - Removed
sec_events - Removed
technology_emerging - Removed
technology_lookup - Removed
technology_momentum
9 tool updates
- First observed
credit_balance - First observed
funding_signals - First observed
list_products - First observed
reg_rules - First observed
sec_company - First observed
sec_events - First observed
technology_emerging - First observed
technology_lookup - First observed
technology_momentum
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
SEC Form D fundraising intelligence.
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
Keyed federal student-loan answers, each logged and citation-stamped. Keyless tier: student-loan
Related MCP Servers
shareseer-mcpofficial
AlicenseNot gradedqualityBmaintenanceShareSeer provides: SEC filings data (10-K, 10-Q, 8-K forms) & related financials Insider trading transaction data per company Largest insider purchases & Sales in a day and week Integration: Remote MCP server (https://shareseer.com/mcp)9MIT- FlicenseNot gradedqualityDmaintenanceReal-time regulatory intelligence for prediction markets. SEC, CFTC, Fed, FinCEN monitoring. 22 x402-paid MCP tools from $0.001 USDC on Base L2. Oracle data for UMA and Chainlink.1-
- AlicenseAqualityAmaintenanceInvestment decision tools for AI agents: portfolio status, isolated multi-agent committee analysis, auditable verdict history, and lookahead-protected backtests. Advisory only, no auto-trading; negative research results published.2183MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A3.9/5.0
Disambiguation4/5
The discovery and account tools are clearly distinct, but answerpool_get is a generic executor that overlaps with answerpool_sec_company, since that SEC snapshot is likely also reachable through the catalog. list_products and search_catalog are similar in output but differ in 'list all' versus 'search', so the ambiguity is limited.
Naming Consistency3/5
All tools share the answerpool_ prefix, but the suffix style is mixed: list_products and search_catalog use verb_noun, while credit_balance and sec_company are noun phrases and get is a bare verb. This is readable but not a consistent naming convention.
Tool Count5/5
Five tools is well-scoped for a platform that exposes 133 products through a generic get endpoint plus discovery, account, and a convenience wrapper. Each tool has a clear role and none feel redundant enough to warrant removal.
Completeness5/5
The toolset covers the full user journey: discover products via search/list, execute any product via get, and check credit balance for paid calls. The sec_company shortcut is a bonus, and because answerpool_get can run any product, no product is left unreachable.