Make money with x402. See which services are earning, find profitable gaps, and price your API right — backed by real on-chain payment data from 90K+ services and $46M+ in volume.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Average 3.8/5 across 6 of 6 tools scored. Lowest: 3.1/5.
Each tool targets a distinct purpose: deep analysis of a specific service, opportunity discovery, market overview, real-time snapshot, search, and pricing suggestions. No two tools appear to do the same thing.
Four tools follow a clear verb_noun pattern (analyze_service, find_opportunities, search_services, suggest_pricing), while market_overview and market_pulse are noun_noun. This is a minor deviation that doesn't hinder readability.
Six tools is a well-scoped count for a market analysis server. Each tool earns its place and covers a different aspect without unnecessary bloat.
The set covers searching, analyzing, market overview, real-time pulse, opportunity identification, and pricing. A minor gap might be side-by-side service comparison or historical tracking, but the core workflows are well covered.
analyze_serviceAnalyze ServiceAInspectDeep competitive analysis of any service — composite score, competitive percentile, revenue data, top competitors, and strategic recommendations. Pass a domain name, URL, or service ID. Preview is free — $5 USDC via x402 unlocks the full analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Service ID, domain name (e.g., 'heurist.ai'), or URL to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It importantly reveals the payment model ('Preview is free — $5 USDC via x402 unlocks the full analysis') and implies the tool returns a preview that requires payment for full results. It also lists the kind of data returned. While it doesn't discuss rate limits or auth beyond the payment, it does add significant behavioral context beyond a bare 'analyze a service'.
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 only two sentences, front-loading the core purpose and outputs in the first sentence, then the input format and payment in the second. Every sentence carries necessary information, with no filler or redundancy. It is both concise and well-structured.
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 tool with a single parameter, no output schema, and no annotations, the description is remarkably complete. It explains the purpose, the nature of the analysis, the specific outputs, the input format, and the critical payment behavior (preview vs. full access). The only minor omission is explicit mention of the return format (e.g., JSON), but the listed output data points sufficiently convey what the user will receive.
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%: the single parameter 'query' is fully described as 'Service ID, domain name (e.g., 'heurist.ai'), or URL to analyze'. The description repeats this same input guidance without adding new details such as examples, constraints, or ambiguity resolution. Therefore it meets the baseline for high schema coverage but adds no extra value.
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's function: 'Deep competitive analysis of any service' with a specific list of outputs (composite score, competitive percentile, revenue data, top competitors, strategic recommendations). This distinguishes it from sibling tools like market_overview or find_opportunities by focusing on single-service deep analysis with concrete deliverables.
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 provides clear context for when to use the tool: when a deep competitive analysis of a specific service is needed. It specifies input format ('Pass a domain name, URL, or service ID'). However, it does not explicitly mention when not to use it or direct users to alternatives like market_overview or market_pulse for different needs, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_opportunitiesFind OpportunitiesAInspectIdentify the most profitable gaps in the agent economy — specific niches, proven price points, competitor counts, and build ideas backed by real revenue data. The kind of insight you'd need weeks of research to find. Preview is free — $25 USDC via x402 unlocks all opportunities.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of opportunities to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It reveals a free preview and a $25 USDC payment via x402 to unlock all opportunities, which is a significant access/cost behavior. However, it doesn't detail the preview's scope or the exact output structure.
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?
Three sentences: first states purpose, second is a value-add (somewhat promotional), third covers pricing. It's structured and front-loaded with the core purpose, but the second sentence is non-essential fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description gives a good overview but leaves ambiguity about the preview vs paid behavior and the exact structure of returned opportunities. The limit parameter's effect with the paywall is unclear.
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 fully documents the single 'limit' parameter with min/max/default. The description adds no extra meaning about how limit interacts with the paid/unlocked tier, so baseline 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?
Description clearly states the specific verb 'Identify' and resource 'gaps in the agent economy', detailing outputs (niches, price points, competitor counts). This differentiates it from siblings like market_overview or search_services by focusing on opportunity discovery.
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?
Implied use case is discovering profitable gaps, but no explicit guidance on when to use this tool over siblings or when not to use it. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_overviewMarket OverviewBInspectComplete state of the agent economy — where $148M+ in payments have flowed, every category broken down by revenue, monetization gaps, emerging players, and what's next. Preview is free — $50 USDC via x402 unlocks the full report.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the payment gate (free preview, paid full report) and indicates the content areas covered. However, it does not mention whether the tool is read-only, potential side effects, auth requirements beyond payment, 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 concise at two sentences, with the first covering content and the second covering pricing. However, the first sentence is somewhat marketing-heavy ('Complete state...') and could be more direct about the tool's operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description explains the content of the report and the pricing structure, which is helpful. But it does not specify the return value's format, how to trigger payment, or how the preview differs from the full report in practice. Some context is provided, but gaps remain.
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 per the baseline rule, a score of 4 applies. The description does not need to document parameters, but it also does not add any parameter-related meaning beyond the empty 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?
The description indicates what the tool provides (market overview data, revenue breakdowns, emerging players) but lacks a specific action verb like 'get' or 'list.' The scope is clear (agent economy) but the tool's exact function (e.g., returning a report) is not explicitly stated, making it somewhat vague.
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 guidance is given on when to use this tool instead of siblings like market_pulse or analyze_service. The only usage-related information is about payment ('Preview is free — $50 USDC via x402 unlocks the full report'), which is not contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_pulseMarket PulseAInspectReal-time snapshot of the agent economy: top earners with revenue, hottest categories, total volume, and the insights you'd miss looking at raw data. Supports time periods: 1d, 7d, 14d, 30d, or all. Preview is free — $1 USDC via x402 unlocks the full picture.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Time period for revenue data: 1d, 7d, 14d, 30d, or all | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: the tool offers a free preview but requires a $1 USDC payment via x402 to unlock the full picture. This is important context. However, it does not mention other behavioral aspects such as rate limits, data freshness guarantees, or the exact difference between preview and full output, which are relevant for an 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?
The description is concise, with two sentences covering purpose, supported periods, and pricing. It is front-loaded with the core function. However, the phrase 'and the insights you'd miss looking at raw data' is somewhat promotional and adds less factual substance, preventing a perfect score.
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 the tool's simplicity (one parameter, no output schema), the description provides a reasonable picture: what it returns, the configurable time periods, and the payment model. It does not fully explain the structure of the response or the exact mechanics of the preview/full transition, but for a snapshot tool this is moderately complete. The gaps are not large enough to drop below a 4.
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% for the single parameter 'period', which has an enum and description. The description redundantly repeats the enum values ('1d, 7d, 14d, 30d, or all') without adding extra semantic detail beyond what the schema already provides. The baseline of 3 applies because the schema fully documents the parameter.
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 provides a real-time snapshot of the agent economy with specific content: top earners, revenue, hottest categories, total volume, and insights. This goes beyond a simple restatement of the name. However, it does not explicitly differentiate from the sibling tool 'market_overview', so it doesn't fully distinguish between alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for getting a quick, high-level market pulse rather than deep raw-data analysis, but it lacks explicit when-to-use guidance or comparisons with sibling tools. No exclusions or alternatives are mentioned. The usage context is inferred from the 'snapshot' and 'insights you'd miss' phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_servicesSearch ServicesAInspectSearch 100K+ services across the agent economy by category or keyword. Returns scores, metadata, and service IDs you can pass to analyze_service for a deep dive. Free — no payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return | |
| keyword | No | Search by keyword in name, description, or category | |
| category | No | Filter by category (e.g., 'crypto', 'ai-ml', 'marketing', 'finance', 'developer-tools', 'education', 'communication', 'cloud') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is free and returns scores, metadata, and service IDs, but omits details like rate limits, pagination, or error behavior. The information given is useful but not comprehensive.
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 compact and front-loaded. Two sentences convey the main purpose, return value, follow-up workflow, and a notable economic trait (free), with no wasted words.
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 core functionality, return values, and how to chain with analyze_service. It does not specify behavior when both keyword and category are omitted or how limit interacts, but given the tool's simplicity and no output schema, it is reasonably complete.
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%, so the baseline is 3. The description's mention of 'by category or keyword' mirrors the schema without adding extra syntax or format details beyond what is already provided.
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 explicitly states the tool searches 100K+ services by category or keyword, clearly defining its action and resource. It distinguishes itself from siblings by mentioning the returned service IDs that lead to analyze_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool: when you need to search for services before taking a deep dive with analyze_service. However, it does not explicitly mention alternatives or exclusions relative to other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_pricingSuggest PricingAInspectRevenue-backed pricing for what you're building. Describe your service in plain language and get a recommended price point based on what comparable services actually charge and earn. Preview is free — $10 USDC via x402 unlocks the full recommendation with comparables.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What you're building — natural language (e.g., 'wallet security scanner', 'DeFi analytics dashboard', 'token risk assessment API') or category (e.g., 'crypto', 'ai-ml') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the payment requirement for the full recommendation ($10 USDC via x402) and that a free preview is available. However, it does not mention return formats, errors, or whether any data is stored, leaving some gaps.
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 compact (three sentences) and front-loaded with the core value proposition. The first sentence is more of a tagline than a functional description, but it does not waste much space. Overall, it is efficient.
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 one-parameter tool with no output schema, the description adequately explains what the user gets: a recommended price and, with payment, comparables. It does not describe the free preview details, but enough context is provided for the agent to use it.
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% for the single 'query' parameter, so the baseline is 3. The description adds the suggestion to use natural language but does not provide additional syntax or format details beyond the schema's examples.
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's function: it suggests a price point for a service based on comparable services. The verb 'suggest' and resource 'pricing' are specific, and it is distinct from siblings like analyze_service or market_overview.
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 gives clear context for use: 'for what you're building' and 'Describe your service in plain language.' It implies the tool should be used when you need a price recommendation, but it does not explicitly contrast with sibling tools or state exclusions.
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.
No comments yet. Be the first to start the discussion!
