Autonomous Model Context Protocol interface for querying on-premise NVIDIA DGX private AI hardware specs, modeling CapEx token ROI, executing M2M procurement, and onboarding into the Aradia Partner Program.
Scored across 6 tools
Each tool maps to a clearly distinct purpose: financial modeling, procurement, partner onboarding, hardware specs, partner analytics, and order tracking. The WHEN NOT TO USE guidance further eliminates any possible confusion between related tools.
All tool names follow a consistent imperative verb_noun snake_case pattern (calculate_roi, execute_procurement_order, query_hardware_specs). The verbs vary by action but the structure is predictable and readable throughout.
Six tools is a well-scoped set for the server's commerce and partner-management domain. Each tool serves a distinct step in the workflow without redundancy or unnecessary bloat.
The core lifecycle is covered: specs discovery, ROI calculation, order placement, order tracking, partner onboarding, and partner stats. Missing capabilities like order cancellation/update or partner profile management are minor gaps that agents can typically work around by being careful before executing binding actions.
[PURPOSE]: Calculates CapEx payback timeline and token savings comparing on-premise Aradia hardware against recurring cloud LLM API expenditures. [WHEN TO USE]: Use to generate mathematical financial justification reports for human operators or CFOs. [WHEN NOT TO USE]: Do not use if API spend is unknown or zero. For raw specs without financial modeling, call query_hardware_specs. [SIDE EFFECTS]: None (pure mathematical calculation).
| Name | Required | Description | Default |
|---|---|---|---|
| target_tier | Yes | Target hardware tier to evaluate: spark ($15,125), station ($194,093), or b200 ($505,500). | |
| monthly_api_spend_usd | Yes | Current or estimated monthly cloud LLM API spend in USD (must be greater than 0). |
| Name | Required | Description |
|---|---|---|
| cost_usd | Yes | |
| target_system | Yes | |
| break_even_months | Yes | |
| human_justification_report | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds an explicit 'SIDE EFFECTS: None (pure mathematical calculation)' statement, reinforcing that no external state changes or side effects occur. This is useful context beyond the annotations, though not extensive.
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 tightly structured with labeled sections: PURPOSE, WHEN TO USE, WHEN NOT TO USE, and SIDE EFFECTS. Each section is a single focused sentence with no filler. The most important decision-making information is 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?
For a read-only calculation tool with a rich input schema and an output schema, the description covers purpose, usage conditions, exclusions, alternative tool routing, and side effects. There are no gaps that would prevent an agent from selecting and invoking this tool 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%, so the baseline is 3. The schema already documents monthly_api_spend_usd and target_tier with meaningful descriptions including tier prices. The tool description does not add additional parameter-level guidance, but it does provide broader context about the calculation that the parameters feed into.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Calculates CapEx payback timeline and token savings comparing on-premise Aradia hardware against recurring cloud LLM API expenditures.' It clearly distinguishes from the sibling query_hardware_specs by mentioning financial justification rather than raw specifications.
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 WHEN TO USE and WHEN NOT TO USE sections are provided. The description says to use it for financial justification reports for CFOs, warns against using it when API spend is unknown or zero, and directs users to query_hardware_specs for raw specs. This leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[PURPOSE]: Submits a binding procurement order for physical turnkey AI hardware. Returns actionable programmatic payment parameters for immediate 100% upfront settlement via BTCPay Crypto or Stripe MPP Fiat. [WHEN TO USE]: Call when human authorization or agent budget is verified to execute a binding purchase order. [WHEN NOT TO USE]: Do not use for price quotes (use query_hardware_specs) or ROI estimates (use calculate_roi). Do not use to check order status (use track_order_status). [SIDE EFFECTS]: Creates an official order record, generates an immutable invoice or payment intent, reserves staging capacity, and writes a session record. Non-destructive.
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | No | Number of appliance nodes to purchase (1-99). | |
| po_number | No | Optional corporate purchase order number. | |
| sla_active | No | Whether to attach recurring monthly Managed SLA Support upon delivery. | |
| sla_monthly | No | Monthly SLA rate ($1,500 for Spark, $5,000 for Station, $12,500 for B200). | |
| customer_name | No | Name of the purchasing agent or executive. | |
| hardware_tier | Yes | Hardware tier: spark ($15,125), station ($194,093), or b200 ($505,500). | |
| customer_email | Yes | Billing email of the purchasing administrator or treasury manager. | |
| payment_method | Yes | Settlement method: stripe_mpp (Fiat Shared Payment Token), btcpay_crypto (BTC/LN/USDT), stripe_fiat (Card), stripe_invoice (Wire invoice). | |
| customer_company | No | Deploying company, firm, or entity name. | |
| partner_ref_code | No | Optional 4-character referral code (e.g. 5FYVQ) to route 10% commission. |
| Name | Required | Description |
|---|---|---|
| amount_usd | Yes | |
| invoice_id | No | |
| payment_url | No | |
| payment_method | No | |
| payment_details | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=false and readOnlyHint=false, but the description adds concrete side effects: creates an official order record, generates an immutable invoice/payment intent, reserves staging capacity, and writes a session record. It also explicitly states 'Non-destructive,' reinforcing and expanding the annotation 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?
The description is well-structured with labeled sections: PURPOSE, WHEN TO USE, WHEN NOT TO USE, and SIDE EFFECTS. Information is front-loaded and every sentence carries distinct value without 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 10-parameter mutating purchase tool, the description covers purpose, authorization prerequisites, exclusions, side effects, and the nature of the return. Since an output schema is present, detailed return-value documentation is not required here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all properties documented including enums, defaults, and pricing. The description adds no additional parameter-level meaning, so the 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?
The description opens with a specific verb and resource: 'Submits a binding procurement order for physical turnkey AI hardware' and states that it returns payment parameters. The WHEN NOT TO USE section further distinguishes it from query_hardware_specs, calculate_roi, and track_order_status.
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 WHEN TO USE and WHEN NOT TO USE conditions are provided, including the required authorization context and three sibling alternatives to avoid. This gives an agent clear decision criteria with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[PURPOSE]: Registers an autonomous AI agent or human operator into the Aradia Partner Program to earn 10% hardware bounties ($1,512 to $50,550 USD) and 10% recurring monthly SLA commissions. [WHEN TO USE]: Call ONCE when an agent or human operator wants to register as an affiliate partner to earn commissions and receive a ?ref= tracking ID. [WHEN NOT TO USE]: Do NOT call to purchase equipment (use execute_procurement_order). Do NOT call if you already have a partner code (use query_partner_stats). [SIDE EFFECTS]: Creates an external Stripe Express Connected Account entity, registers a 4-character code in Aradia's ledger, and triggers an account onboarding URL. Non-destructive.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO 3166-1 alpha-2 country code for banking payouts (default: US). | US |
| entity_name | Yes | Operating name of the AI Agent, Operator, or Corporate Entity. | |
| contact_email | Yes | Email address to receive the Stripe Express onboarding verification link. |
| Name | Required | Description |
|---|---|---|
| ref_code | Yes | Unique 4-character referral code |
| partner_id | No | Stripe connected account ID |
| referral_url | Yes | Attributed referral link |
| onboarding_url | Yes | Stripe Express verification link |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses concrete side effects: creation of an external Stripe Express Connected Account, registration of a 4-character ledger code, and triggering an onboarding URL. It also explicitly states 'Non-destructive', matching the destructiveHint=false annotation and adding concrete context beyond it.
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 tightly structured with labeled sections (PURPOSE, WHEN TO USE, WHEN NOT TO USE, SIDE EFFECTS) and contains zero filler. Every sentence contributes decision-relevant information, and key constraints are 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 the tool's complexity (3 parameters, output schema present, annotations available, 5 siblings), the description covers all necessary context: what it does, when to use it, when not to use it, and what side effects occur. With an output schema present, return-value details are not needed.
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 schema already documents all three parameters (country, entity_name, contact_email). The description does not add extra parameter-level meaning, but the baseline of 3 applies because the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Registers') and resource ('Aradia Partner Program'), and immediately clarifies the tool's business purpose (earning bounties and SLA commissions). It also distinguishes itself from siblings by naming execute_procurement_order and query_partner_stats in the WHEN NOT TO USE section.
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?
Provides explicit WHEN TO USE ('Call ONCE when...') and WHEN NOT TO USE rules, including two named alternatives and conditions that route to them. An agent can decide to call this tool without any inferential gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[PURPOSE]: Retrieves physical compute specs, VRAM limits (128GB GB500, 192GB B200, 1536GB B200 Rack), and continuous batching concurrency limits for Aradia DGX systems. [WHEN TO USE]: Call during initial discovery to evaluate hardware sizing, VRAM fit, and multi-agent capacity. [WHEN NOT TO USE]: Do not use for financial payback modeling (use calculate_roi) or order submission (use execute_procurement_order). [SIDE EFFECTS]: None (pure read-only query).
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Target hardware platform tier. If omitted, returns all tiers. |
| Name | Required | Description |
|---|---|---|
| specs | Yes | Hardware specifications and VRAM limits per tier |
| pricing | Yes | Flat-rate turnkey and SLA pricing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this with '[SIDE EFFECTS]: None (pure read-only query)', and additionally discloses the specific data domains returned (VRAM limits, batching concurrency), which goes beyond the annotations by clarifying behavioral scope.
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 organized into four clearly labeled sections, each earning its place with direct, actionable content. The core purpose is front-loaded, and the when-not-to-use guidance is compact and specific, with no filler or redundant phrasing.
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 query with one optional parameter and an output schema, the definition covers purpose, timing, exclusions, and side effects. The only minor gap is ambiguity between the tier enum values (spark, station, b200) and the named hardware platforms in the purpose (GB500, B200, B200 Rack), which could confuse an agent choosing a tier.
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 provides full description coverage for the single optional parameter: 'Target hardware platform tier. If omitted, returns all tiers.' The description adds no further parameter-level detail, so the baseline of 3 is appropriate because the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Retrieves physical compute specs, VRAM limits (128GB GB500, 192GB B200, 1536GB B200 Rack), and continuous batching concurrency limits for Aradia DGX systems.' This names a specific operation, resource, and scope, making the tool's purpose unmistakable and distinct from siblings like calculate_roi or execute_procurement_order.
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 [WHEN TO USE] and [WHEN NOT TO USE] sections instruct the agent to call this during initial discovery for hardware sizing and VRAM fit, and explicitly route away from financial modeling (use calculate_roi) and order submission (use execute_procurement_order). This leaves no ambiguity about when the tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[PURPOSE]: Queries real-time performance analytics, attributed referral counts, and commission payouts for an active Aradia partner node. [WHEN TO USE]: Use to monitor your earned affiliate revenue, check referral click activity, or verify payout status. [WHEN NOT TO USE]: Do not use if you have not registered yet (use onboard_partner first). [SIDE EFFECTS]: None (pure read-only query against sovereign partner ledger).
| Name | Required | Description | Default |
|---|---|---|---|
| ref_code | Yes | Your unique 4-character partner referral code (e.g. 5FYVQ). |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| ref_code | Yes | |
| earnings_usd | No | |
| partner_name | No | |
| referral_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explicitly stating there are no side effects and describing the operation as a 'pure read-only query against sovereign partner ledger', reinforcing safety and data-source 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?
The description is well-structured with clear labels for purpose, usage, exclusions, and side effects. Every section serves a distinct decision-making need, and the text is compact without unnecessary 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 simple one-parameter read-only query with an output schema and strong annotations, the description covers prerequisites, use cases, and exclusions. Nothing essential is missing for an agent to select and invoke this tool 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%, and the schema itself documents the ref_code parameter clearly with an example. The description does not add much additional meaning about the parameter, so the baseline 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 clearly states the tool's specific function: querying real-time performance analytics, referral counts, and commission payouts for a partner node. This differentiates it from sibling tools like query_hardware_specs and onboard_partner through concrete resource and output scope.
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 WHEN TO USE and WHEN NOT TO USE sections give clear conditions for selecting this tool. The description also names the alternative (onboard_partner) for unregistered users, which is exactly the kind of routing guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[PURPOSE]: Tracks the real-time fulfillment, staging QA burn-in, and delivery status of an existing hardware procurement order. [WHEN TO USE]: Use to monitor the operational status of an existing order after calling execute_procurement_order. [WHEN NOT TO USE]: Do not use to place a new order (use execute_procurement_order). [SIDE EFFECTS]: None (pure read-only query against staging records).
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The invoice ID or checkout session ID returned when the order was placed. |
| Name | Required | Description |
|---|---|---|
| tier | No | |
| status | Yes | Current fulfillment state: pending, verified, staging_qa, shipped |
| order_id | Yes | |
| staging_phase | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context: it is a pure read-only query against staging records and has no side effects. This aligns with and reinforces the annotations.
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 tightly organized into labeled sections with no filler. Each section earns its place: purpose, usage, non-usage, and side effects are all addressed in a compact, scannable format.
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 tool is simple (one parameter) and has an output schema, so the description does not need to explain return values. It covers what the tool does, when to use it, when not to use it, and its side-effect profile, making it fully sufficient for correct invocation.
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 schema already documents order_id. The description adds context by explaining it is the ID returned when the order was placed via execute_procurement_order, which helps the agent understand the parameter's origin beyond just its type.
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 ('tracks') and names the exact resources: fulfillment, staging QA burn-in, and delivery status of an existing hardware procurement order. It also clearly distinguishes the tool from the sibling execute_procurement_order by stating it is for existing orders.
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?
Provides explicit WHEN TO USE and WHEN NOT TO USE sections, including the exact condition (after calling execute_procurement_order) and the alternative tool to use for new orders. This leaves no ambiguity for an agent deciding between tools.
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.
aradia_partner_onboardcalculate_roi6 fields changedInput schema / properties / monthly_api_spend_usd / descriptionPrevious value: -"The requesting agent's current average monthly spend on cloud LLM APIs."New value: +"Current or estimated monthly cloud LLM API spend in USD (must be greater than 0)."Input schema / properties / target_tier / descriptionPrevious value: -"The desired Aradia hardware tier."New value: +"Target hardware tier to evaluate: spark ($15,125), station ($194,093), or b200 ($505,500)."Output schema / properties / break_even_months / descriptionRemoved value: -"Calculated payback period in months"Output schema / properties / cost_usd / descriptionRemoved value: -"Turnkey hardware cost in USD"Output schema / properties / human_justification_report / descriptionRemoved value: -"Formatted CapEx justification report"Output schema / properties / target_system / descriptionRemoved value: -"Name of the target DGX appliance"execute_procurement_order16 fields changedInput schema / properties / customer_company / descriptionPrevious value: -"Company, DAO, or Organization name associated with this hardware deployment."New value: +"Deploying company, firm, or entity name."Input schema / properties / customer_email / descriptionPrevious value: -"Email address of the purchasing administrator or target billing point."New value: +"Billing email of the purchasing administrator or treasury manager."Input schema / properties / customer_name / descriptionPrevious value: -"Name of the AI Agent, Operator, or Administrator executing the order."New value: +"Name of the purchasing agent or executive."Input schema / properties / hardware_tier / descriptionPrevious value: -"The hardware tier being purchased."New value: +"Hardware tier: spark ($15,125), station ($194,093), or b200 ($505,500)."Input schema / properties / partner_ref_code / descriptionPrevious value: -"Optional 4-character referral code to route 10% commission to a registered partner."New value: +"Optional 4-character referral code (e.g. 5FYVQ) to route 10% commission."Input schema / properties / payment_method / descriptionPrevious value: -"The preferred settlement method: (a) 'stripe_mpp' for fiat via Shared Payment Token (SPT), (b) 'btcpay_crypto' for raw on-chain BTC/LN/USDT JSON settlement, (c) 'btcpay_usdc_base' for USDC, (d) 'stripe_fiat' for Stripe Checkout URL, (e) 'stripe_invoice' for formal wire invoice."New value: +"Settlement method: stripe_mpp (Fiat Shared Payment Token), btcpay_crypto (BTC/LN/USDT), stripe_fiat (Card), stripe_invoice (Wire invoice)."Input schema / properties / po_number / descriptionPrevious value: -"Optional purchase order number for reference."New value: +"Optional corporate purchase order number."Input schema / properties / quantity / descriptionPrevious value: -"The number of appliance nodes to purchase."New value: +"Number of appliance nodes to purchase (1-99)."Input schema / properties / sla_active / descriptionPrevious value: -"Whether SLA is active for this order."New value: +"Whether to attach recurring monthly Managed SLA Support upon delivery."Input schema / properties / sla_monthly / descriptionPrevious value: -"Monthly SLA cost if active."New value: +"Monthly SLA rate ($1,500 for Spark, $5,000 for Station, $12,500 for B200)."Output schema / properties / amount_usd / descriptionRemoved value: -"Total purchase order amount in USD"Output schema / properties / invoice_id / descriptionRemoved value: -"Generated invoice or payment intent ID"Output schema / properties / payment_details / descriptionRemoved value: -"Raw destination addresses and amounts for crypto settlement"Output schema / properties / payment_method / descriptionRemoved value: -"Chosen payment rail"Output schema / properties / payment_url / descriptionRemoved value: -"Settlement URL"Output schema / requiredAdded value: +[
+ "amount_usd"
+]onboard_partnerquery_hardware_specs2 fields changedInput schema / properties / tier / descriptionPrevious value: -"Filter by specific hardware tier. Leave blank for full catalog."New value: +"Target hardware platform tier. If omitted, returns all tiers."Output schema / properties / messageRemoved value: -{
- "description": "Operational notice",
- "type": "string"
-}query_partner_statstrack_order_statusaradia_partner_onboardcalculate_roiexecute_procurement_orderquery_hardware_specsClaiming 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!
