Kilotest leverages 10 rule engines to test web pages for front-end quality (accessibility, usability, and standards conformity) and report results with specifiable granularity.
Get one full report in JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| jobID | Yes | Job identifier of the report (example: x9z) | |
| timeStamp | Yes | Timestamp of the report in YYMMDDTHHmm format (example: 260503T0432) |
| Name | Required | Description |
|---|---|---|
| tool name | Yes | |
| this request | Yes | |
| tool collection | Yes | |
| response content | Yes | |
| response metadata | Yes | |
| URLs of similar requests for web users | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that the result is a 'full report in JSON', which gives some response-format context, but it does not address pagination, size limits, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or repetition. It communicates the verb, resource, scope, and output format economically, and every word contributes to the meaning.
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 simple two-parameter schema, existing output schema, and strong safety annotations, the description is nearly complete for invocation purposes. The main missing element is explicit guidance on when to use getReport versus listReports, but the tool is simple enough that this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters include type and example values, so the schema already carries the semantic weight. The description adds no parameter-specific meaning beyond what the schema provides, which matches the baseline for full schema coverage.
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 action ('Get'), the resource ('one full report'), and the output format ('JSON'). The phrase 'one full report' helps distinguish it from the sibling listReports by implying a detailed single-item fetch rather than a list operation, though it does not explicitly name the alternative.
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 no guidance about when to use this tool versus alternatives like listReports. It relies entirely on the tool name and input schema to imply the use case, with no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provide details about one element reported as exhibiting one issue in one report, including the diagnoses provided by rule engines about how the element exhibited the issue.
| Name | Required | Description | Default |
|---|---|---|---|
| jobID | Yes | Job identifier of the report (example: x9z) | |
| issueID | Yes | Issue identifier (example: contrastPoor) | |
| timeStamp | Yes | Timestamp of the report in YYMMDDTHHmm format (example: 260503T0432) | |
| catalogIndex | Yes | Identifier of the issue-exhibiting element in the catalog of elements on the page (example: 372) |
| Name | Required | Description |
|---|---|---|
| tool name | Yes | |
| this request | Yes | |
| tool collection | Yes | |
| response content | Yes | |
| response metadata | Yes | |
| URLs of similar requests for web users | Yes |
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 covered. The description adds the resource scope and the fact that diagnoses come from rule engines, but it does not describe output shape, pagination, or other behavioral details. This is similar to the calibrated mid-tier examples: annotations do the heavy lifting, with modest descriptive value added.
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 that immediately states the action, object, and scope without filler or repetition. It earns every word and is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only tool with full parameter documentation, a rich output schema, and safety annotations, the description is nearly complete. It only lacks an explicit usage boundary against sibling tools, but that gap is covered under usage guidelines rather than this dimension.
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 100% parameter description coverage, so each of the four required parameters is already documented. The tool description only ties them together conceptually rather than adding new field-level meaning, 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 states a specific verb and object: it provides details about a single element, issue, and report, with the distinguishing content being rule-engine diagnoses. This makes its purpose clear and separates it from siblings like listIssues and listViolators.
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 scoped language ('one element', 'one issue', 'one report') implies when this tool is appropriate, but there is no explicit guidance about when to use it instead of sibling tools. An agent must infer the boundary rather than being told it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provide details about one report, including basics about the issues reported in it.
| Name | Required | Description | Default |
|---|---|---|---|
| jobID | Yes | Job identifier of the report (example: x9z) | |
| timeStamp | Yes | Timestamp of the report in YYMMDDTHHmm format (example: 260503T0432) |
| Name | Required | Description |
|---|---|---|
| tool name | Yes | |
| this request | Yes | |
| tool collection | Yes | |
| response content | Yes | |
| response metadata | Yes | |
| URLs of similar requests for web users | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no safety contradiction exists. The description adds only the 'one report / issues' scope and no additional behavioral context such as return shape or pagination, but the output schema helps fill that 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?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying what the tool does, and no structured information is redundantly repeated.
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 a full output schema, detailed annotations, and 100% parameter coverage, the definition is mostly complete for a read-only tool. The main gap is contextual: the description does not differentiate listIssues from the sibling getReport or clarify that this tool is the one to choose for issue details, which can lead to incorrect selection.
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%: both jobID and timeStamp are described with type, purpose, and format examples. The description contributes no parameter-specific meaning beyond the schema, 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 uses a clear verb ('Provide details') and identifies the resource ('one report') plus the relevant content ('basics about the issues reported in it'). However, it does not distinguish listIssues from sibling getReport, which could plausibly also provide details about one report, so it falls short of a 5.
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 singular 'one report' and the mention of issues imply the tool is for retrieving issue-level detail for a specific report identified by jobID/timeStamp. It never says when not to use it or directs the agent to alternatives such as getReport or listReports, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provide basics about all available reports.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tool name | Yes | |
| this request | Yes | |
| tool collection | Yes | |
| response content | Yes | |
| response metadata | Yes | |
| URLs of similar requests for web users | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds the nuance of returning 'basics' rather than full details, which is useful but minimal. It does not contradict annotations and provides no additional behavioral context beyond what the annotations and schema already communicate.
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 concise sentence, 'Provide basics about all available reports,' with no filler. It front-loads the action and clearly states the scope. Every word 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 list tool with an output schema and strong annotations (readOnly, idempotent, not destructive), the description sufficiently states the tool's purpose. The only gap is lack of explicit usage guidance relative to siblings, but that is minor given the simplicity of the operation and the richness of structured metadata.
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 there is nothing to document beyond the schema, which is vacuously 100% covered. Per the rubric, a 0-raw tool gets a baseline of 4. The description does not need to explain parameter semantics since there are none.
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 action ('provide basics') and the resource ('all available reports'), which distinguishes it from sibling tools like getReport (specific report) and listDiagnoses/listIssues listViolators (report subsets). However, it does not explicitly name any sibling or contrast itself, so it misses the top score.
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?
No guidance is given for when to use this tool versus alternatives. The sibling list suggests other report-related tools exist, but the description does not say 'use this to get a summary of all reports' or 'for details, use getReport.' An agent must infer the intended use case without explicit instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provide details about one issue in one report, including basics about the elements of the tested page that were reported as exhibiting the issue.
| Name | Required | Description | Default |
|---|---|---|---|
| jobID | Yes | Job identifier of the report (example: x9z) | |
| issueID | Yes | Issue identifier (example: contrastPoor) | |
| timeStamp | Yes | Timestamp of the report in YYMMDDTHHmm format (example: 260503T0432) |
| Name | Required | Description |
|---|---|---|
| tool name | Yes | |
| this request | Yes | |
| tool collection | Yes | |
| response content | Yes | |
| response metadata | Yes | |
| URLs of similar requests for web users | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context that the result focuses on elements exhibiting a given issue, but it does not disclose anything beyond that, such as output shape or limitations.
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 concise sentence that states the core purpose without extraneous wording. It is appropriately front-loaded, though it repeats the annotation title verbatim rather than adding a differently structured summary.
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 lookup with three fully documented parameters and an output schema, the description is mostly sufficient. However, it lacks any guidance about when to select this tool over the sibling tools, which is a noticeable completeness gap given the similar sibling names.
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 all three parameters are already documented with names and example values. The description adds only the high-level idea of 'one issue in one report' and does not provide additional semantic detail beyond what the schema already gives.
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 ('provide details about one issue in one report') and resource scope ('elements of the tested page ... exhibiting the issue'), which distinguishes it from broader report- or issue-listing tools. However, the tool name 'listViolators' suggests a plural list, while the description frames it as details about one issue, so the connection between name and description is not completely explicit.
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 no explicit guidance on when to use this tool versus the siblings such as listIssues, getReport, or listDiagnoses. The one-issue/one-report wording implicitly narrows the use case, but no direct alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Process my request to add or improve a feature.
| Name | Required | Description | Default |
|---|---|---|---|
| feature | Yes | description of requested feature improvement or new feature |
| Name | Required | Description |
|---|---|---|
| tool name | Yes | |
| this request | Yes | |
| tool collection | Yes | |
| response content | Yes | |
| response metadata | Yes | |
| URLs of similar requests for web users | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is non-read-only, non-idempotent, and non-destructive, but the description adds little behavioral context. It says it 'processes' a request but does not disclose whether this creates a ticket, persists anything, triggers notification, or what side effects may occur. 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 a single sentence with no wasted words. However, it is somewhat low-value and repetitive with the tool name, offering only the core idea without additional useful structure or detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers the basic intent and parameter usage. It is incomplete in distinguishing requestFeature from sibling request tools and in explaining behavioral outcomes, but it is minimally adequate for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the 'feature' parameter is already described as 'description of requested feature improvement or new feature.' The tool description adds no further formatting, constraints, examples, or clarification beyond the schema's existing documentation.
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 a resource: 'request to add or improve a feature,' and the 'feature' scope helps distinguish it from sibling test-related tools. However, the verb 'Process' is generic and there is no explicit contrast with siblings like requestTest or requestRetest.
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 'add or improve a feature' implies the intended use case: when a user wants a new feature or an enhancement. There is no explicit when-not-to-use guidance or named alternatives, so usage context is only implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Process my request to retest a page about which a report is available.
| Name | Required | Description | Default |
|---|---|---|---|
| jobID | Yes | Job identifier of the latest report about the page (example: x9z) | |
| reason | Yes | 20- to 100-character reason why the page should be retested | |
| timeStamp | Yes | Timestamp of the latest report about the page in YYMMDDTHHmm format (example: 260503T0432) |
| Name | Required | Description |
|---|---|---|
| tool name | Yes | |
| this request | Yes | |
| tool collection | Yes | |
| response content | Yes | |
| response metadata | Yes | |
| URLs of similar requests for web users | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false and destructiveHint=false, but the description itself adds no behavioral detail about side effects, prerequisites, or what happens after the request is processed. The description does not contradict annotations, but it also does not enrich them with meaningful operational 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 one clear sentence with no filler or redundant phrases. It front-loads the core purpose and stays appropriately minimal for the available schema and annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the fully documented schema, output schema, and annotations, conveys the basic operation and parameter requirements. However, it lacks explicit routing guidance among siblings and does not explain the relationship between this retest request and the referenced report beyond the parameter descriptions.
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 all three required parameters have clear descriptions with examples. The tool description adds no parameter-specific meaning beyond the schema, 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 identifies the action as requesting a retest of a page for which a report exists, using a specific verb-resource pairing. It implicitly differentiates from the sibling requestTest by focusing on 'retest' and prior report availability, though it does not name the alternative directly.
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 'about which a report is available' implies the tool should be used when a prior report exists, but it offers no explicit guidance on when to prefer requestTest or other siblings. Selection context is present but only by inference, not direct instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Process my request to test a page about which no report is available yet.
| Name | Required | Description | Default |
|---|---|---|---|
| URL | Yes | 12- to 300-character URL of the page, including the https:// scheme and any query | |
| reason | Yes | 20- to 100-character reason why the page should be tested | |
| description | Yes | 10- to 100-character description of the page conforming to the naming convention used in the listReports output |
| Name | Required | Description |
|---|---|---|
| tool name | Yes | |
| this request | Yes | |
| tool collection | Yes | |
| response content | Yes | |
| response metadata | Yes | |
| URLs of similar requests for web users | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, so the description correctly aligns with a non-read operation. It adds that the target must be a page with no report yet, but does not disclose whether the request is queued, how long testing takes, or what immediate effect the call has. The presence of an output schema partially compensates for this.
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 concise sentence with no filler and the key condition is front-loaded. The verb 'process my request' is slightly weak, but the sentence is compact 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?
For a three-parameter tool with 100% schema coverage, annotations, and an output schema, the description is sufficient for basic correct invocation. It clearly communicates the no-report-yet precondition, though it does not address edge cases such as duplicate requests or interactions with requestRetest.
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 each parameter already has a meaningful description with length constraints. The tool description itself adds no additional parameter semantics beyond what the schema provides, so the baseline score 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 clear action ('process my request to test a page') and an important scope condition ('about which no report is available yet'). It implicitly differentiates from requestRetest by requiring no existing report, but the verb 'process' is less specific than 'submit' or 'create', and no sibling tool is explicitly mentioned.
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 'about which no report is available yet' gives an explicit precondition for using this tool rather than requestRetest or getReport. It does not spell out exclusions or name alternatives, but the usage context is clear enough for an agent to make a reasonable choice.
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.
getReportlistDiagnoseslistIssueslistReportslistViolatorsrequestFeaturerequestRetestrequestTestClaiming 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!
Add one secure layer between your agents and this server.
Tools are mostly distinct with a clear hierarchy: listReports, getReport for reports; listIssues, listViolators, listDiagnoses for progressively deeper detail. However, getReport may overlap with the other list tools in purpose, and an agent might initially confuse listViolators vs listDiagnoses without careful reading.
All tools follow a consistent verb+noun camelCase pattern: get for single resources, list for enumerations, request for actions. The naming convention is uniform and predictable, making it easy to infer tool purpose.
8 tools is well-scoped for a testing/reporting server. Each tool serves a distinct function in the workflow (test request, report retrieval, drill-down into issues, violators, diagnoses, and feature requests) without redundancy or bloat.
The tool surface covers the core lifecycle: request test, retest, list reports, inspect full report, and drill into issues, violators, and diagnoses. The only minor gap is a lack of explicit update/delete operations for reports, but this may not be essential for the server's purpose.