Dimensional weight, parcel fit, landed cost and freight class. 4 of 6 tools free.
Scored across 6 tools
Each tool serves a clearly distinct calculation: billable weight, free shipping break-even, freight class from density, landed cost, box selection, and rate card generation. The descriptions explicitly cross-reference which tool to use instead when there's potential overlap, eliminating ambiguity.
Tool names follow a consistent lowercase snake_case style, but the pattern is mostly noun phrases (dim_weight, freight_class, rate_card) with one deviation (parcel_fit uses a noun+verb combo). This is minor and does not hinder readability.
With 6 tools, the set is well-scoped for a shipping mathematics server. Each tool addresses a distinct functional need without redundancy, fitting comfortably in the ideal range.
The surface covers the core shipping calculations: dimensional weight, packaging selection, freight classification, landed cost, pricing thresholds, and rate tables. No obvious missing operations for the stated domain, especially given the read-only and idempotent nature of the tools.
Work out whether a parcel bills on its size or its weight. FREE.
Carriers charge the greater of actual weight and dimensional weight, so a light bulky box costs more than the scale suggests. Typical input {"length": 18, "width": 12, "height": 10, "actual_weight": 6} returns {"cubic": 2160.0, "dim_weight": 15.54, "actual_weight": 6.0, "billable_weight": 15.54, "billed_on": "dimensional", "overage": 9.54, "divisor_used": 139.0, "note": "..."}.
Use when deciding whether a smaller box is worth the packing effort, or why an invoice exceeded the scale weight. Not for choosing a box from a list of candidates — that is parcel_fit. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "custom_divisor must be greater than 0 when divisor is 'custom'"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Second side, same unit as length. Must be greater than 0. | |
| height | Yes | Third side, same unit as length. Must be greater than 0. | |
| length | Yes | Longest side of the packed parcel, in inches (or centimetres when using a metric divisor). Must be greater than 0. | |
| divisor | No | Which published divisor to apply. "ups_daily" is 139 and "ups_retail" is 166 cubic inches per pound, as UPS states them; "usps" is 166; the metric options are cubic centimetres per kilogram. Use "custom" to supply a contracted divisor. | ups_daily |
| actual_weight | Yes | Scale weight in pounds (or kilograms with a metric divisor). Must be greater than 0. | |
| custom_divisor | No | Your contracted divisor, used only when divisor is "custom". Must be greater than 0 in that case. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, and the description adds valuable context beyond that: it never raises a protocol error, returns a structured error object, and is safe to retry after correcting input. The example output also clarifies what the caller can expect.
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 information-dense and well-structured: purpose, example, usage guidance, exclusions, and error behavior are all covered in a compact block. Every sentence contributes meaningful guidance without unnecessary padding.
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 6 parameters, rich annotations, and an output schema, the description covers all essential context: what it computes, when to use it, how it behaves on errors, and its safety profile. The output schema handles return-value details, so the description does not need to enumerate every output field.
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%, so the baseline is 3; the description adds extra meaning through a typical input/output example and a specific error example involving custom_divisor. It does not repeat every parameter definition but demonstrates how the parameters interact, which is useful 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 opens with a specific verb and resource: 'Work out whether a parcel bills on its size or its weight.' It clearly distinguishes the tool from siblings by explicitly naming parcel_fit as the alternative for box selection.
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 gives explicit use cases: deciding whether a smaller box is worth packing effort, or explaining why an invoice exceeded scale weight. It also states what the tool is NOT for and points to parcel_fit as the correct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the order value at which free shipping stops costing you money. PREMIUM (license).
Break-even is where the gross margin on the order covers the shipping you absorb. Typical input {"gross_margin_pct": 45, "ship_cost": 7.5, "current_aov": 38, "target_uplift_pct": 15} returns {"break_even": 16.67, "suggested_threshold": 43.7, "above_current_aov_by": 5.7, "rationale": "..."}.
Use when setting or defending a free-shipping bar. Not for what shipping should cost when it is not free — that is rate_card. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| ship_cost | Yes | What one shipment actually costs you to send. | |
| current_aov | Yes | Your current average order value. | |
| gross_margin_pct | Yes | Gross margin on a typical order, e.g. 45 for 45%. Must be above 0 and at most 100. | |
| target_uplift_pct | No | How far above current AOV you want the threshold set, to pull baskets up. Default 0, which returns break-even. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses critical runtime behavior: it never raises a protocol error and instead returns an error object with instructions on how to fix invalid input. It also reinforces that every call is read-only and idempotent, making retry safe. This meaningfully supplements the structured metadata.
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 efficiently structured: a one-line purpose, a one-line break-even explanation, a concrete example, an explicit usage guideline, and an error/safety note. Every sentence earns its place and the most important 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?
Given the tool has four parameters, a full output schema, annotations, and related sibling tools, the description is complete: it covers purpose, use context, exclusions, error behavior, idempotency, and a sample input/output. No significant operational gap remains for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter descriptions already carry the core burden. The description adds value with a fully worked example ('Typical input {"gross_margin_pct": 45, ...} returns ...') that demonstrates how the parameters combine and what output relationships look like, which is more than the schema alone 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 opens with a specific verb and resource: 'Find the order value at which free shipping stops costing you money.' It clearly differentiates itself from sibling tools by explicitly naming rate_card as the alternative for non-free shipping cost, so the agent can distinguish this tool from its 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 'Use when setting or defending a free-shipping bar' and explicitly excludes the alternative case: 'Not for what shipping should cost when it is not free — that is rate_card.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Derive a US LTL freight class from density. FREE.
Density in pounds per cubic foot maps to a class on the published NMFC density scale. Typical input {"length": 48, "width": 40, "height": 36, "weight": 400} returns {"cubic_feet": 40.0, "density_pcf": 10.0, "density_class": "100", "caveat": "..."}.
Use for a first estimate before a carrier quote. Not as a final classification: NMFC also weighs stowability, handling and liability, so a carrier can and does reclassify. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "dimensions produce zero volume"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| units | No | "in_lb" for inches and pounds, or "cm_kg" for centimetres and kilograms. Default "in_lb". | in_lb |
| width | Yes | Second side. Must be greater than 0. | |
| height | Yes | Third side, including the pallet. Must be greater than 0. | |
| length | Yes | Longest side of the palletised freight. Must be greater than 0. | |
| weight | Yes | Gross weight including the pallet. Must be greater than 0. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds crucial behavioral details beyond these. It explicitly states that invalid input never raises a protocol error, instead returning a structured error object, and that the tool is read-only and idempotent, making retries safe. This discloses error-handling behavior not present in annotations and enriches the agent's understanding of runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet information-dense. It is front-loaded with the purpose and example, followed by usage constraints and error behavior. Every sentence serves a purpose: purpose, typical mapping, example, context for use, caveat about NMFC factors, and error handling. No unnecessary fluff; it effectively communicates the essentials in a compact 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?
Given the tool's moderate complexity and strong schema + annotations, the description covers all critical aspects: what it computes, when to use it, limitations, error handling, and idempotency. An output schema exists (though not shown) and is not required to be explained. The description is complete enough for an agent to decide when to invoke it and what to expect on both success and failure.
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%—all parameters are described in the input schema. The description's example input/output adds concrete usage context but does not introduce meaning beyond the schema's field descriptions. Hence, the baseline of 3 applies, as the description does not compensate for any gaps nor does it deepen parameter semantics beyond the example.
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
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 explicitly states when to use the tool: 'Use for a first estimate before a carrier quote.' It also clearly excludes its use as a final classification: 'Not as a final classification: NMFC also weighs stowability, handling and liability, so a carrier can and does reclassify.' This gives clear guidance on appropriate usage and when to resort to alternatives (carrier quotes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total what a unit really costs once freight, duty and fees are in. FREE.
Duty is applied to goods value, tax to goods plus duty plus freight — the common import treatment — and the order is spelled out in the response so you can check it against your own broker's method. Typical input {"unit_cost": 8.5, "quantity": 200, "freight_total": 640, "duty_pct": 6.5, "tax_pct": 0} returns {"goods": 1700.0, "duty": 110.5, "freight": 640.0, "tax": 0.0, "total_landed": 2450.5, "landed_unit_cost": 12.25, ...}.
Use before setting a price on imported stock. Not for the margin that price leaves you — that is the dropship server's margin_check. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| tax_pct | No | Import VAT or GST as a percentage of goods plus duty plus freight, e.g. 20. Default 0. | |
| duty_pct | No | Import duty as a percentage of goods value, e.g. 6.5. Default 0. | |
| quantity | No | Units in the shipment. Must be at least 1. Default 1. | |
| unit_cost | Yes | Ex-works cost of one unit in your currency. Must be greater than 0. | |
| other_fees | No | Brokerage, port and handling charges for the shipment. Default 0. | |
| freight_total | No | Total freight and insurance for the whole shipment, not per unit. Default 0. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Matches annotations (read-only, idempotent, non-destructive) and adds details about error handling (returns error object instead of raising protocol errors) and retry safety. Provides extra transparency beyond 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?
Despite being detailed, the description is well-structured: purpose, formula, example, usage instructions, and error handling. Each sentence adds value without redundancy, fitting the complexity of the tool.
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?
Covers all necessary aspects: calculation logic, input parameters, example output, usage guidance, and error behavior. The presence of an output schema and complete parameter descriptions means no critical information is missing.
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% and parameter descriptions are detailed (e.g., freight_total is specified as 'for the whole shipment, not per unit'). The description further clarifies the roles of duty and tax parameters in the calculation.
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?
Clearly states the tool computes landed cost including freight, duty, and taxes, with an example. It distinguishes from sibling tools by explicitly noting it is not for margin calculation (margin_check) and is for pricing imported stock.
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?
Explicitly instructs to use before setting a price on imported stock and warns not to use for margin calculations, directing to a sibling tool. Also explains the calculation order and provides an example, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick the smallest box an item actually fits in, allowing for padding. FREE.
Tries every rotation of the item against every box, so an item that only fits diagonally-oriented is still found. Typical input {"item_length": 10, "item_width": 6, "item_height": 4, "box_options": [[12, 9, 4], [14, 10, 6]]} returns {"fits": [{"box": [14, 10, 6], "cubic": 840.0, "slack": [2, 2, 0]}], "best": [14, 10, 6], "rejected": [...]}.
Use when choosing packaging from stock. Not for what the carrier will bill once a box is chosen — that is dim_weight. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "box_options must contain at least one [l, w, h] box"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| padding | No | Cushioning allowance added to every item side before the comparison, in the same unit. Default 1.0; use 0 for a bare fit. | |
| item_width | Yes | Item's second side, same unit. Must be greater than 0. | |
| box_options | Yes | Candidate inner box dimensions, each a list of exactly three positive numbers, e.g. [[12, 9, 4], [14, 10, 6]]. | |
| item_height | Yes | Item's third side, same unit. Must be greater than 0. | |
| item_length | Yes | Item's longest side, in inches. Must be greater than 0. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations. It mentions that the tool is 'FREE' (no cost implications), which is not in the annotations. It explains the algorithm behavior ('Tries every rotation'), the return format (including 'rejected' field), and error behavior (never raises protocol errors, returns error objects). It also confirms read-only and idempotent nature, which aligns with the annotations, adding detail about retry safety.
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 a clear opening statement, an example, usage guidance, and error handling. It is somewhat lengthy but each sentence serves a purpose. The first sentence is front-loaded and grabs attention. It could be slightly more concise, but the detail is justified for clarity, earning a 4.
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 moderately complex with 5 parameters and an output schema, but the description provides comprehensive guidance: it explains the input format, gives a concrete example with expected output, clarifies the algorithm's behavior, and covers error cases. Since the output schema exists, the description does not need to explain return values in depth, but it does highlight the 'rejected' field, which is helpful. The description is complete for the tool's complexity.
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 covers all parameters with descriptions, and the description adds examples of typical input. However, the description provides additional context for the 'padding' parameter by explaining it as 'Cushioning allowance added to every item side' and mentions the default is 1.0, but it could go further in explaining units or implications. Since schema_coverage is 100%, the baseline is 3, and the description adds some extra value, so a 4 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 purpose: 'Pick the smallest box an item actually fits in, allowing for padding.' It specifies the verb (pick), resource (box), and the key qualification (smallest, with padding). It distinguishes itself from siblings by explicitly noting it is not for carrier billing, which is 'dim_weight'. The example input/output further clarifies the function.
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 explicit guidance: 'Use when choosing packaging from stock. Not for what the carrier will bill once a box is chosen — that is dim_weight.' This clearly states when to use the tool and explicitly names an alternative tool (dim_weight) for a different scenario. It also mentions error handling and retry safety, which guides usage in failure cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a cost model into a customer-facing weight-banded price table. PREMIUM (license).
Prices each band at its upper bound so you never under-charge inside a band, then rounds up to a tidy increment. Typical input {"base_cost": 4.2, "cost_per_lb": 0.65, "bands_lb": [1, 2, 5, 10], "margin_pct": 25} returns {"bands": [{"up_to_lb": 1, "cost": 4.85, "price": 6.5}, ...], "over_top_band": "quote individually"}.
Use when publishing shipping prices customers pay. Not for the cut-off at which shipping becomes free — that is free_shipping_threshold. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "bands_lb must contain at least one upper bound"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| bands_lb | Yes | Upper weight bound of each band in ascending order, e.g. [1, 2, 5, 10]. At least one band, each greater than 0. | |
| round_to | No | Increment to round each published price up to, e.g. 0.5 or 1. Default 0.5. | |
| base_cost | Yes | Fixed cost per shipment before weight, e.g. pick, pack and label. Must be greater than 0. | |
| margin_pct | No | Margin added on top of cost, e.g. 25 for 25%. Default 0. | |
| cost_per_lb | Yes | Marginal cost per pound. Use 0 for a flat rate card. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable non-obvious behavior: pricing at the upper bound, rounding up to a tidy increment, and returning an error object instead of raising a protocol error. This goes beyond the annotation metadata and gives the agent important expectations for error handling and retry safety.
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 long but every sentence earns its place: purpose, pricing behavior, example, usage guideline, sibling contrast, error behavior, and retry safety. It is well-structured with clear breaks between these concerns and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers purpose, usage, pricing algorithm, error behavior, idempotency, and a concrete example. An output schema exists, so return-value details need not be repeated. The contrast with free_shipping_threshold addresses the most likely sibling ambiguity. This is complete for an agent selecting and invoking the 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?
The input schema already provides 100% parameter descriptions, so the baseline is 3. The description adds a concrete input/output example that clarifies how base_cost, cost_per_lb, bands_lb, and margin_pct interact, and it explains the rounding behavior. This enriches the schema without duplicating it.
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+resource statement: 'Turn a cost model into a customer-facing weight-banded price table.' It clearly distinguishes itself from the sibling free_shipping_threshold by explicitly saying it is not for that cutoff, and the example input/output makes the tool's function concrete.
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 gives explicit usage guidance: 'Use when publishing shipping prices customers pay' and directly contrasts with free_shipping_threshold as the alternative tool. This is exactly the kind of when-to-use vs. when-not-to-use guidance that helps an agent select the correct tool.
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.
dim_weightfree_shipping_thresholdfreight_classlanded_costparcel_fitrate_cardClaiming 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!
Freight calculators (weight, metres, vehicle fit) and authenticated team packing-library tools.
Calculate shipment volume (CBM/CFT), weight, and how cargo fits standard shipping containers.
Plan optimal container & truck loads: 3D layouts, utilization, centre of gravity, crush checks.
Processor fees, charge-to-net, invoice totals and proration. 3 of 6 tools free.
Add one secure layer between your agents and this server.
