UK used cars: road tax (VED), ULEZ charges, MOT dates, DVSA reliability, live dealer stock.
Average 4.3/5 across 6 of 7 tools scored.
Each tool targets a clearly distinct facet of UK car ownership: tax, clean air zones, MOT timing, running costs, reliability, price benchmarks, and live listings. Even the closely related get_uk_price_guide and search_used_cars are separated cleanly by aggregated guidance versus individual listings. There is no meaningful overlap or ambiguity between any two tools.
All tool names follow a consistent verb_noun snake_case pattern: calculate_, check_, check_, estimate_, get_, get_, search_. The verbs are specific and purposeful, with no mixed conventions, vague action words, or generic placeholders.
Seven tools is well-scoped for a UK automotive marketplace and ownership-information server. Each tool earns its place by covering a distinct user need without redundancy or unnecessary bloat.
The tool surface covers the full used-car decision journey: finding live stock, checking current prices, understanding running costs, road tax, MOT timing, clean air zone charges, and model reliability. For the stated domain, there are no obvious gaps or dead ends that would force an agent to improvise.
calculate_car_taxAInspectCalculate annual UK vehicle tax (VED / road tax) for any car. Handles all three UK systems: cars registered before March 2001 (taxed on engine size), March 2001 to March 2017 (CO2 bands, £20–£790), and April 2017 onward (flat standard rate). Also works out the Expensive Car Supplement for cars that listed over £40,000 new (£50,000 for electric cars registered from April 2025). Use this for any question about UK car tax, road tax, VED, or how much it costs to tax a specific car.
| Name | Required | Description | Default |
|---|---|---|---|
| co2 | No | CO2 emissions in g/km. Required for cars registered March 2001–March 2017; ignored for pre-2001 cars. | |
| fuel | Yes | Fuel type. Use "alternative" for hybrid/LPG, "diesel-rde2" only for diesels meeting RDE2. | |
| engine_size_cc | No | Engine size in cc. Only used for cars registered before March 2001. | |
| registration_year | Yes | Year the car was FIRST registered (not the year it was bought). This decides which tax system applies and is the single most important input. | |
| list_price_when_new | No | Original list price in GBP when the car was new. Needed only to work out the Expensive Car Supplement — based on the price when NEW, not what you pay for it used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses substantive behavioral scope: which registration periods use which rules, the CO2 band range, the flat standard rate, and the Expensive Car Supplement threshold including the electric-car exception. It could go further by stating the return format or that it returns an annual GBP amount, but for a pure calculation tool this is strong disclosure.
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 info-dense yet compact, with the core purpose in the first sentence and supporting detail organized by tax system and supplement. Every sentence contributes either a system rule, a threshold, or an explicit usage directive, so there is no filler or repetition.
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 five-parameter calculation tool with no output schema and no annotations, the description provides enough context for an agent to select and invoke it correctly. It explains the three tax regimes, the expensive-car threshold, and the relationship between registration period and required inputs. No essential selection or invocation 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%, so the baseline is 3. The description adds real cross-parameter meaning beyond the schema: engine size applies pre-2001, CO2 bands apply 2001–2017, later cars use a flat rate, and list price determines the Expensive Car Supplement. It does not walk through every parameter by name, but it enriches the schema's per-field descriptions meaningfully.
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: 'Calculate annual UK vehicle tax (VED / road tax) for any car.' It then names the three different UK tax systems it handles and explicitly says to use it for 'any question about UK car tax, road tax, VED, or how much it costs to tax a specific car.' This clearly distinguishes it from the sibling tools, none of which are tax-focused.
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 clear context for when to invoke it—'Use this for any question about UK car tax, road tax, VED'—and covers the main regime distinctions. However, it does not explicitly name an alternative sibling or state when not to use it, such as pointing estimate_running_costs users elsewhere, so it lacks a full when-not/alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_clean_air_zoneAInspectCheck whether a car is compliant with UK clean air zones (London ULEZ, Birmingham, Bristol) and what it would cost to drive into them. Returns compliance, the daily charge per zone, and estimated annual cost. Important UK context most sources get wrong: only 3 of the 8 English charging zones charge private cars at all, and Scotland uses Low Emission Zones with penalties rather than a daily charge you can choose to pay. Use for any ULEZ, CAZ, clean air zone, or emissions-charge question.
| Name | Required | Description | Default |
|---|---|---|---|
| fuel | Yes | Fuel type. | |
| days_per_year | No | Days per year the driver would enter a charging zone. Defaults to 250 (a daily commute). | |
| registration_year | Yes | Year the car was first registered. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so well: it states what is returned (compliance, daily charge, estimated annual cost) and adds important UK-specific context about which zones charge private cars and how Scotland handles low emission zones. It does not describe edge cases or calculation assumptions in detail, but the core behavior is transparent.
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 with no fluff. The primary action is front-loaded, return values are stated, and the crucial UK context is included in a compact but valuable sentence. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for selecting and invoking the tool: it names the zones, states the outputs, and provides important domain context that prevents misuse. Despite lacking an output schema, the return types are explicitly described, and the parameter schema covers the inputs.
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 schema already documents all parameters. The description adds contextual meaning by tying compliance and cost to the tool's purpose, but it does not specifically explain how registration_year, fuel, and days_per_year map to the results. Baseline 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 names a specific action (check compliance and cost) on a specific resource (UK clean air zones) and explicitly names the zones covered. It clearly distinguishes itself from the sibling cost and tax tools by focusing on emissions zones rather than general running costs or tax.
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 'Use for any ULEZ, CAZ, clean air zone, or emissions-charge question,' giving clear when-to-use guidance. It does not mention when not to use it or name explicit alternatives, but the sibling tools are unrelated enough that this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_mot_due_dateAInspectWork out when a UK car's MOT test is due, and the earliest date it can be tested without losing its renewal date. A car's first MOT falls on its third anniversary of registration, then annually. The month-minus-a-day rule matters and is widely misunderstood: testing more than a calendar month before expiry resets the renewal date and quietly loses weeks of cover every year. Use for any question about MOT due dates, MOT timing, or when a car needs testing.
| Name | Required | Description | Default |
|---|---|---|---|
| mot_expires | No | Date the current MOT expires, ISO format YYYY-MM-DD. Use this for a car that already has an MOT. | |
| first_registered | No | Date the car was first registered, ISO format YYYY-MM-DD. Use this for a car that has never had an MOT. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the first MOT rule, the annual cadence, and the critical month-minus-a-day rule, including the consequence of losing renewal date. It does not describe the exact return structure or what happens when both parameters are supplied, but the domain behavior is well 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 compact and front-loaded, with the main purpose in the first sentence and the most important caveat immediately after. Every sentence contributes information, and there is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the complex MOT timing rules thoroughly and even anticipates a common misunderstanding. It is slightly incomplete in that it does not explicitly state the output format or clarify precedence when both parameters are provided, but given the simplicity of the schema and the richness of the domain explanation, the overall context is strong.
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, but the description adds meaningful domain context: it explains why `mot_expires` is relevant under the month-minus-a-day rule and why `first_registered` drives the first MOT timing. This goes beyond the simple date-format notes already present in 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 ('work out') and resource ('a UK car's MOT test') and clearly states the two outputs: when the MOT is due and the earliest safe test date. It also distinguishes this from the sibling vehicle tools by focusing entirely on MOT timing rather than tax, pricing, or running costs.
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 any question about MOT due dates, MOT timing, or when a car needs testing.' It gives clear context and examples of applicable questions, though it does not spell out when not to use it or compare against alternatives directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_running_costsAInspectEstimate what a specific car on Autoza actually costs to own for a year — road tax, fuel, servicing, MOT and insurance, plus three-year depreciation where it can be worked out. Pass the listing URL or id returned by search_used_cars. This answers the question buyers actually have ("what will this cost me?") rather than just the sticker price. Components that cannot be worked out from the listing are omitted rather than guessed, and the response says which.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | No | Listing id, if you have it instead of the URL. | |
| listing_url | No | Full autoza.co.uk listing URL as returned by search_used_cars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden—and it does so well. It discloses that components that cannot be worked out are 'omitted rather than guessed' and that the response will say which are omitted. It also states the condition 'where it can be worked out' for depreciation, giving the agent insight into fallback 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?
Three sentences with no redundancy: the first states the core function, the second gives input guidance, and the third covers the value proposition and fallback behavior. It is front-loaded with the main purpose and every sentence earns its place.
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 no-output-schema estimation tool, the description covers the key context an agent needs: what is estimated, how to obtain inputs, and how incomplete data is handled. It does not describe the exact output structure (e.g., itemized breakdown vs. total), but the mention that the response says which components are omitted partially compensates for that gap.
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 baseline is 3, but the description adds useful semantic context by explaining that listing_id and listing_url are alternative inputs and that both come from search_used_cars. This resolves any ambiguity about which parameter to pass and reinforces the relationship between the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Estimate') and resource ('what a specific car on Autoza actually costs to own for a year'), then enumerates the cost components: road tax, fuel, servicing, MOT, insurance, and three-year depreciation. It differentiates from siblings by framing the tool as answering the buyer's total-cost question 'rather than just the sticker price', and explicitly references search_used_cars as the source of its input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit invocation guidance: 'Pass the listing URL or id returned by search_used_cars.' This clarifies both what input to use and where it comes from. It does not explicitly list when to prefer this over related tools like calculate_car_tax, but the aggregate-vs-single-component framing makes the use case clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_model_reliabilityAInspectGet known common faults, best and worst model years, and real DVSA MOT first-time pass rates for a specific used car model in the UK. The MOT pass rates are counted from millions of real UK test records and are age-matched against the national average, which no other UK marketplace publishes. Use when someone asks whether a specific model is reliable, what goes wrong with it, which year to buy or avoid, or what to check before buying one.
| Name | Required | Description | Default |
|---|---|---|---|
| model_slug | No | Model identifier, e.g. "ford-focus-common-faults-uk". Call with no argument to list every available model. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses the data source (real DVSA MOT records, millions of tests), the age-matching methodology, and what categories of results are returned. It does not mention edge cases like unknown slugs or the no-argument listing behavior, but the schema covers listing behavior and the data provenance adds meaningful 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?
Three sentences, with the first sentence front-loading the core purpose and outputs. The second sentence adds authority and uniqueness, and the third delivers clear usage triggers. The uniqueness claim is slightly promotional but still relevant for tool selection.
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 single-optional-parameter read-only lookup with no output schema, the description covers what the tool returns, the scope, the data source, and when to invoke it. It does not specify return formatting or unknown-model behavior, but these are minor given the simplicity of the tool and the complete 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?
The schema fully documents the only parameter, model_slug, including an example format and no-argument listing behavior. The description aligns with this by saying 'specific used car model' but adds no parameter-level detail beyond the schema, so the baseline of 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 names a specific verb ('Get'), a specific resource (used car model reliability in the UK), and concrete outputs: common faults, best/worst years, and DVSA MOT first-time pass rates. This clearly differentiates it from siblings focused on tax, MOT due dates, running costs, price guides, and car search.
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: when someone asks whether a model is reliable, what goes wrong, which year to buy or avoid, or what to check before buying. It does not explicitly name alternatives or exclusions, but the sibling names and the focused reliability context make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_uk_price_guideAInspectGet current UK used-car asking-price guidance from live verified-dealer listings — typical, lowest and highest asking price, optionally narrowed to a make or model. Prices are GBP and reflect what dealers are asking right now, not trade or valuation estimates. Use to answer "what do X cost used in the UK" or to sanity-check whether an advertised price is reasonable.
| Name | Required | Description | Default |
|---|---|---|---|
| make | No | Optional: narrow to a manufacturer. | |
| model | No | Optional: narrow to a model. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a good job: it discloses the data source (live verified-dealer listings), the metric types (typical, lowest, highest), the currency (GBP), and crucially what the prices are not (trade or valuation estimates). It could add more on freshness or output shape, but the core behavioral traits are transparent.
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, all earning their place: the first states the function and outputs, the second clarifies currency and semantics, and the third gives concrete use cases. It is front-loaded and has 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?
For a simple two-optional-parameter tool with no output schema, the description is complete: it tells the agent what the tool returns, the source of the data, the unit, the optional narrowing behavior, and practical invocation scenarios. Nothing an agent needs to decide whether to call it 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 description coverage is 100%, so the baseline is 3. The description adds 'optionally narrowed to a make or model,' which mirrors the schema rather than adding new semantic depth. It does not explain edge cases like providing only a model, but the schema already documents the parameters adequately.
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-resource pair ('Get current UK used-car asking-price guidance') and clearly differentiates from siblings by specifying that it returns typical, lowest, and highest asking prices from live dealer listings, not trade or valuation estimates. This makes it easy for an agent to distinguish from search_used_cars and other sibling tools.
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: answering 'what do X cost used in the UK' and sanity-checking advertised prices. It does not explicitly contrast with sibling tools or state when not to use it, but the intended context is clear enough for an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_used_carsAInspectSearch live used cars for sale from verified UK dealers on Autoza, with real current asking prices in GBP and mileage in miles. Returns a canonical autoza.co.uk URL for each car. Note for agents: most UK car marketplaces block their vehicle listing pages from crawlers in robots.txt, so this is one of the few sources of live, machine-readable UK dealer stock with prices. Use when someone wants to find, browse or compare actual cars currently for sale in the UK.
| Name | Required | Description | Default |
|---|---|---|---|
| make | No | Manufacturer, e.g. "BMW", "Ford". | |
| limit | No | Max results, 1–25. Defaults to 10. | |
| model | No | Model name, e.g. "Focus", "3 Series". | |
| location | No | UK city or region, e.g. "Manchester", "Belfast". | |
| max_year | No | ||
| min_year | No | ||
| body_type | No | e.g. "hatchback", "estate", "suv", "saloon". | |
| fuel_type | No | e.g. "petrol", "diesel", "electric", "hybrid". | |
| max_price | No | Maximum price in GBP. | |
| min_price | No | Minimum price in GBP. | |
| transmission | No | e.g. "manual", "automatic". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does substantial work: it discloses that the source is verified UK dealers, that prices are live/current, that mileage is in miles, that each result includes a canonical URL, and that this source is one of the few machine-readable options due to robots.txt blocking elsewhere. It stops short of describing result structure or pagination behavior, but for a search tool this is solid.
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-load the core purpose, then add output format and usage context. It is appropriately sized, with only minor redundancy between 'live', 'real', and 'actual cars'.
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 an 11-parameter tool with no output schema and no annotations, the description covers the key facts an agent needs: source, data quality, units, URL return value, and when to use it. The main omission is a clearer picture of the full result payload and default ordering/pagination, but these are not critical for 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 82%, so the schema already documents most parameters with examples. The description reinforces the GBP unit for prices but does not add meaning for the undocumented max_year/min_year parameters, so it stays at the baseline without compensating.
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 begins with a specific verb and resource: 'Search live used cars for sale from verified UK dealers on Autoza', with concrete output details (prices in GBP, mileage in miles). It clearly differentiates itself from sibling tools like get_uk_price_guide by emphasizing actual cars currently for sale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: 'Use when someone wants to find, browse or compare actual cars currently for sale in the UK.' It does not explicitly name when-not-to-use cases or point to alternative siblings, though the use-case sentence makes the boundary clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming 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 or an account that owns the GitHub organization, then choose Claim with GitHub.
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!
UK tolls & charges: DVLA vehicle checks (ULEZ/CAZ/MOT/tax), prices, penalties, pay-by deadlines.
Real UK MOT failure data by car model and mileage, aggregated from official DfT test results.
Mechanic-grade used-car listing verdicts: risk score, failure points, repair costs, fair price.
Search, compare & filter 102,191 European car variants — 180 specs, 19 languages, EV data.
