A
licenseNot graded
qualityB
maintenanceProvides URL parsing and analysis tools, including component parsing, deterministic hash generation, heuristic safety checks, and metadata extraction, all without external HTTP requests.
7
MIT
URL origin only
Server Details
URL origin only
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- sadri-dridi/named-mcp-utilities
- GitHub Stars
- 0
TDQS
C2.3/5.0
Scored across 11 tools
Disambiguation3/5
Some tools have overlapping purposes, such as 'citation', 'normalize-url', and 'url-origin' all returning URL components, and 'timezone' and 'utc-time' both providing current time. Most descriptions are clear, but a few vague names like 'compatibility' and 'citation' require extra inference.
Naming Consistency3/5
All tool names use lowercase hyphenation, but the pattern is mixed: some are verb-noun (inspect-robots, normalize-url, validate-json), while others are bare nouns (citation, compatibility, timezone). This inconsistency makes the naming less predictable.
Tool Count4/5
With 11 tools, the count is reasonable for a small utility server. There is some redundancy in URL and time-related tools, but the overall number is not excessive or too sparse.
Completeness3/5
The set covers common web/URL utilities, HTTP status metadata, time conversion, JSON validation, and robots.txt inspection. However, the purpose is somewhat diffuse and missing related obvious capabilities like HTTP request execution or URL parsing variants, leaving the completeness ambiguous.
Available Tools
29 toolsagent-tool-indexCInspect
Find a public pay-per-call tool gateway (Monid). Returns CLI setup, how-it-works, skill file, and remote MCP hops. Task text discarded.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
TDQS
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently notes that task text and parameter values are discarded after the call, which informs the agent about side effects. However, it does not disclose whether the tool makes external network requests, requires authentication, or has any side effects beyond returning connection methods.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences with no redundant phrasing. It directly states the tool's primary function and a key behavioral detail, making it easy to read and quickly understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description is incomplete because it does not explain how the tool selects a gateway, what format the 'connection methods' take, or whether any of the parameters are required for certain task types. The phrase 'task text discarded' adds confusion rather than clarification, leaving significant gaps in the agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for all 9 parameters, each indicating its purpose and that it is discarded. The description adds little beyond the schema, mainly repeating the discarding behavior and mentioning that the tool returns connection methods, but does not clarify how parameters map to different gateway choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool finds a public pay-per-call gateway for tasks like weather, search, scrape, or voice, and returns connection methods. However, it is vague about how the gateway is selected and what 'task text discarded' means in practice, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It lists example task categories (weather, search, scrape, voice) but provides no explicit guidance on when to use this tool over the many sibling tools (e.g., weather-hint, search-query-len). There is no mention of prerequisites, alternatives, or conditions that would make this the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
browser-url-okInspect
Check whether a URL can be opened. No browser is launched.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
calc-evalInspect
Evaluate a+b style arithmetic. Expression discarded.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
citationCInspect
Return host, scheme, and HTTP status for a URL. Page content is not stored.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
TDQS
C2.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that page content is not stored, which is a positive transparency note, but it does not explain other behaviors such as HTTP fetching, redirects, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but incomplete, leaving out critical information about the other parameters and interactions; it is structured as a single sentence but does not cover the tool's full scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool name and description suggest a URL-focused function, but the schema includes unrelated parameters, and the description fails to provide a complete context for the tool's capabilities and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for each parameter, but the tool description does not explain how they relate to each other or when to use each; the presence of unrelated parameters (json, zone) without explanation reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary function for URL inputs, but it omits the other parameter functions (json, zone) implied by the schema, making the overall purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a specific use case (URL citation) but no guidance on when to use this tool vs. the sibling tools like normalize-url or validate-json, and no mention of alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compatibilityCInspect
Show how this request is classified. No identifiers are retained.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
TDQS
C2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only mentions that identifiers are not retained, which is a privacy note, but it doesn't state whether the tool is read-only, what it returns, or what side effects it may have. The core behavior is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the main sentence is vague. It's efficient in length but fails to convey necessary information, so it doesn't earn a higher score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four optional parameters, no output schema, and no annotations, the description is severely inadequate. An agent cannot determine what 'classified' means, what input combinations are valid, or what the return value looks like. The tool is effectively unusable based on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a descriptive definition (e.g., 'HTTPS URL to normalize or cite'). The description adds no extra meaning about how these parameters relate to 'classification', so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Show how this request is classified' but 'classified' is undefined and the tool name 'compatibility' doesn't clarify. It doesn't specify the resource or operation precisely, nor does it distinguish from siblings like normalize-url or validate-json.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many siblings (e.g., normalize-url, validate-json, timezone). The description offers no context, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domain-shapeDInspect
Split a hostname into labels without WHOIS or ownership data.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
TDQS
D1.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry behavioral transparency. The phrase 'without WHOIS or data' hints at limited behavior but does not clearly disclose side effects, read-only nature, or what happens with invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and compact, but the odd qualifier and lack of parameter alignment reduce its effectiveness. It is concise but not well structured for the actual tool purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is not complete for the tool's apparent purpose. It does not explain expected input formats, output shape, or how to handle the mismatched parameters, leaving agents without enough context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter descriptions are largely mismatched: 'url' is described as a URL to normalize, 'json' as text to validate, and 'zone' as a timezone name, none of which relate to splitting a hostname into labels. Only 'host' is plausibly relevant, but it is minimally described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Split a hostname into labels.' However, the qualifier 'without WHOIS or data' is confusing and the parameter names/descriptions do not align with this purpose, muddying overall clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus sibling tools such as normalize-url or url-origin. The description does not mention any alternative or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch-statusInspect
HEAD a public URL and return status only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
figma-url-shapeInspect
Parse a Figma file URL. Path discarded.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
file-path-okInspect
Check whether a path looks safe. No disk access.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
geo-hintInspect
Latitude and longitude for a place via Open-Meteo.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
github-repo-shapeInspect
Parse owner and repo from a GitHub URL.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
hn-front-countInspect
Count current Hacker News front-page stories. Titles discarded.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
iana-zonesDInspect
Common IANA timezone names for clock calls.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
TDQS
D1.3/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. The one-sentence description discloses nothing about read-only vs. mutating nature, return format, side effects, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief at one sentence, which is concise, but it reads as a noun phrase without a clear action verb. The brevity undermines clarity more than it aids conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with four parameters, no output schema, and no annotations, placing full burden on the description. The one-sentence description fails to explain the tool's operation, return value, or how the parameters relate to its function, making it inadequate for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the schema for the four parameters. Furthermore, the schema descriptions themselves (e.g., 'HTTPS URL to normalize or cite', 'JSON text to validate; discarded after the check') appear copied from other tools' contexts and don't explain how url, host, and json relate to iana-zones' function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Common IANA timezone names for clock calls' is a noun phrase without a clear action verb, failing to state whether the tool lists zones, validates a zone, or looks up zones by URL/host. The mention of 'clock calls' hints at a connection to time-related sibling tools but doesn't clarify the tool's actual function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus any of its ten siblings. Given the presence of closely related tools like timezone and utc-time, the agent has no basis for selecting iana-zones over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inspect-robotsCInspect
Fetch a public robots.txt and return group counts only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
TDQS
C2.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the basic fetch-and-count behavior but omits any details on error handling, redirects, rate limits, or side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the core function. No unnecessary verbiage, though it lacks some structural detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the mismatched schema and missing behavioral details, the description is far from complete. It fails to explain required inputs, output format, or edge cases, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are clearly mismatched (e.g., 'JSON text to validate' and 'IANA timezone name' appear irrelevant to fetching robots.txt). The description does not clarify which parameters are actually used, leaving the parameters highly ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch), the resource (public robots.txt), and the output (group counts only). It does not explicitly differentiate from sibling tools, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jira-key-shapeInspect
Check a Jira issue key shape. Key discarded.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
lib-docs-hintInspect
HTTP status for a public library docs URL. Body discarded.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
memory-key-countInspect
Count keys in a JSON object. Values discarded.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
normalize-urlAInspect
Return origin, host, and path for a URL. Query and fragment are dropped.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait—dropping query and fragment—which is not present in the annotations. This adds useful transparency about how the tool processes input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two short sentences to convey the core functionality without unnecessary verbosity or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with four parameters—it only addresses the 'url' parameter implicitly. It does not explain the role of host, json, or zone, nor does it specify the output format or error behavior, leaving ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all four parameters (url, host, json, zone), giving 100% coverage. The tool description itself does not add any further meaning to the parameters, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: returning origin, host, and path for a URL, while explicitly noting that query and fragment are dropped. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus sibling tools like 'url-origin' or 'validate-json'. It simply describes the operation without contextualizing its appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
playwright-url-okInspect
Check whether a URL can be opened. No browser is launched.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
search-query-lenInspect
Count characters in a search query. Query discarded.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
status-catalogDInspect
Short catalog of common HTTP status codes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
TDQS
D1.6/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it does not. It fails to explain how the parameters (url, host, json, zone) relate to HTTP status codes or what side effects or return format the tool has.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a single short sentence, which is efficient. However, its brevity sacrifices clarity and structure, making it more cryptic than informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the four unrelated parameters and the need to understand the tool's behavior, the description is severely incomplete. It does not provide enough information for an agent to call the tool correctly or understand its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter descriptions are generic and appear copied from other contexts (e.g., 'HTTPS URL to normalize or cite'). They do not explain how each parameter is used by this specific tool, leaving the mapping between inputs and function unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase ('Short catalog of common HTTP status codes') rather than a clear action statement. It does not specify what the tool does with the inputs or what it returns, and it does not distinguish itself from the many sibling tools dealing with URLs, JSON, and timezones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No conditions, examples, or context are provided to help the agent select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
think-stepsInspect
Return a three-step thinking template. Prompt discarded.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
timezoneCInspect
Current time in a named IANA timezone.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not mention any side effects, permissions, or read-only nature. Since there are no annotations, the description carries the full burden, and it fails to disclose whether the tool performs any writes or has network dependencies beyond reading time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly communicates the core functionality. No unnecessary words or redundant information are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of three unexplained parameters creates significant context gaps. While the core purpose is clear, the tool's overall contract is confusing, and there is no output schema or description of the return format, leaving an agent unsure about expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines four parameters (url, host, json, zone), but the description only explains 'zone'. The other three parameters are entirely unexplained and appear irrelevant to the stated purpose. With only 25% schema coverage and no compensating detail, an agent cannot determine how or whether to supply url, host, or json.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description unambiguously states the tool's function: returning the current time for a named IANA timezone. It is specific enough to distinguish from sibling tools like utc-time, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as utc-time or other time-related tools. The description implies usage for timezone-specific queries, but does not state any conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
url-originDInspect
URL origin only
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
TDQS
D1.4/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses nothing about behavior: does it return a string? Does it perform network requests? What are side effects? It is entirely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise, it is under-specified. The single phrase does not earn its place because it provides no actionable information. It is not well-structured for an agent to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description is completely inadequate. An agent cannot infer when or how to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so baseline is 3. However, the description adds no meaning beyond the schema, and the parameters (host, json, zone) seem unrelated to the tool name, which is confusing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'URL origin only' does not state a verb or clear action. It doesn't indicate whether the tool extracts, validates, or transforms a URL origin. Compared to siblings like normalize-url or domain-shape, it fails to distinguish its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of the siblings. There is no mention of 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.
utc-timeCInspect
Current UTC timestamp.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
TDQS
C2.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of disclosing behavior, but it only states the core function and says nothing about side effects, errors, output format, or how the four input parameters are handled. The schema's parameters are entirely unrelated to a UTC timestamp, and the description does not disclose whether they are ignored, rejected, or repurposed. This leaves a serious behavioral gap for any agent attempting to call the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single short sentence that front-loads the core function without any filler. This is efficient and easy to scan. The terseness is slightly excessive given the complex and mismatched schema, but on the dimension of conciseness itself the description performs well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and no explanation of the tool's behavior beyond a bare one-liner, while the input schema introduces four parameters that appear irrelevant to a UTC timestamp tool. The description is far from complete enough to let an agent safely invoke the tool, especially given the confusing parameter set. Critical context such as output format, handling of the unrelated parameters, and error behavior is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage of the parameters is 100% individually (each has its own description), which sets the baseline at 3, but the tool description adds no meaning connecting url, host, json, or zone to the stated purpose of returning a UTC timestamp. The parameters appear semantically mismatched with the tool's function, and the description does nothing to resolve how or whether they influence the result. An agent cannot infer the role of any parameter in the context of this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Current UTC timestamp' does state a specific function in a compact way, satisfying the verb+resource requirement at a basic level. However, the input schema lists completely unrelated parameters (url, host, json, zone), which creates deep ambiguity about what the tool actually does when called. The stated purpose and the schema do not cohere, so an agent cannot confidently predict tool behavior from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance whatsoever about when to use this tool versus its siblings such as 'timezone' and 'iana-zones', which plausibly serve overlapping purposes. There is no stated condition, no comparison, and no exclusion criteria. An agent selecting among the eleven sibling tools receives no help from this description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate-jsonBInspect
Check whether a body is valid JSON. The body is discarded.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose that the body is discarded, implying no persistence, which is useful. However, it does not state what is returned on valid or invalid JSON, whether the operation is synchronous, or whether the unrelated url/host/zone parameters are ignored.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the core operation and the discard side-effect are front-loaded. The ambiguity of 'body' could be fixed without adding length, but the definition is appropriately sized and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too sparse. An agent cannot know what result to expect, which parameter to populate, or whether the unrelated url/host/zone parameters are ignored. The discard note is helpful, but essential invocation details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level detail beyond the schema, and 'body' is not explicitly tied to the json property, though the schema's json description repeats the discard behavior. It also does not clarify why url/host/zone appear in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('valid JSON'), and the discard note helps set expectations. However, it never names the json parameter or explains how 'body' maps to the schema, and it does not explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use validate-json versus any alternative. The description provides no context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
weather-hintInspect
Current temperature for a city via Open-Meteo.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
web-fetchInspect
HTTP status and content type for a public URL. Body discarded.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
wiki-title-okInspect
Check whether a Wikipedia title exists. Title discarded after the call.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref name; discarded after the shape check | |
| url | No | HTTPS URL to normalize or cite | |
| city | No | City name for a public weather hint; discarded after the call | |
| feed | No | Public RSS or Atom URL; titles discarded | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| path | No | File path to check; no disk access | |
| zone | No | IANA timezone name | |
| query | No | Search text; discarded after the length check |
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- Added
agent-tool-index
28 tool updates
- Added
browser-url-ok - Added
calc-eval - Changed
citation5 fields changed- added
Input schema / properties / cityAdded value: +{ + "description": "City name for a public weather hint; discarded after the call", + "type": "string" +} - added
Input schema / properties / feedAdded value: +{ + "description": "Public RSS or Atom URL; titles discarded", + "type": "string" +} - added
Input schema / properties / pathAdded value: +{ + "description": "File path to check; no disk access", + "type": "string" +} - added
Input schema / properties / queryAdded value: +{ + "description": "Search text; discarded after the length check", + "type": "string" +} - added
Input schema / properties / refAdded value: +{ + "description": "Git ref name; discarded after the shape check", + "type": "string" +}
- Changed
compatibility5 fields changed- added
Input schema / properties / cityAdded value: +{ + "description": "City name for a public weather hint; discarded after the call", + "type": "string" +} - added
Input schema / properties / feedAdded value: +{ + "description": "Public RSS or Atom URL; titles discarded", + "type": "string" +} - added
Input schema / properties / pathAdded value: +{ + "description": "File path to check; no disk access", + "type": "string" +} - added
Input schema / properties / queryAdded value: +{ + "description": "Search text; discarded after the length check", + "type": "string" +} - added
Input schema / properties / refAdded value: +{ + "description": "Git ref name; discarded after the shape check", + "type": "string" +}
- Changed
domain-shape5 fields changed- added
Input schema / properties / cityAdded value: +{ + "description": "City name for a public weather hint; discarded after the call", + "type": "string" +} - added
Input schema / properties / feedAdded value: +{ + "description": "Public RSS or Atom URL; titles discarded", + "type": "string" +} - added
Input schema / properties / pathAdded value: +{ + "description": "File path to check; no disk access", + "type": "string" +} - added
Input schema / properties / queryAdded value: +{ + "description": "Search text; discarded after the length check", + "type": "string" +} - added
Input schema / properties / refAdded value: +{ + "description": "Git ref name; discarded after the shape check", + "type": "string" +}
- Added
fetch-status - Added
figma-url-shape - Added
file-path-ok - Added
geo-hint - Added
github-repo-shape - Added
hn-front-count - Changed
iana-zones5 fields changed- added
Input schema / properties / cityAdded value: +{ + "description": "City name for a public weather hint; discarded after the call", + "type": "string" +} - added
Input schema / properties / feedAdded value: +{ + "description": "Public RSS or Atom URL; titles discarded", + "type": "string" +} - added
Input schema / properties / pathAdded value: +{ + "description": "File path to check; no disk access", + "type": "string" +} - added
Input schema / properties / queryAdded value: +{ + "description": "Search text; discarded after the length check", + "type": "string" +} - added
Input schema / properties / refAdded value: +{ + "description": "Git ref name; discarded after the shape check", + "type": "string" +}
- Changed
inspect-robots5 fields changed- added
Input schema / properties / cityAdded value: +{ + "description": "City name for a public weather hint; discarded after the call", + "type": "string" +} - added
Input schema / properties / feedAdded value: +{ + "description": "Public RSS or Atom URL; titles discarded", + "type": "string" +} - added
Input schema / properties / pathAdded value: +{ + "description": "File path to check; no disk access", + "type": "string" +} - added
Input schema / properties / queryAdded value: +{ + "description": "Search text; discarded after the length check", + "type": "string" +} - added
Input schema / properties / refAdded value: +{ + "description": "Git ref name; discarded after the shape check", + "type": "string" +}
- Added
jira-key-shape - Added
lib-docs-hint - Added
memory-key-count - Changed
normalize-url5 fields changed- added
Input schema / properties / cityAdded value: +{ + "description": "City name for a public weather hint; discarded after the call", + "type": "string" +} - added
Input schema / properties / feedAdded value: +{ + "description": "Public RSS or Atom URL; titles discarded", + "type": "string" +} - added
Input schema / properties / pathAdded value: +{ + "description": "File path to check; no disk access", + "type": "string" +} - added
Input schema / properties / queryAdded value: +{ + "description": "Search text; discarded after the length check", + "type": "string" +} - added
Input schema / properties / refAdded value: +{ + "description": "Git ref name; discarded after the shape check", + "type": "string" +}
- Added
playwright-url-ok - Added
search-query-len - Changed
status-catalog5 fields changed- added
Input schema / properties / cityAdded value: +{ + "description": "City name for a public weather hint; discarded after the call", + "type": "string" +} - added
Input schema / properties / feedAdded value: +{ + "description": "Public RSS or Atom URL; titles discarded", + "type": "string" +} - added
Input schema / properties / pathAdded value: +{ + "description": "File path to check; no disk access", + "type": "string" +} - added
Input schema / properties / queryAdded value: +{ + "description": "Search text; discarded after the length check", + "type": "string" +} - added
Input schema / properties / refAdded value: +{ + "description": "Git ref name; discarded after the shape check", + "type": "string" +}
- Added
think-steps - Changed
timezone5 fields changed- added
Input schema / properties / cityAdded value: +{ + "description": "City name for a public weather hint; discarded after the call", + "type": "string" +} - added
Input schema / properties / feedAdded value: +{ + "description": "Public RSS or Atom URL; titles discarded", + "type": "string" +} - added
Input schema / properties / pathAdded value: +{ + "description": "File path to check; no disk access", + "type": "string" +} - added
Input schema / properties / queryAdded value: +{ + "description": "Search text; discarded after the length check", + "type": "string" +} - added
Input schema / properties / refAdded value: +{ + "description": "Git ref name; discarded after the shape check", + "type": "string" +}
- Changed
url-origin5 fields changed- added
Input schema / properties / cityAdded value: +{ + "description": "City name for a public weather hint; discarded after the call", + "type": "string" +} - added
Input schema / properties / feedAdded value: +{ + "description": "Public RSS or Atom URL; titles discarded", + "type": "string" +} - added
Input schema / properties / pathAdded value: +{ + "description": "File path to check; no disk access", + "type": "string" +} - added
Input schema / properties / queryAdded value: +{ + "description": "Search text; discarded after the length check", + "type": "string" +} - added
Input schema / properties / refAdded value: +{ + "description": "Git ref name; discarded after the shape check", + "type": "string" +}
- Changed
utc-time5 fields changed- added
Input schema / properties / cityAdded value: +{ + "description": "City name for a public weather hint; discarded after the call", + "type": "string" +} - added
Input schema / properties / feedAdded value: +{ + "description": "Public RSS or Atom URL; titles discarded", + "type": "string" +} - added
Input schema / properties / pathAdded value: +{ + "description": "File path to check; no disk access", + "type": "string" +} - added
Input schema / properties / queryAdded value: +{ + "description": "Search text; discarded after the length check", + "type": "string" +} - added
Input schema / properties / refAdded value: +{ + "description": "Git ref name; discarded after the shape check", + "type": "string" +}
- Changed
validate-json5 fields changed- added
Input schema / properties / cityAdded value: +{ + "description": "City name for a public weather hint; discarded after the call", + "type": "string" +} - added
Input schema / properties / feedAdded value: +{ + "description": "Public RSS or Atom URL; titles discarded", + "type": "string" +} - added
Input schema / properties / pathAdded value: +{ + "description": "File path to check; no disk access", + "type": "string" +} - added
Input schema / properties / queryAdded value: +{ + "description": "Search text; discarded after the length check", + "type": "string" +} - added
Input schema / properties / refAdded value: +{ + "description": "Git ref name; discarded after the shape check", + "type": "string" +}
- Added
weather-hint - Added
web-fetch - Added
wiki-title-ok
11 tool updates
- First observed
citation - First observed
compatibility - First observed
domain-shape - First observed
iana-zones - First observed
inspect-robots - First observed
normalize-url - First observed
status-catalog - First observed
timezone - First observed
url-origin - First observed
utc-time - First observed
validate-json
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso 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.jsonon 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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Return origin, host, and path. Query and fragment are dropped.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables URL parsing and building from components, plus query string parsing, all without keys or online dependencies.11MIT
- AlicenseNot gradedqualityBmaintenanceRead-only observation of a single live URL: parses static HTML to report security posture, forms, links, accessibility signals, and leaks, with described fixes. SSRF-gated and safe, never executes JavaScript.93MIT
- AlicenseBqualityBmaintenanceMCP server for opn.onl, the open-source self-hostable URL shortener. Shorten links, read click analytics, generate branded QR codes, and manage links — against the hosted service or your own instance.24482MIT