Generate IDs, QR codes, and hashes, encode values, geolocate IPs, plus gated host diagnostics.
Encode or decode a value across base64, base64url, hex, or URL (percent) encoding, in either direction. Set operation to "encode" to transform raw UTF-8 text into the chosen encoding, or "decode" to recover the original text from an encoded value. base64url uses the URL-safe alphabet (- and _ instead of + and /); url applies encodeURIComponent / decodeURIComponent. Decoding a value that is malformed for the chosen encoding is reported as a recoverable error, not a silent best-effort.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The value to transform — raw text for encode, an encoded string for decode. | |
| encoding | Yes | The encoding to apply: base64, URL-safe base64url, hex, or URL percent-encoding. | |
| operation | Yes | "encode" transforms text into the encoding; "decode" recovers text from an encoded value. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| result | No | The transformed value (encoded text, or the decoded original). |
| encoding | No | The encoding that was applied. |
| operation | No | The operation that was performed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and idempotentHint=true, covering safety. The description adds value by disclosing that decoding malformed input returns a recoverable error rather than silent best-effort (important behavioral detail), and explains how url uses encodeURIComponent/decodeURIComponent. It doesn't contradict annotations; readOnly hint is consistent with a transform tool. Missing specifics like output format or edge cases (empty string, whitespace), but the error disclosure is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff: the first states the full capability, the second explains the two operations and specific encodings, the third discloses error behavior. All sentences earn their place, and the most important info (what it does, how to invoke) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, simple enum values), the description is complete enough. It covers the operation semantics, encoding specifics, and error handling. It does not mention that output is likely a string, but an output schema exists, so return values are covered. Minor gap: doesn't explicitly state that encode assumes raw UTF-8 text input, but the description says 'raw UTF-8 text' for encode, so it's covered. Overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: each parameter (value, encoding, operation) has a clear description and encoding has enum with meanings. The description reinforces parameter semantics and adds context for base64url vs url and error handling, but doesn't add much beyond the schema. Baseline 3 is appropriate because schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool encodes/decodes values across four specific encodings, in either direction, and details the exact operation semantics ('encode' vs 'decode'). It distinguishes it from siblings like toolkit_hash_value (hash vs encode) and toolkit_generate_id (generation vs transformation). Purpose is specific with verb, resource, and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use encodings: base64url for URL-safe contexts, url for percent-encoding, and specifies encodeURIComponent/decodeURIComponent semantics. It doesn't explicitly exclude cases where this tool should NOT be used or mention alternatives like hash for one-way transforms, but it gives sufficient context for an agent to decide based on the operation. Slight gap in not contrasting with hash_value or other transforms, but clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mint cryptographically-random identifiers using the platform CSPRNG — the correct source for IDs that must be unpredictable, unlike model-generated values. type selects the format: uuid_v4 (random, the default), uuid_v7 (time-ordered, sortable by creation), or ulid (26-char Crockford-base32, lexicographically sortable). Set count to mint a batch in one call (up to 1000); the returned ids array always contains exactly count values and is never truncated. For uuid_v7 and ulid, a batch is monotonic — strictly increasing even within the same millisecond — so the ids array stays in sorted creation order. IDs from this tool feed into toolkit_generate_qr (pass ids[0] as data) to create a scannable code.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Identifier format: uuid_v4 (random), uuid_v7 (time-ordered), or ulid (sortable Crockford-base32). | uuid_v4 |
| count | No | How many identifiers to mint (1–1000). The full batch is always returned. |
| Name | Required | Description |
|---|---|---|
| ids | No | The minted identifiers — exactly count of them, in mint order; for uuid_v7 and ulid that order is strictly increasing (sorted by creation). |
| type | No | The identifier format that was minted. |
| count | No | The number of identifiers minted (equals the requested count). |
| error | No | Present when the call failed. Absent on success. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the readOnlyHint annotation: CSPRNG usage, strict batch semantics (exactly count, never truncated), monotonic ordering for uuid_v7 and ulid, and sortability properties. This is exactly the kind of behavioral context that helps an agent reason about results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but not bloated: every sentence contributes either a purpose statement, parameter nuance, behavioral guarantee, or integration hint. The primary purpose is front-loaded before implementation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a two-parameter tool with a readOnly annotation and an output schema. It covers identity, randomness source, format choices, batch limits, ordering guarantees, and a downstream usage example — nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though the schema already documents both parameters at 100% coverage, the description adds meaningful semantics: uuid_v7 is time-ordered, ulid is 26-char Crockford-base32, and count produces an exactly-sized sorted batch. It enriches the schema rather than repeating it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('mint') and resource ('cryptographically-random identifiers') with an explicit correctness claim about the CSPRNG source. It clearly distinguishes the tool's scope from sibling tools and explains the type variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames the tool as the correct source for unpredictable IDs and contrasts it with model-generated values, which is a direct when-to-use/when-not-to-use signal. It also describes type selection, batch counts, and a concrete downstream use with toolkit_generate_qr.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode text or a URL into a QR code. data is the content to encode (a link, a generated identifier such as toolkit_generate_id's ids[0], or any string). format selects the output: svg returns inline SVG markup, png_base64 returns base64-encoded PNG bytes (with mimeType and byteLength), and terminal returns a block of Unicode block characters renderable in a monospace terminal. errorCorrection (L/M/Q/H) trades data capacity for damage tolerance, margin sets the quiet-zone width, and scale sets pixels per module for raster output. The returned version (1–40) reflects how dense the encoded data is. png_base64 renders (modules + 2 × margin) × scale pixels per side and rejects anything past 2048 px with a typed raster_too_large error, so a dense symbol needs a lower scale; svg carries no such limit.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The text or URL to encode. 2953 is the absolute ceiling (QR version 40, level L, byte mode); usable capacity drops at higher errorCorrection levels, so over-capacity data is rejected with a typed data_too_large error rather than a generic failure. | |
| scale | No | Pixels per module for raster (png_base64) output. Ignored for terminal. png_base64 also bounds the whole image at 2048 px per side, so a dense symbol or a wide margin admits a lower scale than 32. | |
| format | No | Output format: svg markup, png_base64 (raster bytes), or a terminal-renderable string. | svg |
| margin | No | Quiet-zone width in modules around the symbol. The spec recommends 4. | |
| errorCorrection | No | Error-correction level: L (~7% recoverable) to H (~30%). Higher tolerance lowers data capacity. | M |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| format | No | The format that was produced. |
| content | No | The QR artifact: SVG markup, a terminal-renderable string, or base64 PNG bytes for png_base64. |
| version | No | QR symbol version (1–40); higher versions hold denser data and indicate denser content. |
| mimeType | No | MIME type of content for image formats. Absent for the terminal format. |
| byteLength | No | Decoded byte size of the PNG. Present only for png_base64. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (readOnly, idempotent) by disclosing return formats (SVG markup, base64 PNG with mimeType/byteLength, terminal block), pixel size limits (2048 px with typed raster_too_large error), data capacity ceiling (2953 with typed data_too_large error), and the meaning of the returned version. It even explains how scale interplays with margins and density. This is rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but slightly wordy; it packs many details into one paragraph. It is front-loaded with purpose and then methodically covers each parameter and constraint. Given the tool's complexity (5 parameters, error cases, format-specific limits), the length is justified, though it could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers every parameter's effect, document return formats, error behaviors, and physical limits. An output schema also exists for the result structure, so the absence of explicit return-field documentation is acceptable. Nothing an agent needs to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with detailed descriptions for every parameter, so the baseline is 3. The description repeats and slightly elaborates (e.g., explaining that png_base64 renders (modules + 2×margin)×scale pixels and that svg has no size limit), but it does not add fundamentally new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource pair ('Encode text or a URL into a QR code') and then details the output formats. It distinguishes the tool from siblings by focusing on QR generation, which is distinct from the other encode/hash/id tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and how to control output, but it never explicitly says when to choose this tool over alternatives. Sibling tools like toolkit_encode_value are not mentioned, so an agent gets no direct comparison or exclusion guidance. However, the purpose is specific enough that usage is inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a public IP address (or hostname) to geographic and network metadata: country, region, city, latitude/longitude, the owning ASN and organization, timezone, and the proxy/hosting/mobile quality flags. target accepts an IPv4/IPv6 address or a hostname — a hostname is DNS-resolved first and the resolvedIp field echoes which IP was actually located. The provider is called directly (never the target), so this is SSRF-free and safe to expose anywhere. Results are best-effort and provider-bounded: VPNs, proxies, mobile NAT, and anycast all defeat IP-to-location, accuracy is city-level at best, and many fields can be absent for reserved or thinly-documented ranges — absent fields are reported as unknown, never invented. Read proxy, hosting, and mobile before trusting the coordinates: a true on any of them means the location describes infrastructure, not the user. Private/reserved addresses have no public geolocation and are rejected. The source field names which provider answered.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | A public IPv4/IPv6 address or a hostname (e.g. "8.8.8.8" or "example.com"). |
| Name | Required | Description |
|---|---|---|
| asn | No | Autonomous System number, e.g. "AS15169". Absent on providers that omit it. |
| org | No | Owning organization or ISP, e.g. "Google LLC". Absent when unknown. |
| city | No | City name. Absent when unknown. |
| error | No | Present when the call failed. Absent on success. |
| proxy | No | True when the address is a known proxy, VPN, or Tor exit — the location describes the exit node, not the user. Absent when the provider does not report it. |
| mobile | No | True when the address belongs to a mobile carrier network, where NAT can place the location far from the device. Absent when unreported. |
| region | No | Region or state name. Absent when unknown. |
| source | No | The provider that answered the lookup, e.g. "ip-api". |
| target | No | The target as supplied (IP or hostname). |
| country | No | Country name. Absent when the provider does not report it. |
| hosting | No | True when the address belongs to a hosting or datacenter network, so the location is a facility rather than a person. Absent when unreported. |
| latitude | No | Latitude in decimal degrees. Absent when unknown. |
| timezone | No | IANA timezone, e.g. "America/Los_Angeles". Absent when unknown. |
| longitude | No | Longitude in decimal degrees. Absent when unknown. |
| resolvedIp | No | The IP that was actually located (a supplied hostname is resolved to this first). |
| countryCode | No | ISO 3166-1 alpha-2 country code. Absent when unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds substantial behavioral context beyond annotations: it explains the SSRF-free nature, best-effort results with provider-bounded accuracy, how absent fields are reported (unknown, never invented), the meaning of proxy/hosting/mobile flags, and that private/reserved addresses are rejected. It also clarifies hostname resolution behavior and the resolvedIp echo.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, front-loading the core purpose and then adding critical caveats. Every sentence adds value: the first sentence states the purpose, the second explains hostname handling, the third addresses safety, the fourth covers accuracy limitations, the fifth warns about proxy flags, and the sixth covers rejection of private addresses. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple input formats, provider-dependent behavior, quality flags, error conditions), the description is remarkably complete. It covers input handling, output semantics (resolvedIp, source field), limitations, safety, and error cases. The output schema exists, so return values are documented elsewhere, but the description still explains the meaning of key fields (proxy/hosting/mobile flags) which is essential for correct interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the target parameter well. The description adds value by explaining that hostnames are DNS-resolved first and that the resolvedIp field echoes the actual IP located, which is not in the schema. It also clarifies the accepted formats (IPv4/IPv6/hostname) beyond the schema's patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a public IP or hostname to geographic and network metadata, listing specific fields (country, region, city, lat/long, ASN, organization, timezone, quality flags). It distinguishes itself from siblings (encode, generate_id, generate_qr, hash_value) by its unique purpose of IP geolocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (resolving IPs/hostnames to location) and provides clear exclusions: private/reserved addresses are rejected, and it warns about VPNs/proxies/mobile NAT defeating accuracy. It also implicitly distinguishes from siblings by its specific domain, and notes the provider is called directly (SSRF-free) making it safe to expose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a cryptographic digest of a value, or verify a value against an expected digest. Set operation to "generate" for a lowercase-hex digest, or "compare" to constant-time-check value against the expected digest — compare is timing-safe and avoids manual string equality checks. Algorithm defaults to sha256; sha512 is also secure, while md5 and sha1 are exposed for checksum and file-integrity compatibility ONLY and must not be used for passwords, signatures, or any security purpose. inputEncoding controls how value and expected are read before hashing (utf8 default, or hex/base64 for raw binary data) so binary blobs need no decode round-trip. The canonical use is matching a download against a vendor-published checksum.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The data to hash, interpreted per inputEncoding (raw text by default). | |
| expected | No | The expected lowercase-hex digest to compare against. Required when operation is "compare". | |
| algorithm | No | Digest algorithm. sha256 (default) or sha512 for security; md5/sha1 are checksum/compat only — not for security. | sha256 |
| operation | No | "generate" produces a digest; "compare" constant-time-checks value against expected. | generate |
| inputEncoding | No | How value (and expected's pre-image, when relevant) is decoded before hashing: utf8 text, hex, or base64. | utf8 |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| digest | No | Lowercase-hex digest of value. Present for operation "generate". |
| matches | No | Constant-time equality of the computed digest against expected. Present for operation "compare". |
| algorithm | No | The algorithm used. |
| operation | No | The operation performed. |
| lengthInBytes | No | Digest size in bytes (32 for sha256, 64 for sha512, 20 for sha1, 16 for md5). Present for "generate". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly and idempotent, so the description adds valuable behavioral detail beyond that: the constant-time comparison (timing-safe), the security implications of different algorithms, and how inputEncoding handles binary data without decode round-trips. It also explains the output format (lowercase-hex) and the expected format for comparison. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-structured: it opens with the overall purpose, then covers operation, algorithm, encoding, and ends with a canonical use case. Every sentence adds functional value and there is no filler. Slightly longer than necessary, but each clause earns its place; front-loading the purpose is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present (not shown but declared), the description needn't detail return values. It covers all parameters, explains the two operation modes, provides algorithm security guidance, clarifies input encoding semantics, and gives a concrete use case. Nothing an agent needs to call this tool correctly — including subtle security caveats — is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 5 parameters at 100% with clear per-parameter descriptions. The description adds meaning beyond the schema by explaining why inputEncoding is useful (no decode round-trip for binary), and by framing the operation parameter as a choice between generating and constant-time comparing. It also reinforces algorithm security profiles, which is helpful context beyond the enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool generates a cryptographic digest or verifies a value against an expected digest — a specific verb and resource. It clearly differentiates itself from encoding/generation tools by focusing on hashing and verification, and even mentions a canonical use case (checksum matching). This unambiguously tells an agent what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives strong context: explains the two operations (generate vs compare), highlights the timing-safe compare, and explicitly warns that md5/sha1 must not be used for security purposes. Though it does not name alternative tools like toolkit_encode_value, it provides clear when-to-use and when-not-to-use guidance within the tool itself, which is sufficient for a standalone utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
toolkit_encode_value6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "encoding",
+ "operation",
+ "result"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `decode_failed`: operation is \"decode\" but value is malformed for the chosen encoding. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "decode_failed"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "encoding",
- "operation",
- "result"
-]toolkit_generate_id6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "type",
+ "ids",
+ "count"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode.",
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "type",
- "ids",
- "count"
-]toolkit_generate_qr6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "format",
+ "content",
+ "version"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `data_too_large`: data exceeds the QR capacity for the chosen errorCorrection level and encoding mode. `raster_too_large`: format is png_base64 and (modules + 2 × margin) × scale exceeds the pixel budget. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "data_too_large",
+ "raster_too_large"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "format",
- "content",
- "version"
-]toolkit_geolocate_ip6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "target",
+ "resolvedIp",
+ "source"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `unresolvable_host`: A hostname target failed DNS resolution. `private_target`: The target resolves to a private/reserved IP with no public geolocation. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "unresolvable_host",
+ "private_target"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "target",
- "resolvedIp",
- "source"
-]toolkit_hash_value6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "algorithm",
+ "operation"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `missing_expected`: operation is \"compare\" but no expected digest was supplied. `expected_length_mismatch`: The expected digest length does not match the algorithm, so compare would always fail. `invalid_input_encoding`: value is not valid for the declared inputEncoding (e.g. non-hex characters with inputEncoding \"hex\"). Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "missing_expected",
+ "expected_length_mismatch",
+ "invalid_input_encoding"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "algorithm",
- "operation"
-]toolkit_generate_qr1 field changedInput schema / properties / scale / descriptionPrevious value: -"Pixels per module for raster (png_base64) output. Ignored for terminal."New value: +"Pixels per module for raster (png_base64) output. Ignored for terminal. png_base64 also bounds the whole image at 2048 px per side, so a dense symbol or a wide margin admits a lower scale than 32."toolkit_encode_valuetoolkit_generate_idtoolkit_generate_qrtoolkit_geolocate_iptoolkit_hash_valueClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Utility tools for AI agents: hashing, text stats, validation, DNS, currency, GEO audits.
Exact hashing, base64/hex/URL encoding, JWT decoding and UUIDs for AI agents. No auth required.
Developer toolkit: UUID, timestamp, unit conversion, JSON tools, and QR code (SVG). Free.
49 developer tools via MCP: DNS, WHOIS, IP lookup, JWT, hashing, QR, and more.
Add one secure layer between your agents and this server.
Each tool targets a distinct function: encoding, ID generation, QR generation, IP geolocation, and hashing. No two tools could plausibly be selected for the same task, and the descriptions reinforce these boundaries.
All tools follow the exact toolkit_<verb>_<noun> snake_case pattern with action verbs (encode, generate, geolocate, hash). There are no mixed conventions or vague names.
Five tools is within the ideal 3-15 range and each tool carries substantial functionality through multiple formats, algorithms, or operations. No tool feels like filler, and the set avoids bloat.
Each individual tool is internally comprehensive—encode covers four encodings in both directions, generate_id covers common ID formats, and hash covers generate/compare. As a general 'toolkit' it omits some common utility categories, but there are no dead ends or missing operations within the five advertised functions.
