Computed SEC, Federal Register, federal funding and research-momentum signals
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, so the operation is known to be safe. The description adds context about the API key scope and 'remaining' balance, but does not disclose details like units or what happens when the balance is low; this is acceptable for a simple read-only call.
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 concise sentence that front-loads the verb and resource. It contains no filler, repetition, or unnecessary detail.
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 tool with an output schema present, the description provides sufficient context: what is checked, for which API key, and that it returns remaining balance information. No critical operational details are 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?
The input schema has zero parameters, so the baseline is 4. The description does not need to add parameter-level meaning, and none is missing.
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 ('Check') and a specific resource scope ('remaining credit balance for your API key'), making the tool's function immediately clear. It naturally distinguishes itself from the sibling tools, which concern funding signals, products, SEC filings, and technology topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the purpose: call this tool when you need to know the remaining credit balance for the API key. However, there is no explicit when-to-use versus alternatives guidance, but no alternative is plausibly relevant given the unique resource.
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 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.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | ||
| product_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and destructiveHint, and the description adds useful behavior: paid products 'debit a prepaid credit key and are never charged on failure'. It also points to catalog entries for schemas, but says nothing about error responses or rate limits.
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 the core action and workflow. The category list and pricing sentence are useful but make it slightly longer than strictly necessary.
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 dispatcher of 133 products, it covers the full call path: obtaining the id, passing params, locating schemas, and handling keys. The existence of an output schema is referenced via catalog entries, so return values need not be spelled out here.
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 0% schema description coverage, the description compensates by giving a concrete example of the JSON object and explaining that each product's input/output schema lives in its catalog entry. This gives the agent enough to construct both parameters correctly.
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 specific verb and resource: 'RUN ANY of the 133 AnswerPool products by id'. It clearly positions this tool as the main execution path and distinguishes it from answerpool_search_catalog, which finds ids.
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 defines the workflow: 'Find an id with answerpool_search_catalog, then pass its inputs as a JSON object'. It also differentiates paid vs free products, telling the agent when a key is required.
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 the operation as read-only and non-destructive, covering the safety profile. The description adds the scoping detail 'all' products, indicating no filtering, but it does not mention rate limits, authentication, or data freshness.
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 sentence front-loads the action and object, then adds the key output details without redundant wording. 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?
For a parameterless, read-only list operation with an output schema present, the description fully conveys what the tool does and what its response contains. An agent has enough information to select and invoke 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?
The tool has zero parameters, so parameter-level documentation is unnecessary and schema coverage is trivially 100%. The description adds value by naming the output fields ('prices, inputs and when to use each'), which is the closest relevant semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('all AnswerPool products'), and it names the output content ('prices, inputs and when to use each'). This distinguishes it from sibling tools that focus on credit balances, SEC events, or technology topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool to use for discovering AnswerPool products and their recommended use cases, but it never explicitly states when to choose this tool over a sibling. No exclusions or alternative tool names are 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 and inputs; 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 establish readOnlyHint=true and destructiveHint=false, so the tool's safety profile is known. The description adds meaningful behavioral context beyond the annotations: it specifies the scope (130+ products across listed domains), the return shape (matching product ids with price and inputs), and the fact that the tool is free. This gives the agent useful expectations for invocation and interpretation of results.
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 a bold directive, then presents the domain list in one efficient sentence, followed by return behavior and the follow-up tool. Every sentence contributes value, though the long domain enumeration adds some length. It remains well-structured and scannable for an agent parsing the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's scope, return format, and follow-up workflow, and an output schema is present, so return-value details are not required. However, it omits guidance on the input parameters (query, limit, free_only) and does not clarify how this tool relates to answerpool_list_products. For a search tool this is a notable gap, but the core usage is adequately communicated.
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 3 parameters and 0% schema description coverage, the description was expected to compensate by explaining the meaning of query, limit, and free_only. It does not do so; no parameter is mentioned by name or described functionally. The only possible hint is the final 'Free.' which vaguely aligns with free_only but is not connected to the parameter. This leaves the agent to infer semantics from property names and defaults alone.
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 core action: 'Search 130+ computed products' across a broad set of named domains, and explains that it returns matching product ids with price and inputs. It is unambiguous about the tool's resource and purpose. However, it does not explicitly differentiate itself from the sibling answerpool_list_products, leaning on the word 'search' rather than naming the alternative.
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 opening imperative 'FIND THE RIGHT DATA PRODUCT' establishes a clear use case: this tool is for locating a product in the catalog. It also gives a workflow cue, 'pass a product id to answerpool_get,' which tells the agent the natural next step after using this tool. It does not, however, state when not to use this tool or explicitly contrast it with sibling tools like answerpool_list_products.
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. Dates show when Glama detected each change.
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_momentumClaiming 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 as io.github.acme/server also 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.json on 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.
No comments yet. Be the first to start the discussion!
Federal government contracts and USAspending procurement exposure for SEC-listed companies.
SEC, Congress, FDA, crypto, app reviews and live jobs: scored signals. 18 tools, free flagship.
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
Add one secure layer between your agents and this server.
Search, list, and get are clearly distinct, and credit_balance is unambiguous. However, answerpool_sec_company overlaps with answerpool_get since SEC company data is described as one of the many products reachable through get, which could confuse an agent about whether to use the generic get or the specialized tool.
All tools share the answerpool_ prefix, but the suffix pattern is inconsistent: list_products and search_catalog follow verb_noun, get is a bare verb without an object, and credit_balance and sec_company are noun phrases. The naming is readable but not uniformly patterned.
Five tools is a reasonable size for a data-product gateway: two discovery tools, one execution tool, an account tool, and a convenience shortcut. The count is appropriate, though sec_company is arguably redundant given answerpool_get.
The tool set covers the full user workflow: find products, list all products, execute a product, and check billing balance. Minor gaps exist, such as no way to inspect a single product's schema without listing everything and no general mechanism for product-specific convenience tools beyond sec_company, but no critical workflow is blocked.