HomeCover HQ: the site's own MCP server — dataset; every answer cites the site.
The columns, which of them are numeric, the row count and the provenance banner of the HomeCover HQ dataset. Call this first to learn the schema.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses the exact contents of the response (columns, numeric flags, row count, provenance banner) and implies a safe read operation via 'learn the schema'. It does not discuss error behavior or side effects, but for a zero-parameter inspection tool this is sufficient.
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, no wasted words. The return value list is front-loaded, and the usage guidance is appended in a short, actionable sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with no output schema and no annotations, the description fully suffices: it enumerates what the agent will receive and instructs when to call it. Nothing needed for correct invocation 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?
The tool has zero parameters and the schema reflects that with 100% coverage, so the baseline is 4. The description correctly omits parameter details and instead focuses on the tool's output, which is all that needs explaining.
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 the specific resource (the HomeCover HQ dataset), the action (returning columns, numeric flags, row count, and provenance banner), and distinguishes it from siblings like dataset_stats and dataset_provenance by framing it as the schema-introspection entry point.
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 instruction 'Call this first to learn the schema' provides explicit navigation guidance within the sibling set. It does not name the alternative tools or state when not to use it, but the positional guidance is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The rows of the HomeCover HQ dataset whose column is any of the given values, in the order given — for "X vs Y" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| column | Yes | ||
| values | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains the filtering behavior and ordering, but it does not describe the output shape, whether rows are truly compared side-by-side, or any limitations beyond the schema constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous content, and the filtering/ordering behavior is stated before the usage note. It is concise and adequately front-loaded, though slightly awkward in phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description gives enough to understand the core purpose and basic invocation. However, with no annotations and no output schema, it does not disclose the return format, valid column sources, or any edge-case behavior, leaving some gaps.
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 description explains the relationship between the two parameters: 'column' is the dataset column being filtered, and 'values' are the values to match. Since schema coverage is 0%, this adds useful meaning, though it does not fully define parameter formats or constraints beyond what is inferable.
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 that the tool returns rows from the HomeCover HQ dataset filtered by a column matching any of the given values, preserving the given order. This differentiates it from dataset_search and dataset_row, though it lacks an explicit verb like 'returns' or 'selects'.
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 "X vs Y" questions' provides clear context on when to use this tool. It does not explicitly mention when not to use it or name alternative sibling tools, but the intended use case is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The source, the date it was computed, the licence and the citation for the HomeCover HQ dataset. Read this to attribute a figure correctly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It discloses exactly what information the tool provides (source, date, licence, citation) and implies a read-only operation via 'Read this'. It does not describe output format, but the content is simple enough that this is not a significant gap.
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 concise sentences with no filler. The first sentence enumerates the actual contents, and the second gives the practical purpose. Everything present 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 zero-parameter, no-side-effect metadata retrieval tool, the description is complete: it states what data is returned and why an agent would call it. There is no output schema, but the enumerated fields (source, date, licence, citation) effectively describe the expected return values.
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 already fully covers the input contract. Per the baseline for zero-parameter tools, the description does not need to add parameter-level detail, and its content correctly focuses on what the tool returns.
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 resource (HomeCover HQ dataset) and the exact content returned: source, computed date, licence, and citation. It is clearly distinguishable from sibling tools like dataset_row, dataset_stats, and dataset_columns, which concern data content rather than provenance.
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 'Read this to attribute a figure correctly' gives a clear use case: citation and attribution. It does not explicitly name alternatives or exclusion cases, but no sibling tool serves this provenance purpose, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The rows of the HomeCover HQ dataset where a column equals a value exactly (case-insensitive).
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| column | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals that matching is exact and case-insensitive, but it does not describe output shape, ordering, limits, or whether one row or all matching rows are returned, leaving partial 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?
A single sentence delivers the core semantics with no filler. The behavior is front-loaded and the title reinforces the purpose efficiently.
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-string-parameter lookup, the core behavior is stated, but no output schema or annotations exist. The description omits return-value details, sibling differentiation, and behavior for invalid columns or missing keys, making it minimally viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only restates the column/value relationship in prose and adds no detail about valid column names, value formatting, or accepted data types, providing little beyond the obvious property names.
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 title and description together state a clear lookup operation: return rows from the HomeCover HQ dataset where a column equals a given value. The exactness and case-insensitivity qualifiers distinguish it from a fuzzy search, though no sibling is explicitly named.
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?
Usage is implied through the phrase 'exact key' and the explicit case-insensitive exact-match behavior, which hints this is for precise key lookups rather than search. However, no explicit when-to-use or when-not-to-use guidance is given, and no alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rows of the HomeCover HQ dataset whose cells contain the query (case-insensitive), up to 50.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | text to look for in any cell |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses two meaningful behaviors: case-insensitive matching and a 50-row limit. It stops short of describing the exact fields returned, but for a simple read-only search these constraints are the key behavioral facts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It states the resource, the matching behavior, case sensitivity, and the row cap in the tightest useful form.
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 low-complexity tool with one required string and an optional cap, the description covers matching semantics, case sensitivity, and the row limit. The lack of an output schema means the exact return shape is unspecified, but the essential invocation context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: query has a description, but limit does not. The description's 'up to 50' gives limit some contextual meaning, but it never explicitly connects the cap to the limit parameter and adds little beyond the schema's maximum constraint.
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 concrete operation: return rows of the HomeCover HQ dataset whose cells contain the query, with case-insensitivity and a cap of 50. This clearly distinguishes it from siblings like dataset_row (single row) or dataset_stats (aggregates).
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 core use case—searching all cells for a text query—is implied by the title and description, but there is no explicit guidance about when to use this tool instead of dataset_row, dataset_top, or dataset_columns. No alternatives or exclusion conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
count, min, max, mean, median and sum of a numeric column of the HomeCover HQ dataset (grouping commas and currency are handled; non-numeric rows are excluded and counted).
| Name | Required | Description | Default |
|---|---|---|---|
| column | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It usefully states that grouping commas and currency symbols are handled and that non-numeric rows are excluded and counted. It could mention error/empty-column behavior, but the preprocessing context is a strong addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the six statistics, then adds two caveats. There is no filler and every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers the operations and key parsing behavior. Return format is implied by the listed statistics; the only missing detail is the exact structure of the excluded-row count and empty-column handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; the only parameter is a 'column' string. The description adds meaning by requiring a numeric column within the HomeCover HQ dataset, which is essential for correct invocation. It leaves minor details like case sensitivity implied.
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 specifies the exact operations (count, min, max, mean, median, sum), names the target (numeric column of the HomeCover HQ dataset), and the title reinforces it. This clearly distinguishes it from sibling tools like dataset_top or dataset_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 implies the use case: compute summary statistics for a numeric column. It gives clear context but does not explicitly state when to prefer this over a sibling like dataset_top or dataset_compare.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The highest (or lowest) rows of the HomeCover HQ dataset by a numeric column — "which is the most/least X".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| column | Yes | ||
| ascending | No | true for the lowest first; default highest first |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that rows are ranked by a numeric column, but it does not mention limit behavior, default ordering, output shape, or whether ties or invalid columns have special handling. These are material gaps for an agent calling this 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 short, front-loaded, and free of filler. It communicates the core purpose in one sentence and even adds a user-facing framing of the problem. It could be slightly more structured, but it is appropriately concise for a simple 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?
There is no output schema and no annotations, so the description must cover more than it does. It omits what the result looks like, how limit behaves, and any ordering/tie details, making the tool underspecified for reliable autonomous 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 only 33% schema description coverage, the description partially compensates by clarifying that column must be numeric and that highest/lowest maps to ordering. However, it does not explain the limit parameter or its default/effect beyond the schema's min/max constraints.
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 title and description clearly state the operation: rank/top rows of the HomeCover HQ dataset by a numeric column, supporting highest or lowest. This distinguishes it from sibling tools like dataset_row, dataset_search, and dataset_stats, which serve different lookup or aggregation 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 implies the main use case through the phrase 'which is the most/least X', but it does not explicitly state when to choose this tool over alternatives like dataset_search or dataset_stats. There is no when-not-to-use guidance or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read first. States plainly what submit_enquiry does on HomeCover HQ: it starts an enquiry with human providers who quote directly. Nothing is bought, ordered or paid; no quote is guaranteed; it is free. Also returns who receives the details, the consent wording, and how the person confirms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that no purchase/payment occurs, that quotes are not guaranteed, that the service is free, and that the tool returns details about recipients, consent wording, and confirmation. This gives an agent an accurate model of what to 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 compact and front-loaded with the 'Read first' instruction. It uses short, purposeful sentences and a clear list of what is returned. Slightly redundant phrasing prevents a 5, but it is well organized.
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 tool with no output schema, the description provides enough context to understand why it exists, what it does, and what information it returns. There are no missing operational details that an agent needs to call 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?
The tool has zero parameters, so the schema provides nothing to interpret. The description adds meaningful context about what the tool explains, which is a solid baseline for a parameterless tool.
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 concrete purpose: it describes what submit_enquiry does on HomeCover HQ, including scope (enquiry with human providers) and exclusions (no purchase, no guaranteed quote). This clearly distinguishes it from the sibling submit_enquiry 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 opening 'Read first' explicitly signals when to use this tool: before acting on submit_enquiry. It does not name alternatives or state when not to use it, but for a documentation-style tool with no real side effects, the guidance is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every field of the HomeCover HQ enquiry: key, label, type, whether required, help text and the allowed options where there are any. Pass answers to submit_enquiry keyed by field key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains what the tool returns (key, label, type, required flag, help text, options) and implies a read-only metadata lookup, but it does not explicitly state that there are no side effects or describe any other behavioral constraints such as authentication or data freshness.
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 exceptionally compact: two sentences, front-loaded with the resource and attribute list, followed by a single operational pointer. No filler, no redundant restatement of the title.
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 tool with no output schema, the description covers the returned field attributes and the relationship to submit_enquiry. It does not explicitly state whether the result is an array or map, but this is not essential for 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 has zero properties, so there are no parameters to document; baseline is 4. The description adds valuable downstream meaning by clarifying that the returned field keys should be used as keys when calling submit_enquiry, which helps an agent apply the output correctly.
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 the resource: 'every field of the HomeCover HQ enquiry' and enumerates the returned attributes. It distinguishes its purpose from submit_enquiry by noting that answers should be keyed by these field keys, though it does not explicitly contrast with enquiry_describe and lacks a direct verb like 'list' 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 implies the tool is a prerequisite for submit_enquiry: 'Pass answers to submit_enquiry keyed by field key'. This gives useful context for when to use it, but it does not explicitly state when to choose this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submits an enquiry to HomeCover HQ — NOT a purchase, NOT a guaranteed quote. Step 1: call with the answers (keyed by field key from enquiry_fields) and consent=true; it validates and returns a summary, the consent line and a confirmation token — show the person the summary and the consent line. Step 2: only if the person agrees, call again with the same answers, consent=true and the confirmation token; the enquiry is then submitted, and the person receives an email with a link they must click before any provider sees it. Consent means the person has read and agreed to: "By submitting you agree HomeCover HQ shares your details with licensed insurance agents who may contact you."
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | the person's answers, keyed by field key | |
| consent | Yes | true only when the person has agreed to: By submitting you agree HomeCover HQ shares your details with licensed insurance agents who may contact you. | |
| confirmation | No | the confirmation token from step 1, after the person has approved the summary |
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 thoroughly. It discloses that step 1 is only validation, step 2 is the actual submission, and that providers only see the enquiry after the person clicks an email link. It also spells out the exact consent line and legal implication, which is critical behavioral context for an agent.
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 front-loaded with the most important constraints and then walks through the two steps in order. Every sentence carries necessary operational information; none is filler or redundant with the 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?
Despite lacking an output schema, the description explains what step 1 returns (summary, consent line, confirmation token) and what step 2 triggers (submission and email link). It accounts for the two-step workflow, consent handling, and the human-provider context, so an agent has enough to invoke 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?
Schema coverage is 100%, but the description adds meaningful semantics beyond the schema: it explains that answers are keyed by enquiry_fields keys, that consent requires the person to have agreed to the exact statement, and that confirmation is the token returned by step 1. This enriches the otherwise bare parameter definitions.
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 and resource ('Submits an enquiry to HomeCover HQ') and immediately distinguishes the tool from a purchase or quote. It also clearly defines the two-step nature, so an agent understands exactly what operation this tool performs and what it does not.
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 when and how to use the tool: step 1 requires answers and consent and returns a token; step 2 only happens after the person approves, using the same answers plus the token. It also says the tool is not for purchases and references enquiry_fields for answer keys, which orients the agent toward related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
dataset_columnsdataset_comparedataset_provenancedataset_rowdataset_searchdataset_statsdataset_topenquiry_describeenquiry_fieldssubmit_enquiryClaiming 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!
Handovra: the site's own MCP server — dataset; every answer cites the site.
Topcoatly: the site's own MCP server — dataset; every answer cites the site.
Hardenvo: the site's own MCP server — dataset; every answer cites the site.
Upkeepvo: the site's own MCP server — dataset; every answer cites the site.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes: schema, provenance, exact row lookup, substring search, comparison, stats, top values, and enquiry steps are all separate. The only mild ambiguity is between dataset_row, dataset_search, and dataset_compare, but their descriptions clarify exact matching, substring matching, and ordered value comparison respectively.
The dataset_* prefix and enquiry_* prefix create a clear grouping. Within each group the pattern is mostly consistent, though some names are noun-based (dataset_columns, dataset_provenance) while others are verb-based (dataset_search, dataset_compare), and submit_enquiry reverses the prefix order.
Ten tools is a well-scoped set for this domain: seven query tools cover the dataset surface and three cover the enquiry flow. Each tool has a distinct job and none feel redundant.
The dataset side covers schema discovery, provenance, exact lookup, search, comparison, statistics, and ranking, which covers the full range of likely questions. The enquiry side handles explaining the process, listing fields, and submitting with a two-step confirmation, leaving no obvious dead ends.