Generate IDs, QR codes, and hashes, encode values, geolocate IPs, plus gated host diagnostics.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 5 of 5 tools scored.
Each tool has a clear, distinct purpose: encoding/decoding, ID generation, QR generation, IP geolocation, and hashing. There is no overlap or ambiguity between tools.
All tools follow the consistent 'toolkit_verb_noun' pattern (e.g., toolkit_encode_value, toolkit_generate_id). The naming is uniform and predictable.
5 tools is well-scoped for a utility toolkit. Each tool serves a distinct function without being too sparse or overwhelming.
The tools cover core utilities (encoding, hashing, ID generation, QR generation, geolocation) but lack QR decoding and other common transformations. Minor gap but overall cohesive.
toolkit_encode_valuetoolkit-mcp-server: encode valueAEncode 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 |
|---|---|---|
| result | Yes | The transformed value (encoded text, or the decoded original). |
| encoding | Yes | The encoding that was applied. |
| operation | Yes | The operation that was performed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds: base64url alphabet details, url using encodeURIComponent, and that malformed decode returns a recoverable error (no silent fallback). This provides meaningful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences covering operation, encodings, error behavior. No redundant words. Front-loaded with main action.
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 output schema present, no need to describe return values. Description covers all essential aspects: inputs (raw text vs encoded), operation, encoding choices, error handling. Complete for this straightforward tool.
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 covers all 3 params at 100% with clear descriptions. Description adds general context about operation direction and encoding specifics, but does not introduce new per-parameter detail beyond schema. Some value added by overall framing, so above baseline 3.
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?
Clear verb+resource: 'encode or decode a value' across four named encodings. Distinct from siblings (generate_id, generate_qr, geolocate_ip, hash_value) which serve entirely different purposes.
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 states when to use encode vs decode and defines each encoding variant (base64, base64url, hex, URL). Notes error handling for malformed decode input. Lacks explicit comparison to sibling tools but the distinct domains make this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toolkit_generate_idtoolkit-mcp-server: generate idAMint 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 | Yes | The minted identifiers — exactly count of them, in mint order; for uuid_v7 and ulid that order is strictly increasing (sorted by creation). |
| type | Yes | The identifier format that was minted. |
| count | Yes | The number of identifiers minted (equals the requested count). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this by describing a pure generation function with no side effects. It adds critical behavioral details beyond annotations: the ids array is never truncated, uuid_v7 and ulid batches are monotonic and strictly increasing, and type selection impacts sortability. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, all substantive. First sentence states purpose and key differentiator. Second explains type parameter with format details. Third explains count and batch behavior with guarantees. Fourth cross-references another tool. No filler, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters (both with defaults, 100% schema coverage, enums for type), a rich output schema exists, and annotations cover the behavioral profile, the description is fully complete. It covers the generation source, format semantics, batch behavior guarantees, and even downstream usage. No gaps for an agent to act on.
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 baseline is 3. The description adds significant value beyond schema: it explains the cryptographic nature of generation, the specific properties of each format (time-ordered for uuid_v7, lexicographically sortable for ulid, Crockford-base32 for ulid), and batch monotonicity guarantees. It does not add syntax details but that's unnecessary given the schema already has enums and defaults.
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 mints cryptographically-random identifiers using the platform CSPRNG, explicitly distinguishing it from model-generated values. It specifies the verb 'mint' and the resource 'cryptographically-random identifiers', and the sibling tools (encode, generate QR, geolocate, hash) are all clearly different in purpose.
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 explains when to use this tool (when IDs must be unpredictable) versus not (model-generated values), and even provides cross-reference to toolkit_generate_qr for the next step. It gives clear context for format selection (uuid_v4, uuid_v7, ulid) and batch behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toolkit_generate_qrtoolkit-mcp-server: generate QR codeAEncode 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 |
|---|---|---|
| format | Yes | The format that was produced. |
| content | Yes | The QR artifact: SVG markup, a terminal-renderable string, or base64 PNG bytes for png_base64. |
| version | Yes | 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 readOnlyHint and idempotentHint annotations. It discloses the different output formats (svg, png_base64, terminal), the error-correction trade-off, pixel size limits for png_base64 (2048 px side), the version range, and typed error conditions (data_too_large, raster_too_large). This richly informs the agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph that efficiently conveys all necessary information. Every sentence adds value. It is front-loaded with the main purpose. However, it could be slightly improved by using bullet points or separate sections for readability, though it remains concise and 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?
Given the tool has an output schema, the description does not need to explain return values. It covers all parameters, format options, error cases, limits, and version semantics. The description is complete for the complexity of the tool (5 parameters, 2 enums, dynamic constraints).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the relationship between scale, margin, and pixel size for png_base64, the error-correction levels' impact on data capacity, and the version output. It also clarifies that scale is ignored for terminal output. This is more than the schema alone 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 clearly states 'Encode text or a URL into a QR code.' This is a specific verb+resource (encode into QR code) that uniquely identifies the tool's purpose. It distinguishes itself from sibling tools (generate_id, encode_value, etc.) without overlap.
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 does not explicitly state when to use this tool vs. alternatives, but the context is clear: it is for QR code generation. It provides concrete usage examples (links, generated IDs, any string) and mentions error cases, which helps an agent decide. However, direct 'when-not' guidance is absent, so it's not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toolkit_geolocate_iptoolkit-mcp-server: geolocate IPAResolve 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. |
| 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 | Yes | The provider that answered the lookup, e.g. "ip-api". |
| target | Yes | 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 | Yes | 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?
The description goes far beyond the annotations (readOnlyHint, openWorldHint, idempotentHint) by detailing SSRF safety, best-effort nature, provider-bounded accuracy, handling of absent fields (reported as unknown, never invented), and the significance of proxy/hosting/mobile flags. It also explains that hostnames are DNS-resolved and that private addresses are rejected. 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 relatively long but every sentence adds unique value (purpose, parameter behavior, safety, limitations, output interpretation). It is front-loaded with the main purpose. While it could be slightly tighter, it is well-structured and not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown but present), the description does not need to detail return values. It covers input behavior, security, accuracy limitations, quality flag interpretation, and error conditions (private address rejection). This is complete for a single-parameter lookup tool with rich metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'target', which already describes accepted formats. The description adds value by explaining that hostnames are DNS-resolved first and the resolved IP is echoed in the output, and that private/reserved addresses are rejected. This provides meaning beyond the schema structure.
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 that the tool resolves an IP address or hostname to geographic and network metadata, listing specific fields (country, region, city, lat/lng, ASN, organization, timezone, quality flags). This is a specific verb-resource combination that distinguishes it from sibling tools (encode, generate IDs, hash, QR) which are unrelated.
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 the tool (geolocation lookup) and includes important caveats: private addresses are rejected, accuracy is best-effort, results may be unreliable for VPNs/proxies. It also states that the tool is SSRF-free and safe to expose. However, it does not explicitly contrast with alternative tools, though the sibling tools are unrelated enough that this is not a major gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toolkit_hash_valuetoolkit-mcp-server: hash valueAGenerate 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 |
|---|---|---|
| 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 | Yes | The algorithm used. |
| operation | Yes | 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 declare readOnlyHint=true and idempotentHint=true, so the agent knows the tool is safe and idempotent. The description adds value by disclosing that 'compare' is timing-safe ('constant-time-check value against expected digest — compare is timing-safe and avoids manual string equality checks') and that md5/sha1 are for compatibility only. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 4 sentences, well-structured and front-loaded with the core purpose. Each sentence adds value: operation modes, algorithm security warnings, input encoding utility, and a canonical use case. Slightly longer than necessary but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 2 operations, security nuances), 100% schema coverage, and the presence of an output schema (which explains return values), the description is complete. It covers all behavioral aspects: dual modes, algorithm security, encoding flexibility, and a concrete use case. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and provides solid defaults and enum explanations. The description adds additional meaning: it explains why compare is preferred over manual equality checks (timing safety), how inputEncoding helps avoid decode round-trips for binary data, and that sha256/sha512 are secure while md5/sha1 are not. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('generate' and 'verify') and resources ('cryptographic digest', 'value'), clearly distinguishing the tool's two operations. It differentiates from siblings by focusing on hashing and comparison, which none of the listed sibling tools (encode, generate id, generate qr, geolocate ip) perform.
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 each operation ('Set operation to "generate"... or "compare"...'), warns against using md5/sha1 for security purposes ('must not be used for passwords, signatures'), and provides canonical use cases ('matching a download against a vendor-published checksum'). It implicitly distinguishes from siblings by covering hashing, which they do not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
Sign in to create a connector for this server.