Cited, filing-grounded equity research via x402, per call: graded quarterly cards, WACC, 10-Q.
Free coverage check against SEC EDGAR for any U.S. ticker: confirms whether 10-Q Highlights can serve it, lists available fiscal periods (newest first), and returns the payable URLs. No charge; the paid product is the extraction itself.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Optional fiscal period like fy2026-q1; checks that this dated variant exists | |
| ticker | Yes | U.S. ticker symbol, e.g. AAPL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true. Description adds that it is free, lists fiscal periods (newest first), returns payable URLs, and confirms the paid product is the extraction itself. No contradictions.
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?
Two sentences, each earn its place. Front-loaded with purpose and key details. No 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?
No output schema, but description clearly states what the tool returns (fiscal periods, URLs). Adequately covers all needed context for a simple coverage check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds example format for period (fy2026-q1) and explains its behavior (checks that dated variant exists). This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verbs ('checks', 'confirms', 'lists', 'returns') and explicitly names the resource (SEC EDGAR, 10-Q Highlights) and ticker. It distinguishes from siblings by being a coverage check tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use: for free coverage check of any U.S. ticker. Notes that the paid product is the extraction, implying use before purchasing. However, no explicit when-not-to-use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact x402 payment terms for one payable URL or product path (price, asset, network, payTo, scheme). The live 402 response's PAYMENT-REQUIRED header remains the authoritative terms document; this tool mirrors the same constants the gates are built from.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | A payable path or URL, e.g. /10q-highlights/AAPL, /wacc-build/AAPL/fye-2025-09-27, /quarterly-quant-card/AMD/fy2026-q2, /quarterly-qual-card/AMD/fy2026-q2, /profiles/100x-floor, /5x-stock-empirical-profile |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true annotation, the description adds valuable context that this tool mirrors constants and the live PAYMENT-REQUIRED header remains authoritative. This clarifies the tool's non-authoritative nature and its behavioral scope beyond the annotation, providing useful context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence states the tool's function and output fields; the second clarifies authority. Front-loaded with essential information, making it efficient for quick comprehension.
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 simple read-only tool with one parameter and no output schema, the description adequately covers what the tool returns (fields) and its relationship to the authoritative header. No critical information is missing for the agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed examples for the product parameter. The description adds no new meaning beyond stating it applies to 'one payable URL or product path', which is already implied by the schema. Baseline 3 is appropriate when schema fully documents parameters.
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 gets exact x402 payment terms for a payable URL/product path, listing specific fields (price, asset, network, payTo, scheme). This distinguishes it from siblings like check_10q_coverage, how_to_pay_x402, and list_research by focusing on retrieving payment term constants.
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 does not provide explicit guidance on when to use this tool versus siblings. It mentions the live 402 response is authoritative but does not state when to choose this tool over how_to_pay_x402 or check_10q_coverage. No alternatives are named, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One COMPLETE quarterly card, free — the identical payload the paid route returns for that card, not a trimmed preview. Two company-quarters (AMD fy2026-q2, MRVL fy2027-q2) are published free in both the quantitative and qualitative families, in the exact schema and field names every paid card uses, so a parser written against a sample works unchanged against any card you buy. Use it as a zero-cost integration test before paying for coverage. Any other ticker returns not_a_sample.
| Name | Required | Description | Default |
|---|---|---|---|
| family | No | Which card family to return. Defaults to quantitative. | |
| ticker | Yes | AMD or MRVL — the two company-quarters published free |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond the readOnlyHint annotation: it returns the identical payload as paid cards, supports only two specific company-quarters, and responds with 'not_a_sample' for other tickers. It does not contradict the annotation and gives the agent a clear model of the tool's runtime behavior.
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 bit lengthy but every sentence contributes value: the free complete card promise, the schema compatibility detail, the integration-test use case, and the invalid-ticker behavior. The most important information is front-loaded, though the sentence about exact schema/field names could be slightly tighter.
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 read-only sample tool with two parameters and no output schema, the description is complete: it explains what is returned, what is not returned (paid vs sample, unsupported tickers), how to use it, and how the response relates to paid cards. An agent has everything needed to invoke it correctly and interpret the result.
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 already documents both parameters completely (ticker: AMD or MRVL; family: quantitative/qualitative with default). The description reinforces the ticker constraint and family enum but does not add meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a concrete resource ('complete quarterly card') and clearly differentiates itself from the paid route ('not a trimmed preview'). It even names the exact free tickers and states the tool is a zero-cost integration test, making its purpose unmistakable.
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?
Explicit usage guidance is provided: 'Use it as a zero-cost integration test before paying for coverage.' It also tells the agent what will happen with unsupported tickers ('Any other ticker returns not_a_sample') and clarifies that the sample payload is identical to paid cards, so it can validate parsers. This fully informs when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The x402 payment flow for these products, the client libraries that automate it, and where the authoritative terms live.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, but the description adds no additional behavioral context (e.g., whether results are cached, if there are rate limits). The bar is lower with annotations, but the description misses the opportunity to provide deeper behavioral insight.
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 very concise at 15 words, but it is a sentence fragment rather than a complete sentence. The key information is front-loaded ('x402 payment flow'), but the lack of structure slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description covers the main topics but leaves ambiguity with 'these products' and does not explain the structure of the information returned. The completeness is adequate but not thorough.
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?
There are no parameters, and the input schema covers 100% of the parameter space. The description does not need to elaborate on parameters, so it is adequate.
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 the tool covers the x402 payment flow, client libraries, and authoritative terms, but it is phrased as a noun phrase rather than a clear action statement. The reference to 'these products' is ambiguous, reducing clarity. However, it does differentiate from sibling tools which cover different areas.
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?
No explicit guidance on when to use this tool versus alternatives like get_product_terms or check_10q_coverage. The description does not provide context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full alpha402x catalog: every payable research product (empirical multibagger profiles, fiscal-year-end WACC builds, 10-Q highlight extractions, quarterly quantitative and qualitative cards) with prices, payable URLs, and free guide pages. All prices are USDC per call over x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds useful context about pricing being in USDC per call and the existence of free guide pages, which goes beyond the annotation. However, it does not mention response structure, pagination, or any other behavioral details. With the annotation providing the main safety info, a 3 is appropriate.
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?
Two sentences with zero waste. The main purpose is front-loaded ('The full alpha402x catalog'), and every clause adds meaningful detail (product types, prices, URLs, free pages, currency). No redundant phrases or 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?
For a parameterless, read-only listing tool, the description is largely complete: it specifies the content, the payment currency, and the inclusion of URLs and free pages. It lacks an explicit note about response format or whether the catalog is paginated, but given the tool's simplicity and the readOnlyHint annotation, those are minor gaps. The description stands on its own adequately.
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 trivially covers everything. Per the guideline, 0 parameters earns a baseline of 4. The description adds nothing about parameters because none exist; it simply states the tool requires no input. No additional meaning is needed beyond what the empty schema implies.
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 specific verb 'list' and the resource 'the full alpha402x catalog', enumerating the exact product types (empirical multibagger profiles, WACC builds, 10-Q extractions, quarterly cards) and what is included (prices, URLs, free guide pages). This fully distinguishes it from sibling tools like check_10q_coverage or get_product_terms, which serve different specific purposes.
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 for viewing the entire catalog, but it does not explicitly state when to use it versus siblings or when not to. An agent can infer 'use this to list everything' but there is no explicit exclusions or alternative guidance. Sibling names hint at differences, but the description does not reference them.
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.
get_sample_cardget_product_terms1 field changedInput schema / properties / product / descriptionPrevious value: -"A payable path or URL, e.g. /10q-highlights/AAPL, /wacc-build/AAPL/fye-2025-09-27, /profiles/100x-floor, /5x-stock-empirical-profile"New value: +"A payable path or URL, e.g. /10q-highlights/AAPL, /wacc-build/AAPL/fye-2025-09-27, /quarterly-quant-card/AMD/fy2026-q2, /quarterly-qual-card/AMD/fy2026-q2, /profiles/100x-floor, /5x-stock-empirical-profile"check_10q_coverageget_product_termshow_to_pay_x402list_researchClaiming 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!
SEC filings, XBRL earnings and Form 4 insider trades for agents. S&P 500. Pay per call via x402.
SEC filings, insider trades, 13F, IPO calendar, macro & FX MCP tools via x402.
Autonomous buy-side research: diligence, earnings, SEC filings, comp sets. Source-cited real data.
Cross-model evidence pipeline for financial filings & contracts. x402 pay-per-call.
Add one secure layer between your agents and this server.
Each tool targets a distinct stage of the pre-sales lifecycle: catalog discovery, coverage checking, sample access, payment terms, and payment instructions. Even though pricing and URLs appear in both list_research and get_product_terms, their granularity and purpose are clearly separate.
The names are all lowercase snake_case and mostly follow a verb-first pattern (check_, get_, list_). how_to_pay_x402 is the one clear deviation from the verb_noun convention, so the set is nearly but not fully consistent.
Five tools is a well-scoped size for this product/payment-information server. Each tool has a clear role, and none feel redundant or missing for the stated pre-sales scope.
The advertised workflow is fully covered: catalog discovery, 10-Q coverage checks, free sample payloads for integration testing, exact payment terms, and payment instructions. Paid extraction is intentionally an x402 URL transaction rather than an MCP tool, so within the server's stated purpose there are no obvious dead ends.