Florida's published auto insurance averages. Not a quote; we are not licensed here yet.
For a registered agency: its states, rail, terms, founding period, queued and delivered counts, credit balance, and whether the licence was verified. Requires the buyer key issued at confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| buyer_key | Yes | Issued to the licensed contact at confirmation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful context beyond that: the data scope (counts, credit balance, verification flag) and the authentication need (buyer key issued at confirmation). No contradiction with 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?
Two sentences with zero filler: the return-data list is front-loaded and the credential requirement is appended. Every phrase carries information, making this appropriately dense without being bloated.
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 one-parameter, read-only status tool with no output schema, the description supplies the return contract by enumerating the fields and stating the required credential. It does not cover error behavior for invalid or missing keys, but annotations mitigate that gap for a simple closed-world read.
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 buyer_key already documented as 'Issued to the licensed contact at confirmation.' The description essentially repeats that provenance without adding new format, constraints, or behavioral details, 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 the resource (a registered agency) and enumerates the exact status fields returned: states, rail, terms, founding period, queued/delivered counts, credit balance, and licence verification. The retrieving verb is implied rather than stated, and it distinguishes well from siblings like register_agency and check_eligibility by scope, though not explicitly.
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 phrase 'For a registered agency' and the requirement of the buyer key provide clear context for when to call this tool. However, it never states when not to use it or explicitly routes to alternatives such as register_agency for creation or check_eligibility for pre-registration decisions; the guidance remains implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether we can return quotes for a state before any personal details are collected. Call this first. Returns the states we are licensed in, what we can do in each, and how many licensed agents can take a request there.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Two-letter US state code, e.g. NV | |
| product | Yes | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds useful context beyond the annotations: no personal details are needed, it should be called first, and it returns licensing coverage, capabilities, and licensed agent counts. This enriches the operational understanding of the tool.
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 two sentences, front-loads the core action, and includes both sequencing guidance and a concise summary of the return value. Every sentence adds value with no redundant or filler 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?
With no output schema, the description appropriately describes the return contents: licensed states, per-state capabilities, and licensed agent counts. It also covers call ordering and the absence of personal data requirements. It is slightly open how the optional state parameter behaves when omitted, but the plural 'states' strongly implies the all-states behavior.
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 describes the state parameter as a two-letter code, and the description adds meaningful guidance by linking it to eligibility and noting the returned states. It also implies the tool can return licensed states generally, which clarifies optional state usage. The product parameter is self-explanatory through its enum/default of 'auto,' so the partial schema coverage is adequately compensated.
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: a pre-collection eligibility check for returning quotes in a state. It distinguishes itself implicitly from quote retrieval by emphasizing the 'before any personal details are collected' step and 'Call this first.' The resource and action are specific and immediately understandable.
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 says 'Call this first,' which gives clear sequencing guidance and identifies this as the initial prerequisite check. It could be stronger by naming the alternative sibling tools, such as get_quotes, to explicitly state when not to use this tool, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What happens to anything you send us: who receives it, for what purpose, how long it is kept, how your human revokes it, and the exact consent wording to present before request_agent_contact. Machine readable so you can evaluate the exchange before making it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context by specifying what information is disclosed and that the output is machine-readable for pre-exchange evaluation, which goes 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?
The description is compact and information-dense, with no filler. The front-loaded phrase 'What happens to anything you send us' immediately establishes the tool's purpose, and every clause adds relevant detail.
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 zero-parameter, read-only tool, the description is complete: it covers the returned content (recipients, purpose, retention, revocation, consent wording), explains machine readability, and ties the tool to a specific workflow step involving request_agent_contact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully defines the input. The description still helps by clarifying the semantic content of the returned terms, but no parameter-level explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies what the tool provides: data-use terms, retention/revocation details, and consent wording. It avoids tautology by explaining the resource in concrete terms, though it lacks an explicit verb like 'retrieve' or 'get'.
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 use the tool: before request_agent_contact and before making an exchange. It does not mention direct alternatives or explicit exclusions, but the intended usage moment is clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return indicative auto insurance prices from multiple carriers, where this entity is licensed to show them. Takes rating facts only — no name, phone, email, SSN or licence number is required for an indicative price. Where we are not licensed to show prices, the request is still registered and a quote_id returned so licensed agents can quote it. If facts are missing the server asks for exactly what it needs and nothing more.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional; derived from the ZIP when absent | |
| coverage | Yes | ||
| garaging_zip | Yes | Five-digit ZIP where the vehicle is kept | |
| vehicle_year | Yes | ||
| date_of_birth | Yes | ||
| annual_mileage | No | ||
| violations_3yr | No | ||
| years_licensed | No | ||
| prior_continuous | No | ||
| vehicle_make_model | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
This is an annotation contradiction. The annotations declare readOnlyHint=true, meaning the tool should not create persistent state, but the description says that where the entity is not licensed, 'the request is still registered and a quote_id returned' so licensed agents can quote it. Registering a request and returning a quote_id for later use implies a persistent side effect, directly contradicting the read-only annotation.
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 and front-loaded with the main purpose, with each sentence contributing meaningful information: what is returned, what inputs are excluded, how unlicensed requests behave, and how missing facts are handled. It could be slightly more structured, but it is well within acceptable length and density.
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?
Despite the useful licensing and PII context, the definition is not complete enough for reliable invocation: there is no output schema, parameter descriptions are sparse, and the description does not explain the shape of returned quotes or the meaning of several inputs. The readOnlyHint contradiction further undermines contextual reliability. An agent would still need significant additional information to call this tool confidently in edge cases.
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 only 20%, with most parameter names left to self-explanation. The description adds a useful general constraint—'Takes rating facts only' and no PII—but it does not clarify ambiguous parameters like prior_continuous, violations_3yr, years_licensed, or annual_mileage. With 10 parameters and only 20% schema coverage, the description does not sufficiently compensate for the missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Return indicative auto insurance prices from multiple carriers'. It is clearly distinguishable from sibling tools by focusing on indicative quotes rather than eligibility, agency status, or market data. The qualifier 'where this entity is licensed to show them' adds important scope without muddying the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when an indicative auto insurance price is needed. It also explains the unlicensed edge case and the no-PII requirement, but it never explicitly names alternatives or states when not to use this tool versus sibling tools such as check_eligibility or request_agent_contact. The usage context is clear but relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The demand dataset: every auto insurance request people and their AI assistants made here, de-identified (age band, ZIP3, vehicle, coverage, mileage band, record, prices shown, the door and the AI vendor that asked, and the outcome: consented, verified, delivered, withdrawn). Never a name, phone, email, date of birth or five-digit ZIP. Filter by state, since, until, door, vendor; limit and offset. Priced per record with a minimum per pull; pay with a prepaid buyer key, x402, MPP or AP2. Without payment the result is a 402 with the price and a preview count. A free sample and the schema are at /data.json.
| Name | Required | Description | Default |
|---|---|---|---|
| door | No | ||
| limit | No | ||
| since | No | ||
| state | No | ||
| until | No | ||
| offset | No | ||
| vendor | No | ||
| mandate | No | AP2 Payment Mandate | |
| payment | No | x402 X-PAYMENT payload | |
| buyer_key | No | A prepaid buyer key | |
| credential | No | MPP credential |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/destructive annotations, the description discloses PII safeguards ('Never a name, phone, email, date of birth or five-digit ZIP'), pricing mechanics, payment methods, the no-payment failure mode ('Without payment the result is a 402 with the price and a preview count'), and a pointer to sample/schema data. This adds substantial behavioral context and does not contradict 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 dense but well-structured: it front-loads the dataset definition, then gives privacy guarantees, filtering, pricing, payment, failure behavior, and a schema reference. Every sentence earns its place and no content is redundant with the input schema.
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 11 parameters, no required fields, and no output schema, the description covers the essential operational concerns: filters, payment options, error behavior, and a link to the schema at /data.json. It could be slightly more explicit about the success response shape and the exact accepted values for door/vendor, but it is highly usable as written.
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 only 36%, but the description compensates by mapping all parameter groups: state/since/until/door/vendor/limit/offset for filtering, and buyer_key/x402/MPP/AP2 for the payment-related fields. It does not enumerate exact allowed values for door or vendor, which leaves some ambiguity, but the dataset field list provides enough business context.
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 identifies a specific resource — 'the demand dataset' of de-identified auto insurance requests — and a clear purchase/retrieval action via the title 'Buy de-identified demand records'. It enumerates the record contents and distinct filters, making it easy to tell apart from siblings like get_quotes or pull_requests.
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 use the tool: to pull filtered de-identified demand records and pay for them. It does not explicitly name sibling alternatives or state when not to use it, but the dataset framing and payment behavior make the tool's role unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drain the queue of pool records routed to you. Requires your buyer key. Metered buyers receive an x402 payment requirement (status 402, accepts[]) until a payment is supplied. Records are projected to the scope the consumer granted — never wider.
| Name | Required | Description | Default |
|---|---|---|---|
| mandate | No | AP2 Payment Mandate | |
| payment | No | x402 X-PAYMENT payload | |
| buyer_key | Yes | ||
| credential | No | MPP credential (the base64url JSON that would follow "Authorization: Payment") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the minimal annotations: it discloses the buyer-key requirement, the x402 payment requirement for metered buyers, the status 402/accepts[] condition, and the projection scope limitation. It could mention what 'drain' does to the queue in more detail, but the disclosed behavior is substantial.
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 concise sentences, each adding distinct value: purpose, prerequisite, payment behavior, and scope constraint. There is no redundant or filler text, 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?
For a tool with no output schema and only basic annotations, the description covers the main operational context: what it does, who it is for, the payment edge case, and the security scope. It does not describe return format or empty-queue behavior, but these are secondary given the clarity of the rest.
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 documents mandate, payment, and credential, providing 75% coverage. The description reinforces the buyer_key requirement and explains the payment-related parameters in context, but it does not add significant new meaning beyond the schema. With coverage near 75%, a mid-range score 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 states a specific action ('Drain the queue of pool records routed to you') with a clear resource and audience (buyers). It is immediately distinguishable from siblings like agency_status or get_quotes, which serve different purposes.
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: use this when you have a queue of pool records routed to you, and you need your buyer key. It does not explicitly name alternatives or when-not-to-use conditions, but no sibling tool performs a similar operation, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For an AI working for a licensed insurance agency: register the agency to receive consented consumer requests in its states. Needs the agency name, the producer NPN (National Producer Number) and its state, the states it is appointed in, the licensed contact's name, email and mobile, and how leads should arrive (email, webhook, or pull by key). The licensed contact confirms by a link sent to their email; nothing is delivered before that. The first agencies in a state receive leads free for a founding period, then prepaid credits by card. Read /join for the terms.
| Name | Required | Description | Default |
|---|---|---|---|
| npn | Yes | NPN (National Producer Number). Your NPN is on your licence and at nipr.com. Digits only. | |
| rail | No | How leads arrive: email, an https webhook (HMAC-signed), or pull by key over MCP/REST | |
| states | No | Two-letter states the agency is appointed in; defaults to npn_state | |
| website | No | ||
| npn_state | Yes | Two-letter state that issued the licence | |
| agency_name | Yes | ||
| webhook_url | No | ||
| contact_name | Yes | The licensed contact, who confirms by email | |
| verify_token | No | Optional: from POST /v1/verify/check after the contact enters the code texted to them | |
| contact_email | Yes | ||
| contact_phone | Yes | US mobile |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, openWorldHint=true), the description discloses the email confirmation flow, that nothing is delivered before confirmation, the founding-period free leads, and prepaid credits. This meaningfully supplements 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 a bit long but each sentence carries useful information: purpose, required fields, confirmation mechanism, delivery gating, and billing terms. It is front-loaded with the core action.
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 registration tool with no output schema, the description covers the essential workflow, prerequisites, and post-registration behavior. It could mention response format or verification token, but what is included is 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?
With schema coverage at 64%, the description explicitly enumerates the key fields: agency name, NPN and state, appointed states, licensed contact details, and lead delivery method. This compensates for uncovered schema entries, though it omits specifics like verify_token and webhook_url.
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 and resource: 'register the agency to receive consented consumer requests in its states.' It clearly differentiates from siblings by focusing on agency onboarding rather than quote retrieval or contact requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context by targeting 'an AI working for a licensed insurance agency' and lists prerequisites like NPN and licensed contact. However, it does not explicitly compare to sibling tools like request_agent_contact or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect the consumer with licensed insurance agents who can quote firm and bind. Needs the quote_id from get_quotes, the consumer's name and phone, and the consumer's explicit consent to be contacted — granted by the human, presented by you, or confirmed by the human directly at the consent URL the elicitation returns. Under scope contact_consumer up to 4 licensed agents receive the request and contact details; sell_identity additionally permits sharing with marketing partners. Nothing leaves without the consent. Every delivery and refusal is receipted, and POST /forget revokes.
| Name | Required | Description | Default |
|---|---|---|---|
| consent | Yes | ||
| quote_id | Yes | From get_quotes | |
| best_time | No | ||
| full_name | Yes | ||
| phone_number | Yes | US mobile or landline | |
| verify_token | No | Optional. From POST /v1/verify/check after the consumer enters the code texted to them. A verified number sells at the verified price and is contacted first. | |
| email_address | No | ||
| street_address | No | Optional. Lets a licensed agent answer firm. | |
| preferred_channel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations, disclosing consent requirements, scope-dependent sharing behavior (up to 4 agents vs. marketing partners), the guarantee that nothing leaves without consent, receipting of deliveries/refusals, and the POST /forget revocation endpoint. This is rich behavioral context with no contradiction.
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 four dense sentences with no filler. It front-loads the core purpose, then efficiently explains prerequisites, consent scopes, privacy guarantees, receipting, and revocation. 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?
Given the tool's complexity — nested consent object, scopes, no output schema — the description covers prerequisites, side effects, privacy, and revocation well. However, the return value is only indirectly implied by 'receipted' and optional parameter meanings are not fully explained, leaving a small completeness 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 description coverage is low at 44%, so the description must compensate. It adds meaningful semantics for consent and quote_id, but optional parameters such as best_time, preferred_channel, street_address, and email_address are left mostly to their names or schema placeholders. The description partially compensates but not enough for a tool with 9 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?
The description states a specific verb and resource: 'Connect the consumer with licensed insurance agents who can quote firm and bind.' It also references quote_id from get_quotes, which clearly differentiates this tool from sibling tools like get_quotes or agency_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?
The description clearly implies when to use it: after obtaining a quote_id from get_quotes and only with explicit consumer consent. It does not explicitly state when not to use it or name alternatives, but the prerequisite and consent conditions provide clear usage context.
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.
agency_statuscheck_eligibilitydata_use_termsget_quotesmarket_datapull_requestsregister_agencyrequest_agent_contactClaiming 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!
California's published auto insurance averages. Not a quote; we are not licensed here yet.
Oklahoma's published auto insurance averages. Not a quote; we are not licensed here yet.
Georgia's published auto insurance averages. Not a quote; we are not licensed here yet.
New York's published auto insurance averages. Not a quote; we are not licensed here yet.
Add one secure layer between your agents and this server.
Each tool maps to a distinct step or resource: eligibility pre-check, quotes, consent/contact, agency registration, agency status, lead queue, market data, and data-use terms. Even the two quote-related tools are clearly sequenced with check_eligibility described as 'call this first'.
Five tools use a clear verb_noun pattern (check_eligibility, get_quotes, pull_requests, register_agency, request_agent_contact), but three are bare noun phrases (agency_status, data_use_terms, market_data). All names are readable and consistently snake_case, but the verb-led convention is not uniform.
Eight tools cover the main stages of an insurance marketplace: eligibility, quotes, consumer consent, agency onboarding, lead delivery, market data, and terms. The count is well-scoped and each tool earns its place.
The core consumer journey (eligibility → quotes → consented agent contact → lead delivery) and agency workflow (register → status → pull requests) are well covered, along with market data and terms. Minor gaps exist, such as no explicit update/removal for agency registration and consent revocation only mentioned as POST /forget rather than a tool.
