Amalgixofficial
F
license-
qualityB
maintenanceCross-model evidence pipeline for financial filings and contracts, providing source-grounded claims with verification via MCP and REST, with x402 pay-per-call.
alpha402x Equity Research
Server Details
Cited equity research, payable per call via x402: profiles, WACC builds, live 10-Q highlights.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A3.8/5.0
Tool DescriptionsB
Average 3.8/5 across 4 of 4 tools scored. Lowest: 2.9/5.
Server CoherenceA
Disambiguation5/5
Each tool has a clearly distinct purpose: checking coverage, retrieving payment terms, explaining the payment flow, and listing the catalog. There is no ambiguity or overlap.
Naming Consistency5/5
All tool names use snake_case and follow a consistent verb_noun pattern (e.g., check_10q_coverage, get_product_terms, list_research). The naming is predictable and uniform.
Tool Count5/5
With 4 tools, the set is tightly scoped to the server's purpose of providing research product information and payment terms. Each tool earns its place; no redundancy or excess.
Completeness4/5
The tools cover the key aspects: coverage checks, terms, payment flow, and catalog listing. However, there is no tool for the actual extraction or purchase execution, which is a minor gap for a fully operational workflow.
Available Tools
4 toolscheck_10q_coverageCheck 10-Q coverage for a tickerARead-onlyInspect
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.
ParametersJSON Schema
| 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 |
Tool Definition Quality
A4.8/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
get_product_termsGet a product's payment termsARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | A payable path or URL, e.g. /10q-highlights/AAPL, /wacc-build/AAPL/fye-2025-09-27, /profiles/100x-floor, /5x-stock-empirical-profile |
Tool Definition Quality
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it is safe. The description adds that the tool returns exact constants and notes the live header is authoritative, which provides some behavioral context (data source and reliability). However, it does not disclose additional traits like authentication requirements or rate limits, which are less critical for a read-only tool.
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?
Two sentences: first states the core purpose, second adds authoritative context. No redundant information. Could be slightly more concise by integrating the header note, but overall efficient and well-structured.
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?
For a simple read-only tool with one parameter and no output schema, the description adequately covers what the tool does and the scope. It lists the components of payment terms and notes the live header as authoritative. Without output schema, the description gives a reasonable expectation of return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single parameter 'product' has a description with examples. The description reiterates 'one payable URL or product path' but does not add new semantics beyond what the schema already provides. Baseline is 3 due to high coverage.
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 retrieves exact x402 payment terms for a payable URL or product path, listing the specific components (price, asset, network, payTo, scheme). It distinguishes from siblings by focusing on payment terms constants, unlike check_10q_coverage (coverage) or how_to_pay_x402 (payment instructions).
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 that the tool mirrors constants from the live 402 response's PAYMENT-REQUIRED header, but it does not explicitly state when to use this tool versus alternatives, such as checking payment terms before listing a product or using how_to_pay_x402 for payment instructions. No exclusions or usage context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
how_to_pay_x402How an agent pays over x402CRead-onlyInspect
The x402 payment flow for these products, the client libraries that automate it, and where the authoritative terms live.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
C2.9/5.0
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
list_researchList the research catalogARead-onlyInspect
The full alpha402x catalog: every payable research product (empirical multibagger profiles, fiscal-year-end WACC builds, 10-Q highlight extractions) with prices, payable URLs, and free guide pages. All prices are USDC per call over x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds scope (lists all payable products with prices) but no additional behavioral info like auth needs or side effects.
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?
Two sentences, front-loaded with purpose, no wasted words.
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?
Describes return value (catalog with prices, URLs, guide pages) adequately given no output schema; lacks mention of ordering or filtering but acceptable for a static list.
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?
No parameters; schema coverage is 100%. Description adds value by detailing output contents, meeting the baseline for zero-parameter tools.
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?
Clearly states 'list the research catalog' and enumerates contents (empirical multibagger profiles, WACC builds, etc.), distinguishing from siblings like check_10q_coverage which checks specific filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs siblings. Does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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 Servers
- Alicense-qualityCmaintenanceReal-time financial intelligence MCP server for crypto public companies. Provides covenant stress analysis, alpha signals, peer ranking, risk distribution, SEC XBRL fundamentals, and daily changes. Native x402 micropayments supported. First 5 calls free.1MIT
- AlicenseBqualityCmaintenancex402 capability chassis: 170+ AI-callable, pay-per-call data tools (US/global equities, crypto/DeFi, prediction markets, gov/legal, research, infra) settled in USDC on Base mainnet via the Coinbase CDP facilitator. No API keys or accounts — the x402 payment is the auth. Remote MCP at https://the-stall.intuitek.ai/mcp.1006MIT
- AlicenseAqualityAmaintenanceSEC EDGAR filing MCP for equity research agents: search 10-K/10-Q/8-K with CompanyFacts metrics, preview a free sample, and purchase full structured JSON via x402 USDC on Polygon. Public endpoint on xpay.tools.832MIT