Onsite GEO visibility tests, score trends, sitemap discovery, and domain monitoring for AI agents.
Scored across 17 tools
Almost every tool has a distinct, clear purpose: running tests, retrieving snapshots/trends, managing visibility, scheduling, knowledge lookups, and prompt workflows. The main overlap is gvt_share_test being a wrapper around gvt_manage_test, and the trio of gvt_get_latest/gvt_get_oldest/gvt_get_score_trend being similar but with different use cases. Descriptions are detailed enough to resolve ambiguity.
All tools share the 'gvt_' prefix and generally follow a verb_noun pattern (get_, list_, delete_, manage_, run_). Minor inconsistencies include 'batch_run_tests' vs 'run_visibility_test' and the slightly vague 'manage_test'.
17 tools is above the typical 3-15 sweet spot, but the domain is broad enough (running tests, scheduling, sharing, knowledge base, prompts) to justify it. The tools are organized logically and do not feel redundant overall.
The set covers the full GEO testing lifecycle: single and batch test execution, result retrieval, baseline comparison, scheduling, sharing/deletion, knowledge lookup, fix guidance, and prompt listing. A notable minor gap is the lack of a batch-result aggregation tool, but individual result retrieval covers the need.
Queue up to 500 URLs for batch GEO visibility testing. Returns a batch ID for tracking progress. Optionally add URLs to recurring schedules (daily, weekly, monthly) during the same call. Results are retrieved individually via gvt_get_test_results once the batch completes. A webhook URL can be provided to receive a completion notification.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Array of URL objects to test (max 500) | |
| webhookUrl | No | Optional HTTPS URL to receive a batch completion webhook |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses queued/asynchronous behavior, batch ID for tracking, and the necessity for a follow-up result call. It also mentions optional scheduling and webhook completion, going beyond the annotations and telling the agent what to expect after invocation.
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 primary sentence front-loads the tool's purpose. Every following sentence adds a distinct workflow fact: batch ID, scheduling, result retrieval, and webhook notification. There is no redundant or padding 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?
Given the tool has no output schema, the description appropriately explains the key return value and follow-up process. It covers URL limits, optional scheduling, and the completion webhook. It could describe more about failure behavior or response shape, but the essential 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 description coverage is 100%, so the description doesn't need to add much. It restates max URL count, frequency options, and webhook capability already in the schema. The return of a batch ID is helpful but not a parameter semantic.
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: queue up to 500 URLs for batch GEO visibility testing. It also explains the output as a batch ID and distinguishes itself from singular testing and scheduling siblings through the batch scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage flow: queue URLs, optionally schedule recurring runs, retrieve results later, and optionally use a webhook for completion. It does not explicitly contrast with gvt_run_visibility_test or gvt_schedule_test, but the batch and multiple-URL context implies when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a test session and all its associated results. This action cannot be undone. Use gvt_manage_test instead if you only want to hide a test from public view.
| Name | Required | Description | Default |
|---|---|---|---|
| tid | Yes | The 8-character test ID of the test to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag the tool as destructive (destructiveHint=true) and non-read-only (readOnlyHint=false), so the baseline burden is lower. The description adds valuable context beyond annotations: the deletion is permanent, cannot be undone, and includes 'all its associated results,' which clarifies the scope of the action. This is useful extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero filler. The primary action is front-loaded ('Permanently delete'), followed by a caution and an alternative. Every sentence contributes essential information; nothing is redundant.
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 destructive operation with a single parameter and no output schema, the description covers the core action, the consequence (permanence, irreversibility), the scope (associated results), and the alternative for a less severe action. Given the annotations and schema already carrying the safety profile, the description is fully sufficient for an agent 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 description coverage is 100% (only one parameter, tid, well-described as 'The 8-character test ID of the test to delete'). The description does not add any new information about the parameter beyond the schema. Per the rubric, with high coverage the baseline is 3, and the description provides no additional semantic nuance.
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 ('delete'), a clear resource ('test session and all its associated results'), and explicitly notes the permanence. It also differentiates itself from the sibling gvt_manage_test by clarifying the distinction between deletion and hiding, which makes the purpose unambiguous.
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 tells the agent when to use this tool versus the alternative: 'Use gvt_manage_test instead if you only want to hide a test from public view.' This provides a direct when-not condition and names the alternative tool, leaving no ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the canonical fix record for one GVT issue type: severity range, impact, scoring weight, plain-language description, and the recommended remediation. Issue IDs come from the fixId field on issues in gvt_get_test_results output. The same content is served as the gvt://knowledge/fixes/{issue_id} resource template for resource-capable clients.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | Stable issue identifier, e.g. og_title_missing or color-contrast. Matches the fixId field in gvt_get_test_results output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the operation's non-mutating behavior is well covered. The description adds useful context about canonical content and ID sourcing, but does not describe return shape, error behavior, or what happens for unknown issue_ids.
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, each earning its place: the first defines the tool's purpose and output contents, the second gives the source of the parameter, and the third notes the resource-template alternative. 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 simple read-only single-parameter tool with rich annotations and no output schema, the description provides enough context to call it correctly: what it returns, how to obtain the issue_id, and an alternative access path. Nothing essential 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% for the single parameter, including examples and an explicit match to the fixId field. The description essentially reinforces this same guidance rather than adding new semantic meaning beyond the schema, so the high-coverage 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 uses a specific verb and resource: 'Read the canonical fix record for one GVT issue type' and enumerates the exact contents returned. It clearly distinguishes this from siblings by scoping it to a single fixId, while noting where those IDs come from.
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 tells the agent where to get the required issue_id: from the fixId field on issues in gvt_get_test_results output. It also notes that resource-capable clients can access the same content via a gvt:// resource template, providing an alternative without explicitly naming a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read GVT reference knowledge: how scoring works, score bands and category weights, what each analysis category checks, or GEO glossary definitions. Use it to interpret test results and scores correctly instead of guessing. The same content is served as MCP resources at gvt://knowledge/app/* for resource-capable clients.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Which knowledge topic to read: methodology (how GVT analyzes pages), scoring (score bands and category weights), categories (what each of the six categories checks), glossary (GEO term definitions), or all (complete knowledge base). | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds the observation that the same content is also served as MCP resources, but that is an access detail rather than a behavior; there is no additional behavioral disclosure needed for a read-only knowledge fetch.
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 the core purpose front-loaded and a usage directive immediately following. The resource reference is extra but useful. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter read tool with no output schema, this description is complete. It tells the agent what content is available, when to use it, and even where the same data lives in MCP resources. No critical detail 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?
Schema coverage is 100%: the topic parameter has a clear description with all enum values explained. The tool description restates the topics (scoring, categories, glossary) but does not add meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read GVT reference knowledge', then lists the exact content areas (scoring, score bands and category weights, analysis categories, GEO glossary). This clearly distinguishes it from sibling tools like gvt_get_test_results or gvt_get_score_trend, which retrieve test data rather than reference knowledge.
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 to use it 'to interpret test results and scores correctly instead of guessing', giving a clear context. It does not name alternative tools, but no sibling is a near-duplicate; the MCP resource note is a bonus alternative, not a competing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most recent non-expired test snapshot for a single URL. Use with gvt_get_oldest to compare baseline vs current, or use gvt_get_score_trend for a pre-computed comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to look up (must match the URL used when the test was run). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the description doesn't need to restate that this is a safe read. It does add behavioral context about filtering by "non-expired" and "most recent" snapshots, which are useful beyond the schema, but it doesn't describe what happens if no snapshot exists or whether the response is singular/null.
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 convey a complete, front-loaded purpose. The first sentence explains the operation, and the second sentence adds relevant usage guidance without unnecessary filler or redundancy.
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 retrieval tool with no output schema, the description is adequate: it states the action, the freshness constraint, and relationships to two sibling tools. It does not cover edge cases like missing/expired snapshots, but those are not essential for a correct call and the annotations cover safety. A small gap is the lack of any indication of the result shape, but no output schema exists to fill that.
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%: the only parameter 'url' is described as "The URL to look up (must match the URL used when the test was run)." The description adds only "single URL" and the notion of freshness, which are largely already implied. It does not need to compensate for schema gaps, so the 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 states a specific verb and resource: "Get the most recent non-expired test snapshot for a single URL." It also distinguishes itself from siblings by explicitly mentioning gvt_get_oldest and gvt_get_score_trend, making its role clear without needing to inspect other schemas.
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?
Gives explicit instructions on how to use this tool: combine with gvt_get_oldest to compare baseline vs current, or use gvt_get_score_trend for a pre-computed comparison. This directly guides the agent through its main decision points and names the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the oldest baseline test snapshot for a single URL, including expired tests. Use with gvt_get_latest to compare baseline vs current, or use gvt_get_score_trend for a pre-computed comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to look up (must match the URL used when the test was run). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond that: it includes expired tests and restricts lookup to a single URL. No contradictions 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 tightly packed sentences: the first states the core purpose and key scope, the second gives usage direction with alternatives. No filler or redundant restatement.
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 read-only getter with one documented parameter and safety annotations, this description is complete. It tells the agent what the tool does, its scope, and how to combine it with related tools. Nothing essential 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%, and the single url parameter is already described with a usage constraint ('must match the URL used when the test was run'). The description adds no significant parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Get the oldest baseline test snapshot for a single URL'. The qualifiers 'single URL' and 'including expired tests' distinguish it from list/trend tools, and the description explicitly names related siblings it is meant to complement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: use with gvt_get_latest to compare baseline vs current, or use gvt_get_score_trend when a pre-computed comparison is wanted. This clearly tells an agent when this tool is the right choice and points to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the oldest baseline test snapshots for a batch of URLs (up to 100) in a single call. Ideal for monthly/periodic batch comparisons: fetch baselines in bulk here, then call gvt_get_latest per URL. Each result includes the URL and its oldest test object (null if no test exists for that URL).
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Array of URLs to look up (max 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds concrete behavioral detail about the result shape ('Each result includes the URL and its oldest test object (null if no test exists for that URL)'), which goes beyond the schema. It does not contradict 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 three sentences long with no filler. The first sentence states action and limits, the second provides the ideal usage scenario and workflow, and the third specifies the result format. It is tightly packed and 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 batch read tool, this is complete: it specifies what it does, the batch limit, why to use it, the result structure (including null behavior), and how it fits with sibling tools. No output schema exists, but the description compensates by describing the result. An agent can correctly decide to call it and understand the response.
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 only parameter 'urls' is fully covered by the schema (type array, minItems 1, maxItems 100, with a description). The tool description does not add extra parameter-specific detail (e.g., URL formatting) beyond what the schema provides. Since coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Get), resource (oldest baseline test snapshots), scope (batch of URLs up to 100), and explicitly distinguishes from the singular sibling gvt_get_oldest by noting 'in a single call'. It also references gvt_get_latest as the complementary tool, making the purpose unambiguous.
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 when to use it ('Ideal for monthly/periodic batch comparisons') and gives a specific workflow ('fetch baselines in bulk here, then call gvt_get_latest per URL'). This clearly guides an agent away from using this tool for single-URL lookups, which are better served by gvt_get_oldest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a GVT prompt workflow with concrete argument values, returning the complete step-by-step instruction text ready to follow. Also returns the effective arguments that were bound (provided values plus defaults for omitted optionals). Prompt names and their arguments come from gvt_list_prompts. The rendered text references GVT tools by name — call them as instructed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Prompt name from gvt_list_prompts, e.g. gvt_setup_domain_monitoring. | |
| arguments | No | Argument values for the prompt, keyed by argument name (e.g. {"domain": "example.com", "frequency": "weekly"}). Omit optional arguments to use their defaults. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing safety. The description adds behavioral detail beyond annotations: it specifies the output contains both the complete instruction text and the effective arguments (provided values plus defaults for omitted optionals). This is valuable context that helps an agent understand what to expect. No contradictions 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?
The description is two sentences of high-density content without unnecessary verbosity. It front-loads the core action and output, then adds the crucial relationship to gvt_list_prompts and the follow-up instruction. The structure is clean and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is well-specified for its function: it names the inputs, the source of valid values, and what the output contains. It also hints at next steps ('call them as instructed'). However, it does not elaborate on potential edge cases (e.g., what happens if a referenced tool doesn't exist) or provide a return schema, which, while not required, could further improve completeness. Overall, it is sufficient for an agent to use 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%, and both parameters are fully documented. The description explains that arguments are provided as key-value pairs and that optional ones can be omitted to use defaults. The schema even includes a concrete example for arguments. This leaves no ambiguity about how to construct the inputs.
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: 'Render a GVT prompt workflow with concrete argument values, returning the complete step-by-step instruction text ready to follow.' It uses a specific verb (render) and names the resource (prompt workflow). It also differentiates from siblings by referencing gvt_list_prompts as the source of prompt names and arguments, making it distinct from listing or executing 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 implicitly provides usage context: it says prompt names and arguments come from gvt_list_prompts, indicating a sequence (first list, then render). It also notes that the rendered text references GVT tools by name and instructs to 'call them as instructed', which clarifies you should subsequently invoke those tools. However, it does not explicitly state when NOT to use this tool or contrast it with other siblings beyond the source relationship, so it falls short of full explicitness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare the oldest baseline vs the latest non-expired test for a single URL or an entire domain, with pre-computed per-category deltas (latest minus baseline). Provide exactly one of url or domain. Domain mode matches the exact domain, www., and subdomains (alphabetical, capped by limit). Page through the whole domain with offset: offset=0 for the first page, offset=limit for the second, following hasMore/nextOffset. This replaces paging the full test history and computing comparisons client-side — one call per site.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Single URL scope (XOR with domain). | |
| limit | No | Cap on returned records in domain mode (max 100, default 25). | |
| domain | No | Domain scope — matches the domain, www.<domain>, and subdomains (XOR with url). | |
| offset | No | Number of matched URLs to skip in domain mode (row skip, not a page number). Use offset=0 for the first page, offset=limit for the second. Ignored in single-URL mode. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds substantial behavioral detail beyond that: it defines the comparison baseline, includes domain matching (www.<domain> and subdomains), alphabetical ordering, limit caps, offset semantics, and response navigation via hasMore/nextOffset. This is rich, non-obvious behavior that an agent needs to know.
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 three dense sentences, front-loaded with the core purpose, then covering the critical input constraint, domain behavior, pagination, and the value proposition. Every sentence earns its place, with 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 tool with four optional params, XOR constraints, and pagination but no output schema, the description covers the key input semantics and response navigation. It mentions per-category deltas and hasMore/nextOffset, though it does not describe the exact shape of those deltas, which slightly limits completeness.
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 value by clarifying the XOR relationship between url and domain, explicitly stating that offset is a row skipper, not a page number, and explaining that offset is ignored in single-URL mode. This goes beyond the schema descriptions.
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 operation: compare the oldest baseline against the latest non-expired test for a URL or domain, with pre-computed per-category deltas. This clearly distinguishes it from sibling history tools like gvt_get_latest, gvt_get_oldest, and gvt_get_test_results by emphasizing the comparison and delta computation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage constraints: provide exactly one of url or domain, explains domain matching scope, and defines offset-based pagination. It also frames this as a replacement for paging full history and computing comparisons client-side. It does not explicitly name sibling alternatives, but the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discovers and ranks URLs from a domain's XML sitemaps. Use this tool to find the most significant pages on a website (e.g., homepages, product pages, recently updated content) before analyzing them. Supports filtering by URL patterns and automatically flags pages blocked by robots.txt or already tested. Returns a ranked list of URLs optimized for SEO importance. Legal/policy boilerplate pages (privacy, terms, cookies, disclaimers, refund policies, etc) are flagged with legalPage:true and carry a -25 significance penalty; use the legalPages filter to drop them (exclude) or isolate them for a policy-coverage audit (only).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The target website URL or an explicit sitemap .xml URL. | |
| sort | No | How to sort the discovered URLs. 'significance' uses SEO heuristics. | significance |
| limit | No | Maximum number of URLs to return (default 10). | |
| exclude | No | Wildcard patterns to reject (e.g., '*archive*'). | |
| include | No | Wildcard patterns to require (e.g., '*blog*'). Only '*' wildcards are supported. | |
| legalPages | No | Tri-state filter for legal/policy boilerplate pages (privacy, terms, cookies, disclaimers, refund policies, etc). "include" keeps them (default), "exclude" drops them, and "only" returns just the legal/policy pages — useful for auditing a site's policy coverage. | include |
| excludeTested | No | If true, omits URLs the user has already tested. | |
| excludeScheduled | No | If true, omits URLs currently in the testing queue. | |
| excludeDisallowed | No | If true, silently drops URLs that are blocked by robots.txt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it flags legal pages with legalPage:true, applies a -25 significance penalty, and explains that robots.txt-blocked pages are silently dropped when excludeDisallowed is true. It does not contradict 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 well-structured and front-loaded with the core purpose, followed by filtering behavior and legal-page handling. It is slightly long but every sentence adds meaningful context, and the legal-page explanation earns its place because it clarifies a non-obvious behavior.
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 discovery tool with 9 parameters and no output schema, the description covers the key behaviors an agent needs: ranking, filtering, legal-page handling, and robots.txt behavior. It does not describe the exact return format, but the absence of an output schema makes that a minor gap given the rich parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters. The description adds context for the legalPages parameter and the significance penalty, but most parameter semantics are already fully covered by the schema. 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 states a specific verb ('Discovers and ranks'), a clear resource ('URLs from a domain's XML sitemaps'), and the intended use case ('find the most significant pages... before analyzing them'). It also distinguishes itself from sibling tools by focusing on sitemap discovery rather than test execution or management.
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 when to use this tool ('before analyzing them') and provides clear filtering guidance, including how to handle legal/policy pages with the legalPages filter. It also names the alternative behavior for policy-coverage audits ('only'), giving the agent explicit routing context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full results for a visibility test by tid. Returns per-category resultData for all 7 analysis types (heading, semantic, accessibility, schema, javascript, nojs, social), overall scores, findingSentence, and shareableTid. If status is "pending" or "running", the test is not yet complete — wait and retry. findingSentence is a pre-generated natural language verdict; use it as the primary summary for the developer. shareableTid is non-null when the result is public and can be linked.
| Name | Required | Description | Default |
|---|---|---|---|
| tid | Yes | Opaque 8-character hash ID returned by gvt_run_visibility_test or gvt_list_tests. Not an integer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnly, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond that: results are not final while status is pending/running, and callers should wait and retry. It also clarifies the semantics of findingSentence and shareableTid, giving the agent non-obvious knowledge about how to interpret the response. 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?
The description is front-loaded with the core action and then efficiently packs high-value details: the exact return fields, retry condition, and usage hints for findingSentence and shareableTid. Every sentence contributes useful information without redundancy or 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?
With no output schema, the description takes on the burden of explaining return values and does so thoroughly: it lists per-category resultData across all 7 analysis types, overall scores, findingSentence, shareableTid, and the pending/running caveat. For a single-parameter read-only tool, this is complete enough for an agent to invoke and interpret 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 description coverage is 100%, and the tid parameter is already well documented as an opaque 8-character hash from gvt_run_visibility_test or gvt_list_tests, not an integer. The description reinforces that results are keyed by tid but does not add substantial new parameter-level meaning beyond what the schema provides, 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 uses a specific verb and resource: 'Get full results for a visibility test by tid.' It goes further by enumerating the exact output categories (7 analysis types, overall scores, findingSentence, shareableTid), making the tool's responsibility unmistakable and clearly distinct from sibling getters like gvt_get_latest or gvt_get_score_trend.
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 establishes when to use the tool: whenever a caller has a tid and wants complete visibility test results. It adds operational guidance about pending/running status implying the caller should wait and retry. It does not explicitly name alternative tools or exclusion conditions, but the context is strong enough without them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the GVT prompt workflows: user-invocable recipes that chain GVT tools into complete tasks (check a page, review a monthly batch, analyze regressions, verify fixes, set up domain monitoring, report client status). Each entry lists its arguments. Use gvt_get_prompt to render a prompt with concrete argument values, then follow the rendered instructions to run the workflow.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds valuable context about what the workflows are, what they do, and that each entry lists its arguments, which helps set expectations about the tool's purpose 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?
Two sentences that deliver high-value information: what the workflows are, what they contain, and how to proceed after listing. No fluff 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 zero-parameter, read-only listing tool, the description is nearly complete. It explains the resource, the contents of each entry, and the follow-up action. The absence of an output schema is partially compensated by noting that entries list their arguments, though the exact return shape remains unspecified.
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 inferable from the schema (100% coverage), so the description does not need to explain parameters. The mention that each entry lists its arguments provides useful context for how the tool's output relates to subsequent parameterized calls. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (GVT prompt workflows) and the action (list), and identifies them as user-invocable recipes that chain GVT tools into complete tasks. It distinguishes itself from the sibling tool gvt_get_prompt by noting that the latter renders a prompt with concrete argument values.
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 instructs the agent to use gvt_get_prompt to render a prompt with concrete argument values after listing. This provides clear routing guidance for when to use this tool versus its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List visibility tests for the authenticated user, newest first. Supports filtering by domain (optionally including subdomains), by URL (exact or contains match), by creation date range, by status, and by test type.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to filter tests by; matched per urlMode (contains by default). | |
| limit | No | Max results to return (default 10, max 100) | |
| domain | No | Domain to filter tests by, e.g. example.com. Subdomains are included unless includeSubdomains is false. | |
| offset | No | Number of records to skip before returning results (not a page number). Use offset=0 for the first page, offset=limit for the second page, etc. | |
| status | No | Test status to filter by: pending, processing, completed, or failed. | |
| urlMode | No | How the url filter matches: "exact" for full-URL equality, "contains" for substring match. | contains |
| testType | No | Test type to filter by: url, html, or html_paste. | |
| createdTo | No | Exclusive creation-date upper bound. YYYY-MM-DD (UTC midnight) or full ISO 8601 instant. | |
| createdFrom | No | Inclusive creation-date lower bound. YYYY-MM-DD (UTC midnight) or full ISO 8601 instant. | |
| sortDirection | No | Sort direction by creation date: desc (newest first, default) or asc (oldest first). | desc |
| includeSubdomains | No | If true (the default), includes tests for subdomains of the given domain. Set false to match the exact domain only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations: results are newest first by default, scope is limited to the authenticated user, and subdomains are optionally included. This covers the meaningful behavioral nuances without contradicting 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 two sentences, front-loaded with the core action and default ordering, then briefly enumerates the supported filters. Every clause earns its place, and no unnecessary detail is included.
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 rich annotations, comprehensive parameter descriptions, and clear sibling context, the description is complete enough for an agent to select and invoke the tool correctly. It states scope, ordering, and filtering capabilities, while the schema handles parameter details and the annotations handle safety expectations.
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 input schema already fully documents every parameter. The description summarizes the filter dimensions (domain, URL, date range, status, test type) but does not add meaning beyond what the schema already provides; it repeats the concepts rather than deepening them.
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 and resource: "List visibility tests for the authenticated user, newest first." This clearly distinguishes it from sibling tools like gvt_list_prompts and from retrieval tools like gvt_get_test_results, because it explicitly scopes the operation to listing visibility tests.
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: whenever the agent needs a filterable list of the authenticated user's visibility tests. It does not explicitly name alternative tools, but the resource and filtering scope are specific enough that an agent can infer this is the list-oriented counterpart to run/get/delete workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle the public visibility of a test session. Set is_public to true to make the test shareable via a public link, or false to make it private. This is the primary way to control who can view a test result without requiring MCP authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| tid | Yes | The 8-character test ID returned by gvt_run_visibility_test. | |
| is_public | Yes | true to make the test publicly shareable, false to make it private. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds context about public link sharing and authentication, but does not disclose potential side effects like link invalidation or whether toggling affects existing shares. It does not contradict 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 two sentences, front-loads the main action, and provides a clear conditional explanation. Every sentence earns its place, with no fluff.
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 toggle tool with full schema coverage and annotations, the description is nearly complete. It explains the primary use case and the meaning of the boolean. It could mention what happens to existing public links when set to false, but that is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds a bit of context about the effect of is_public (shareable via public link) but does not add new syntax or format details beyond the schema. 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 clearly states the tool's purpose: toggling public visibility of a test session via the is_public parameter. It distinguishes itself from siblings by explicitly noting it is the primary way to control viewing without MCP authentication, which differentiates it from gvt_share_test and gvt_run_visibility_test.
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 explains when to use this tool (to control who can view a test result without MCP authentication) and implies it is the primary method. It does not explicitly name alternatives or exclusions, but the context signals and sibling list suggest gvt_share_test might be an alternative; the description does not explicitly say 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.
Run a GEO visibility test on a URL. Analyzes 7 categories: JavaScript dependencies (js), no-JS rendering (nojs), semantic HTML5, heading structure, schema.org markup, social tags, and accessibility. This is an async operation — it returns a tid immediately. Pass that tid to gvt_get_test_results to retrieve scores and issues once the test completes (poll until status is not "pending" or "running").
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to analyze | |
| waitForJs | No | Wait for JavaScript rendering before analysis. Set to false to skip JS rendering (faster, but may miss dynamically injected content). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses behavior beyond annotations: async execution, immediate tid return, and polling semantics. This is important operational context that annotations alone do not convey, and it matches the annotations' non-read-only, non-idempotent nature.
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 three focused sentences with no filler. It front-loads the action and result, then gives the necessary continuation steps.
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 no output schema, the description covers the essential invocation flow: what the tool returns, how to retrieve results, and the polling condition. The listed categories provide useful context for interpretation.
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 both parameters. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a GEO visibility test on a URL, with a specific verb and resource. It enumerates the seven analyzed categories, distinguishing it from sibling tools like gvt_get_test_results or gvt_list_tests.
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: it is an async operation that returns a tid, and explicitly instructs the agent to pass that tid to gvt_get_test_results and poll until completion. It does not explicitly state when to choose this over gvt_batch_run_tests, but the flow is clear enough for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage recurring test schedules. Schedule management modes (require urls array): "add" to create or update scheduled URLs, "delete" to remove scheduled URLs (by schid or url), "reset" to reset existing schedules. In reset mode, an optional domain field scopes the reset to schedules matching that domain only (e.g. "example.com" deletes all schedules for that domain before upserting the provided URLs; omitting domain resets ALL schedules). Schedule control modes (require schid): "pause" to temporarily halt a schedule, "resume" to restart a paused schedule (also clears auto-pause reasons and failure counts), "cancel" to permanently cancel a schedule, "change_frequency" to update how often a test re-runs. Subscription-tier enforcement applies.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Schedule operation mode. add/delete/reset operate on URLs (require urls array). pause/resume/cancel/change_frequency operate on a single schedule (require schid). | add |
| urls | No | Array of URL/schedule objects. Required for add, delete, and reset modes. | |
| schid | No | Schedule ID. Required for pause, resume, cancel, and change_frequency modes. | |
| domain | No | Domain to scope a reset operation (reset mode only). e.g. "example.com". Matches https://, http://, with/without www., with/without trailing path. Omit to reset ALL schedules. | |
| frequency | No | New frequency for the schedule. Required for change_frequency mode. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description openly discloses destructive behaviors—delete, reset ('deletes all schedules for that domain before upserting'), omitting domain 'resets ALL schedules', and cancel ('permanently cancel'). It also adds side effects like resume clearing 'auto-pause reasons and failure counts', which goes beyond the annotations and matches destructiveHint=true.
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 organized into schedule-management versus schedule-control modes, front-loads the purpose, and every sentence contributes mode semantics or side effects. The reset example and domain-scoping sentence earn their 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 multi-mode tool with five parameters and no output schema, the description covers all modes, required arguments, reset scope, resume side effects, and subscription constraints. An agent has enough information to select the right mode and parameters.
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 cross-parameter meaning by tying modes to required parameters (urls vs schid), explaining reset's domain-scoping semantics, and noting resume's side effects. A minor ambiguity remains: 'delete by schid or url' is not perfectly reconciled with the schema's note that schid is required for delete/reset modes.
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 starts with a specific verb and resource — 'Manage recurring test schedules' — and enumerates all seven operation modes. This clearly separates it from one-off test tools like gvt_manage_test and gvt_batch_run_tests, so an agent can infer what the tool is for.
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 mode-level requirements: schedule management modes 'require urls array' and control modes 'require schid', plus detailed reset-scoping rules. It does not explicitly name sibling alternatives or state when not to use the tool, so it falls short of full 5.
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.
gvt_get_sitemap_urls2 fields changedInput schema / properties / limit / defaultPrevious value: -25New value: +10Input schema / properties / limit / descriptionPrevious value: -"Maximum number of URLs to return."New value: +"Maximum number of URLs to return (default 10)."gvt_batch_run_testsgvt_delete_testgvt_get_fixgvt_get_knowledgegvt_get_latestgvt_get_oldestgvt_get_oldest_listgvt_get_promptgvt_get_score_trendgvt_get_sitemap_urlsgvt_get_test_resultsgvt_list_promptsgvt_list_testsgvt_manage_testgvt_run_visibility_testgvt_schedule_testgvt_share_testClaiming 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!
