Discover, quote & invoke RocketCore x402-paid cyber/market intelligence products.
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.6/5 across 7 of 8 tools scored.
Each tool targets a distinct operation: checking delivery, getting status, quotes, product manifest, invocation, listing, recommendation, and search. No two tools overlap in purpose.
All tools follow a consistent 'verb_rocketcore_[noun]' pattern (e.g., list_rocketcore_products, get_rocketcore_quote). The naming is uniform and predictable.
With 8 tools covering browsing, inspection, invocation, and status, the count is well-suited for a marketplace server. Each tool serves a clear role without excess.
The tool set covers the full lifecycle for a marketplace: discovery (list, search, recommend), evaluation (inspect, quote), purchase (invoke), and post-purchase (check delivery). No obvious gaps.
check_rocketcore_deliveryAInspectExplain/verify delivery for an x402 purchase. RocketCore delivery is ATOMIC with payment (data + receipt returned in the same 200 response), so there is no async delivery to poll. Optionally echoes back a caller-supplied receipt reference for their own records. Never exposes other parties' settlement records.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_reference | No | Optional: the caller's own x402 settlement receipt id / tx hash (echoed, not looked up in private records). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses atomic delivery, no async behavior, optional receipt echoing, and a privacy constraint. This is sufficient for a simple tool, though more detail on potential errors could be added.
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 front-loaded with purpose. Every sentence adds specific value: atomicity, optional echo, and privacy constraint. 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?
For a simple tool with one optional parameter, no output schema, and no annotations, the description covers purpose, behavior, parameter semantics, and constraints. It is fairly complete, though a brief note on the response format would be helpful since no output schema exists.
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% with a single optional parameter. The description adds value by stating the parameter is 'echoed, not looked up in private records', which clarifies the parameter's semantics beyond what the schema description provides.
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 'Explain/verify delivery for an x402 purchase', providing a specific verb and resource. It distinguishes itself from sibling tools by clarifying atomic delivery with no async polling, and mentions optional receipt echoing. No confusion with siblings.
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 says 'there is no async delivery to poll', which guides the agent away from polling patterns. It also explains when the optional parameter is used. However, it does not explicitly state when not to use the tool or list alternatives beyond the atomicity note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rocketcore_marketplace_statusAInspectReturn marketplace summary: product counts, live count, categories, supported payment protocols/networks/currencies, and honest per-market publication status. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only lists return fields and mentions 'Free' (indicating no cost). It does not disclose read-only nature, potential side effects, or rate limits, leaving behavioral traits insufficiently covered.
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 sentence with a clear list of return items, but could be better structured (e.g., bullet points) for readability. 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?
For a simple tool with zero parameters and no output schema, the description adequately covers the return content. Lacks context on data freshness or caching, but generally 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?
No parameters exist (0 params, 100% schema coverage), so the description correctly adds no parameter info. Baseline score of 4 applies as no additional meaning is needed.
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 returns a marketplace summary with specific elements (product counts, live count, categories, payment protocols, etc.), distinguishing it from sibling tools that handle delivery, quotes, or product details.
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 usage for quick overview but lacks explicit guidance on when to use this tool vs alternatives like list_rocketcore_products or inspect_rocketcore_product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rocketcore_quoteBInspectReturn the exact price and x402 payment terms (amount, atomic_amount, currency, network, asset, pay_to, endpoint) for a product. Free; quoting does not pay.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It states 'Free; quoting does not pay' which hints at no cost, but does not disclose whether the operation is read-only, idempotent, or requires any authorization. No mention of potential side effects or limitations.
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, concise sentence that conveys the tool's purpose without unnecessary words. It efficiently packs the key deliverables and a notable behavioral trait (free).
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 is minimally adequate. It covers what is returned (price and payment terms) but lacks details on error conditions, response format, or required permissions.
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 0% (no description in input schema). The description mentions 'for a product' but does not explain what product_id expects (format, example, how to obtain it). Only one parameter, but no added 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?
The description uses a specific verb 'Return' and a clear resource description ('exact price and x402 payment terms') with detailed fields. It clearly distinguishes from sibling tools like list_rocketcore_products or inspect_rocketcore_product.
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. There are many sibling tools, but no comparison or use case differentiation is provided. The description does not clarify when a quote is needed versus inspecting a product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inspect_rocketcore_productAInspectReturn the full public manifest for one product: schemas, provenance, freshness, limitations, pricing, payment terms. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It states the tool is read-only (returns manifest), includes 'Free.' as a behavioral note, but does not clarify authentication requirements, rate limits, or potential errors. It is adequate but not thorough.
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?
Single sentence, front-loaded with return behavior and list of contents. No extraneous words. Perfectly concise for the complexity.
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 inspection tool with one parameter and no output schema, the description covers the main purpose and return structure. It lacks details on error handling or response format, but given the tool's simplicity, it is nearly 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 coverage is 0%, so description must compensate for parameter meaning. It implies product_id via 'one product' but provides no additional context (e.g., format, examples, ownership). This is minimal 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?
The description clearly specifies the verb 'Return' and the resource 'full public manifest for one product', and lists the included components. This distinguishes it from siblings like list_rocketcore_products (list only) and get_rocketcore_quote (quote-specific).
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. The description does not state conditions for use, excluded scenarios, or suggest alternative tools. Given the many siblings, this omission reduces usability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoke_rocketcore_productAInspectReturn everything needed for the AGENT to invoke a paid product over x402. This server NEVER pays: it returns the endpoint + x402 payment-required terms; the agent pays with its own wallet and receives data + a settlement receipt in the same 200 response.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Optional query params for the product call (validated against the product input_schema by the endpoint). | |
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that the server never pays and the agent pays with its own wallet, and that the response includes data + settlement receipt. However, it does not mention side effects, idempotency, or error behavior, leaving gaps in behavioral transparency.
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 effectively convey the tool's purpose and the payment model. No filler words; every sentence adds value. The purpose is front-loaded in the first sentence.
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?
Without an output schema, the description partially describes the response (endpoint + terms, then data+receipt). However, it does not specify the structure, error cases, or behavior for invalid product_id. The parameter documentation gap for product_id further reduces completeness.
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 50%: product_id lacks a schema description, and params is described. The tool description does not add meaning for product_id (only mentions 'product' generically) and does not elaborate on params beyond the schema. Thus, one parameter remains semantically underdocumented.
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 returns 'everything needed for the AGENT to invoke a paid product over x402', specifying the endpoint and payment terms. It distinguishes itself from siblings (e.g., get_rocketcore_quote returns a quote, not invocation data) by focusing on the purchase invocation step.
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 use when the agent wants to invoke a paid product, but does not explicitly state when to use this vs alternatives like get_rocketcore_quote or check_rocketcore_delivery. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_rocketcore_productsBInspectList all RocketCore Intel Marketplace products with status, price, and endpoint. Free, read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by lifecycle status. | |
| category | No | Filter by category, e.g. 'cyber' or 'market'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacking annotations, the description must fully disclose behavior. It mentions 'read-only' and 'Free', but omits pagination details, rate limits, and whether 'all' products implies unbounded output. No authentication context.
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?
Extremely concise: a single sentence conveying purpose, scope, and key attributes. No fluff, front-loaded with the most critical information.
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 multiple siblings and two optional parameters, the description lacks differentiation. It doesn't clarify when to list all vs search, nor does it explain output structure or pagination behavior in the absence of an output schema.
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%, with each parameter having a clear description. The tool description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
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 verb 'List', the resource 'RocketCore Intel Marketplace products', and the returned details (status, price, endpoint). It also notes 'Free, read-only', clearly distinguishing it from mutation tools like invoke_rocketcore_product or search variants.
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 on when to use this tool versus siblings like search_rocketcore_products, inspect_rocketcore_product, or get_rocketcore_marketplace_status. The description only says 'List all', which may conflict with typical filtered usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_rocketcore_productBInspectRecommend the best-matching LIVE products for a described task, with an explanation of why each matched. Deterministic, no LLM. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| limit | No | ||
| category | No | ||
| max_price | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds that the tool is deterministic and free, which is useful behavioral info. However, no annotations exist, and the description doesn't disclose side effects or whether it modifies state. Some value but incomplete.
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?
Single sentence with no redundancy. Every word adds value: verb, resource, purpose, behavioral traits. Efficient and front-loaded.
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 4 parameters and no output schema, the description is somewhat complete for a recommendation tool, but lacks details on return format beyond 'explanation', error handling, and edge cases. Mid-range adequacy.
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 0%, and the description only mentions 'task' implicitly. No details on limit, category, max_price, their formats, or how they affect recommendations. The description fails to compensate for the lack of schema documentation.
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 it recommends the best-matching LIVE products for a described task with explanations. The verb (recommend) and resource (LIVE products) are specific, and it distinguishes from sibling tools like list/search/inspect.
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 vs alternatives such as search_rocketcore_products or list_rocketcore_products. The description mentions 'no LLM' but that is behavioral, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_rocketcore_productsAInspectTask-focused search over RocketCore products (deterministic weighted keyword + natural-language match, no LLM). Free.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Natural-language task or keywords. | |
| status | No | ||
| category | No | ||
| max_price | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides moderate transparency by revealing the search algorithm ('deterministic weighted keyword + natural-language match, no LLM') and stating 'Free'. However, it does not disclose side effects, rate limits, auth requirements, or result behavior (e.g., sorting, pagination).
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, focused sentence that conveys the core purpose and unique characteristics upfront with no extraneous information.
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 5 parameters, no output schema, and no annotations, the description is too sparse. It does not explain how to use filters (status, category, max_price), what the output contains, or when to choose this tool over siblings like 'inspect_rocketcore_product' or 'list_rocketcore_products'.
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 only 20% (only 'query' has a description). The tool description does not mention any parameters or their usage. Agents must rely on the schema, which lacks descriptions for most parameters (limit, status, category, max_price). The description adds no value to parameter understanding.
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 'Task-focused search over RocketCore products', clearly identifying the verb and resource. It further distinguishes from siblings like 'list_rocketcore_products' by noting the search algorithm (deterministic weighted keyword + natural-language match) and that it's free.
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 use for task-based searches, and the sibling tools provide context (e.g., list vs. search). However, it lacks explicit guidance on when not to use it or how it compares to alternatives like 'recommend_rocketcore_product'. The context is clear but not prescriptive.
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!