A
licenseNot graded
qualityC
maintenanceEnables URL parsing and building from components, plus query string parsing, all without keys or online dependencies.
11
MIT
URL path only
Server Details
URL path 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.1/5.0
Scored across 11 tools
Disambiguation2/5
Several tools overlap significantly: normalize-url returns the path, making url-path redundant, and citation overlaps with normalize-url on host/scheme. timezone and utc-time also cover the same fundamental operation, and domain-shape adds another way to inspect URL host parts, so an agent can easily pick the wrong tool.
Naming Consistency3/5
All names use lowercase hyphenated words and are readable, but they mix noun-style names like status-catalog and iana-zones with imperative verb-noun names like inspect-robots and validate-json. There is no consistent verb_noun pattern, though the style is not chaotic.
Tool Count4/5
11 tools is within the typical well-scoped range, and most are small, single-purpose utilities. However, some tools are near-duplicates or tangential to the apparent URL/HTTP domain, so not every tool fully earns its place.
Completeness2/5
The set lacks a clear unifying domain, mixing URL inspection, timezone lookup, and JSON validation, so it is hard to define a complete surface. Even within the URL-focused subset, operations like query/fragment handling, robots rule details, and richer HTTP status information are missing.
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
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool 'returns connection methods' and that task text is discarded, but it does not disclose side effects, cost implications despite the 'pay-per-call' label, or failure/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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loads the main purpose, and contains no redundant filler. It is appropriately concise for the information it conveys.
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?
There is no output schema, no explanation of what 'connection methods' look like, and no guidance on parameter selection or error cases. Given the ambiguous parameter list and lack of annotations, the description is not complete enough for an agent to reliably invoke the 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 descriptions cover all nine parameters with individual explanations, which meets the baseline. However, the tool description does not explain how parameters like city, query, url, or json relate to the 'task' being looked up, and the statement that task text is discarded conflicts with parameters like query that are only length-checked.
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 states a specific action ('Find a public pay-per-call tool gateway') and gives examples of task types ('weather, search, scrape, or voice'), which distinguishes it from sibling tools like weather-hint or web-fetch. However, 'tool gateway' is somewhat jargon-y and the phrase 'Task text discarded' is ambiguous about what input the task text refers to.
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 examples of when to use the tool (weather, search, scrape, voice) but gives no guidance on how to select among the nine optional parameters or when not to use this tool versus a sibling. It also does not explain how the 'task' is specified, especially since no parameter is named 'task'.
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.8/5.0
Behavior2/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. However, it omits other behaviors implied by the schema (e.g., JSON validation, timezone conversion) and side effects like network requests, so transparency is incomplete.
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 brief and to the point, with a clear main function and a behavioral note. It wastes no words.
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 the full schema, as it does not explain the json and zone parameters. It also lacks context on when to use this tool relative to the sibling tools, leaving gaps in understanding the tool's overall purpose.
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 descriptions for each parameter are clear (url, host, json, zone), but the tool description only explains the url parameter. The schema covers all parameters, but the tool description fails to align with the json and zone parameters, making their role 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 primary action ('Return host, scheme, and HTTP status for a URL') with a specific resource. However, it does not explain the json and zone parameters present in the schema, leaving the full 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 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 over sibling tools like normalize-url, validate-json, or timezone. The description lacks any mention of alternative conditions or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compatibilityDInspect
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
D1.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only mentions that identifiers are not retained, but does not explain side effects, return values, or other behavioral aspects.
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 very brief and to the point, with no fluff. However, the brevity comes at the cost of clarity.
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 no output schema and the description does not explain what the result of the classification is. It is incomplete for an agent to understand how to use this tool effectively.
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?
While each parameter has a schema description, they are generic and do not explain their role in the classification process. The tool description does not add meaning to how url, host, json, and zone are used together.
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 'Show how this request is classified' is vague and does not clearly state what classification means or what the tool does. It lacks a specific verb and does not distinguish from sibling tools 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?
There is no guidance on when to use this tool versus alternatives. No conditions or scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domain-shapeCInspect
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
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose any side effects, permissions, or system impact. The phrase 'without WHOIS or data' is more about output than behavior.
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 a single concise sentence, but it lacks necessary detail about labels and parameters, making it underinformative despite being brief.
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 is simple, but the description does not explain the output format, how parameters are used, or in what scenarios it should be invoked, leaving it incomplete.
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 descriptions for parameters are generic (e.g., 'HTTPS URL to normalize or cite' for url) and do not explain how they relate to splitting a hostname, making their purpose unclear.
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 'Split a hostname into labels' and clarifies it does not include WHOIS or data. However, the term 'labels' is undefined and the parameters suggest other functions, so it is not fully precise.
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 on when to use this tool versus alternatives like normalize-url or url-path, and does not mention any conditions or context.
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-zonesCInspect
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
C2/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description offers no information about side effects, permissions, or operational behavior beyond the vague purpose, failing to carry the transparency burden.
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 short sentence with no extraneous words, achieving maximum conciseness.
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 does not explain how the four parameters are used or what the tool returns, leaving essential context missing for correct 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 parameter descriptions appear mismatched (e.g., 'json' for validation, 'url' for normalization) and do not clarify how they relate to timezone names, creating confusion rather than semantic 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 states a subject ('Common IANA timezone names') and context ('for clock calls') but lacks an explicit verb like 'lists' or 'returns', making the purpose somewhat vague though not a tautology.
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 sibling tools like 'timezone' or 'utc-time', leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inspect-robotsBInspect
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
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that only group counts are returned, but omits whether the operation is read-only, requires auth, handles errors, follows redirects, or has side effects. Minimal behavioral disclosure.
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?
Single sentence, front-loaded with the main action and limitation. No wasted words.
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 has 4 parameters and no output schema. The description does not define what 'group counts' means, the output format, or how parameters influence the fetch. Ambiguity remains around the role of json and zone, and the return structure is unspecified.
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 is 100% (each parameter has a description), so baseline is 3, but the tool description adds no meaning to the parameters and actually creates confusion: url and host plausibly relate to robots.txt, while json and zone appear unrelated to the stated purpose. The description does not clarify which parameters are used or how.
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?
Clearly states the action (fetch) and resource (public robots.txt) and specifies the output (group counts only). Distinct from sibling tools, none of which target robots.txt.
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 on when to use this tool versus alternatives. Does not mention conditions, prerequisites, or exclusions. The description is purely functional with no contextual use cases.
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-urlBInspect
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
B3.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently states the output components (origin, host, path) and explicitly mentions that query and fragment are dropped. However, it does not disclose behavior for invalid URLs or edge cases, but the core behavior is well exposed.
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 with no unnecessary words. It gets straight to the point and efficiently communicates the tool's function.
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 and no output schema. It fails to explain the roles of host, json, and zone, and does not describe the return format or any error handling. This leaves the agent without essential context for correct 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 input schema lists four parameters (url, host, json, zone), but the description only mentions URL. No explanation is given for host, json, or zone, leaving their purpose completely ambiguous. This is a severe gap in parameter semantics.
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 returns origin, host, and path for a URL, and specifies that query and fragment are dropped. This is a specific verb-resource combination and differentiates from sibling tools like url-path, which likely returns only the path.
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 url-path or validate-json. The description only explains what it does, not under what circumstances it should be selected.
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.5/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not mention any behavioral aspects such as read-only nature, side effects, or output structure. Without annotations, the agent has no information about what happens when the tool is called.
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 very short, which is concise, but it omits essential action and context. It is not overly verbose, but the brevity sacrifices necessary clarity.
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 complexity implied by the four unrelated parameters and the catalog purpose, the description is severely incomplete. It lacks any example of expected input/output, parameter usage, or the nature of the catalog.
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 parameters (url, host, json, zone) are completely unrelated to HTTP status codes, and their individual descriptions appear copied from other tools (e.g., 'JSON text to validate'). There is no explanation of how these parameters relate to the catalog.
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 'Short catalog of common HTTP status codes' uses a noun phrase rather than a verb, leaving ambiguous whether the tool lists, looks up, or returns status codes. It does not state the actual function or result.
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 or how it differs from sibling tools like validate-json or normalize-url. The description gives no context for appropriate invocation.
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.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and the description is minimal. It does not disclose the output format, whether the zone parameter is required, or what happens for invalid timezone names. It implies a read-only lookup but provides little else.
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 clear sentence and is efficient and front-loaded. However, the clutter of irrelevant schema parameters detracts from the overall structure.
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?
Given the lack of an output schema and annotations, the description is too thin. It omits output format, error behavior, and fails to reconcile the extraneous parameters, leaving an agent without enough context to confidently invoke the tool.
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 includes url, host, and json parameters with descriptions that are unrelated to timezone, suggesting a schema mismatch. Only zone matches the tool's stated purpose, and no required fields are specified, leaving confusion about which parameters are actually needed.
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 that the tool returns the current time for a named IANA timezone. However, it does not explicitly contrast with sibling tools like utc-time or iana-zones, and the schema's unrelated parameters add 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?
No guidance is provided on when to use this tool versus alternatives such as utc-time or iana-zones, nor how to supply the timezone. The description only states what the tool does, not when it should be called.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
url-pathDInspect
URL path 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.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 the full burden of disclosing behavior. The description gives no indication of side effects, data mutation, or operational characteristics beyond the cryptic 'URL path only' phrase.
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 short and front-loaded, but it sacrifices necessary detail for brevity. It is not appropriately sized because it fails to convey the tool's function or context.
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 apparent complexity (four unrelated parameters), the description is severely incomplete. There is no explanation of what the tool does, how the parameters interact, or what the expected output is.
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?
While the schema covers all parameters with descriptions, they are internally inconsistent (e.g., URL normalization, hostname, JSON validation, timezone). The descriptions confuse rather than clarify how each parameter relates to the tool's purpose, so they add little semantic value.
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 path only' is extremely vague and does not state a clear verb or resource. It is unclear whether the tool extracts, normalizes, or validates a URL path, and the presence of unrelated parameters (host, json, zone) further obscures the purpose.
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 or how it relates to alternatives. There is no mention of use cases, prerequisites, or conditions that would help an agent select this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
utc-timeDInspect
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
D1.3/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'Current UTC timestamp.' It fails to mention that it might validate JSON, normalize URLs, or use timezone parameters, leaving the agent unaware of side effects or the actual operation.
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 a single short sentence, which is concise but so under-specified that it fails to convey necessary information. There is no structure or elaboration, making it more a placeholder than a usable description.
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 four unrelated parameters and no output schema. The description does not explain the return format, how parameters affect the result, or any operational context. It is severely incomplete for an agent to call the tool correctly.
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?
While schema description coverage is 100%, the description does not link the parameters to the tool's function. The parameters (url, host, json, zone) seem irrelevant to a timestamp tool, and the description provides no explanation of how they are used, so it adds little beyond the schema's own descriptions.
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 states 'Current UTC timestamp,' but the input schema requires parameters like url, host, json, and zone, which are unrelated to returning a timestamp. This mismatch makes the purpose misleading—an agent cannot infer what the tool actually does with these inputs.
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 like timezone or iana-zones. The description gives no 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.
validate-jsonDInspect
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
D1.6/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description offers minimal behavioral detail. It states 'the body is discarded' but does not explain side effects on other parameters, network activity, or read-only guarantees.
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 very short and does not waste words, but it lacks structure and fails to convey essential information. It is concise in length but not in effective communication.
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 fundamentally incomplete. It does not explain how the parameters relate to JSON validation, what the return value is, or any edge cases. No output schema is provided.
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?
While each parameter has a schema description, three of the four (url, host, zone) have descriptions that are irrelevant to JSON validation and appear copied from other tools, actively misleading rather than clarifying.
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 core purpose is clear: checking whether a JSON body is valid. However, the presence of unrelated parameters (url, host, zone) obscures the actual scope and makes the 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 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 any alternatives. The description is a single sentence with no context about use cases or selection criteria.
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-path5 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-path - 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
- FlicenseNot gradedqualityCmaintenanceFree URL shortener with a hosted MCP server. Create, update, and bulk-create short links with custom aliases and QR codes, and read click analytics (countries, cities, devices, browsers, referrers, UTM) from Claude, Cursor, or any MCP client. Unlimited links on the free plan; read-only and write scopes are assigned per API key.1-
- 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
- AlicenseNot gradedqualityDmaintenanceEnables URL shortening using a hash-based approach with pay-per-call via x402 micropayments on Base L2.MIT