Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@buildutilities-mcp Generate a random UUID v4 for me"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Deterministic developer utilities as MCP tools. Runs entirely on your machine — no network calls, no telemetry, no API key, no account.
From the people who make buildutilities.com.
A language model is already good at most text manipulation, and a tool it does not need is a tool that only burns its context window. So this server deliberately covers the operations models are genuinely bad at:
Randomness. A model cannot generate it. Ask one for a UUID or a password and you get something drawn from its training distribution — repeatable between sessions, sometimes lifted verbatim from a public code sample. For anything security-adjacent that is a real defect.
Exact digests and bytes. It cannot compute a SHA-256, so it invents a plausible one. Base64 of anything it has not effectively memorised comes back quietly corrupted.
Running a regex. Asked whether a pattern matches, a model reasons about the pattern instead of executing it, so it reports matches that do not exist and misses ones that do.
Precise counting over long text, and calendar arithmetic across timezones and DST — including "when does this cron next fire", which models answer confidently and wrongly.
Everything here is a pure function: same arguments, same answer, no state, no side effects.
Related MCP server: mcp-server-devutils
Claude Code
claude mcp add buildutilities -- npx -y buildutilities-mcpClaude Desktop, Cursor, or any client with a JSON config
{
"mcpServers": {
"buildutilities": {
"command": "npx",
"args": ["-y", "buildutilities-mcp"]
}
}
}Requires Node 18 or newer. To see the tool list without an MCP client:
npx -y buildutilities-mcp --helpRandomness a model cannot fake
Tool | What it does |
| Cryptographically random UUID v4s, via the OS CSPRNG. |
| Random password, guaranteeing at least one character from every enabled set. |
| Random token for API keys, session ids, nonces and salts — hex, base64url or alphanumeric. |
Exact bytes and digests
Tool | What it does |
| Encode to Base64, standard or URL-safe. |
| Decode Base64, reporting invalid input rather than returning mojibake. |
| Percent-encode, in component or full-URI mode. |
| Decode percent-encoding, reporting malformed input. |
| md5, sha1, sha256, sha384 or sha512 digest, with a warning on the broken ones. |
| HMAC a message with a secret — webhook and request signing. |
| Constant-time check of a message against an expected signature. |
Calendar arithmetic
Tool | What it does |
| Unix epoch to human time in any IANA timezone; auto-detects seconds vs milliseconds. |
| Next run times for a 5-field cron expression, in a timezone. |
Documents, tokens, diffs
Tool | What it does |
| Pretty-print or minify JSON exactly, with line and column on a parse error. |
| Read a JWT's header, payload and expiry. Decodes only — never verifies. |
| Line-by-line diff, marking what was added and removed. |
Run it, do not predict it
Tool | What it does |
| Actually execute a pattern and return every match with its index and capture groups. |
| Escape a string for use as a regex literal. |
| Exact character, word, line, sentence, paragraph and byte counts. |
| URL-safe slug, transliterating accents. |
| Exact WCAG 2.2 contrast ratio and which AA/AAA thresholds it passes. |
It does not verify JWT signatures. decode_jwt reads a token; it cannot tell you the token is genuine. Never trust its output as authentication.
md5 and sha1 are included but not secure. They are there for checksums and legacy interop, and the tool says so in its output.
Cron is standard 5-field only. Non-standard syntax (L, W, #, ?) is refused rather than guessed at, because a plausible wrong schedule is worse than an error. Times inside a DST spring-forward gap are still listed; real cron implementations disagree about that case.
Three tests in test/no-network.test.ts enforce it, so it cannot quietly stop being true:
No source file imports node:net, http, https, dns, tls or dgram, or calls fetch.
Running every tool in the catalogue loads no network-related native binding.
The package declares exactly two runtime dependencies (the MCP SDK and zod); adding a third fails the suite and forces a re-check.
npm test # 48 testsMIT
Exact counts for a text: characters, words, lines, sentences, paragraphs, bytes. Use this rather than estimating — counting long text is a classic model failure. Web version: https://buildutilities.com/word-counter
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the specific list of counts returned and emphasizes the 'exact' nature, which is beyond annotations. It does not mention edge cases like encoding or how words/sentences are defined, but given the annotations cover safety and the tool is simple, this is sufficient. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences with zero waste. The first sentence front-loads the purpose and output list; the second adds a usage rationale. The web link is extra but not distracting. Every sentence earns its place, and the structure is ideal for quick parsing by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and simple annotations, the description is largely complete. It lists all output types and provides a usage guideline. It does not describe the return format (e.g., JSON structure), but since there is no output schema, the agent must infer that from the listed counts. This is acceptable given the tool's simplicity, though a note about the return shape would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for the 'text' parameter (only type: string). The description says 'for a text' but adds no meaning beyond what the schema already provides. It does not clarify encoding, length limits, or formatting expectations. Since schema coverage is 0%, the description should compensate, but it merely restates the parameter name. This is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Exact counts') and resource ('a text'), and enumerates the exact metrics (characters, words, lines, sentences, paragraphs, bytes). It is immediately clear what the tool does and distinguishes it from siblings like diff_text or slugify, which serve different purposes. The explicit list of outputs leaves no ambiguity about the tool's function.
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 provides a clear usage directive: 'Use this rather than estimating — counting long text is a classic model failure.' This tells the agent when to prefer this tool (exact counting over estimation). It does not explicitly name alternatives or when-not-to-use conditions, but the directive is specific enough for most contexts. The guidance is actionable and relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode Base64 (standard or URL-safe) back to text. Reports whether the input was valid rather than returning mojibake. Web version: https://buildutilities.com/base64-codec
| Name | Required | Description | Default |
|---|---|---|---|
| encoded | Yes | Base64 or base64url input |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral value by stating that it reports whether the input was valid rather than returning mojibake, and it mentions URL-safe support. This goes beyond annotations and helps the agent understand error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and validity behavior. It includes a web link which is extra but not harmful. No unnecessary verbiage; 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?
For a single-parameter tool with annotations covering safety, the description covers the input format, output (text), and validity reporting. It does not detail the exact return structure (e.g., whether it returns an error object), but the statement about reporting validity implies that. Minor gap, but overall adequate for an agent to call it correctly.
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 already documents the single 'encoded' parameter with description 'Base64 or base64url input', achieving 100% coverage. The description restates this by mentioning 'standard or URL-safe' but adds no new meaning beyond the schema. Per the baseline, a 3 is appropriate when the 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 verb 'Decode', the resource 'Base64', and the output 'text'. It also distinguishes from siblings by mentioning both standard and URL-safe variants, and the validity-reporting behavior. The purpose is unambiguous and differentiates from encode/decode tools.
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 provides clear context (decoding Base64 back to text) but does not explicitly name alternative tools or state when not to use it. It implies usage for any Base64-encoded string, which is sufficient for this simple tool. No exclusions or comparisons are given, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode text to Base64. Set urlSafe for the URL/filename-safe alphabet (-_ instead of +/, no padding). Web version: https://buildutilities.com/base64-codec
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to encode | |
| urlSafe | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral detail about the urlSafe option (different alphabet and no padding), which goes beyond the annotations. It does not mention error cases, but for a pure encoding function that is acceptable.
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?
Two sentences deliver the core purpose and the key parameter variation, with a helpful web link appended. The main purpose is front-loaded, and there is zero wasted wording. It is concise without sacrificing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple encoding tool with two parameters, the description fully covers what an agent needs to call it correctly: the operation, the optional behavior, and a reference. No output schema exists, but the return value (encoded string) is self-evident. Nothing essential 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 'text' with a description but leaves 'urlSafe' undocumented (only a default). The description explicitly explains urlSafe's effect (URL/filename-safe alphabet and no padding), compensating for the schema gap. For 'text', the description adds no new meaning beyond the schema, but overall it provides meaningful parameter context.
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 precise verb and resource: 'Encode text to Base64.' It also distinguishes the URL-safe variant, which differentiates it from base64_decode and other encoding tools. The purpose is unambiguous and immediately actionable.
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 clearly states what the tool does but does not explicitly compare it to alternatives like url_encode or base64_decode. The conditional 'Set urlSafe for the URL/filename-safe alphabet' gives usage guidance for the parameter, and the overall context implies when to use it, but it lacks an explicit 'use this instead of X' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the exact WCAG 2.2 contrast ratio between two colours and report which AA/AAA thresholds it passes. This is a specific formula, not a judgement call — do not estimate it. Web version: https://buildutilities.com/color-contrast-checker
| Name | Required | Description | Default |
|---|---|---|---|
| background | Yes | Hex colour, e.g. #ffffff | |
| foreground | Yes | Hex colour, e.g. #1a1a1a |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds valuable behavioral context: it is deterministic ('specific formula'), not a judgement call, and outputs threshold status. This goes beyond annotations without contradicting them.
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?
Two sentences, front-loaded with the core purpose and result. The caution about not estimating is concise, and the web link is a minor extra. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deterministic tool with two well-documented params and no output schema, the description adequately conveys the return behavior ('report which AA/AAA thresholds it passes'). Combined with annotations covering safety, an agent has all needed information to call it correctly.
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% with clear descriptions for both params ('Hex colour, e.g. #ffffff'). The description adds no additional parameter-specific details beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb 'Compute' with a precise resource 'WCAG 2.2 contrast ratio between two colours' and the outcome 'report which AA/AAA thresholds it passes'. This clearly distinguishes it from all sibling utilities (generators, encoders, hash functions) 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 implies when to use it: when an exact ratio is needed, and explicitly cautions 'do not estimate it'. It doesn't name alternatives, but no sibling performs contrast checks, so this is acceptable. It could state 'use when verifying accessibility compliance' but the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between Unix epoch and human-readable time, in any IANA timezone. Auto-detects seconds vs milliseconds. Use this rather than doing the arithmetic in your head. Web version: https://buildutilities.com/timestamp-converter
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Epoch seconds/ms, an ISO 8601 string, or "now" | |
| timeZone | No | IANA timezone, e.g. "America/New_York" | UTC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, so the description correctly avoids repeating that. It adds valuable behavioral detail beyond annotations: auto-detection of seconds vs milliseconds, acceptance of ISO 8601 strings and 'now', and IANA timezone support. These are not covered by annotations and help the agent predict 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 four short sentences with no wasted words. The core purpose and key capability are front-loaded, followed by a usage tip and an optional web link. Every sentence contributes value; the web link is extraneous but does not detract from clarity or efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple conversion utility with no output schema, the description adequately covers the tool's function, input flexibility, and timezone handling. It does not explicitly state the output format (e.g., the exact human-readable representation), but for a well-known operation like timestamp conversion this is inferable. Combined with the complete input schema and annotations, the description is sufficiently complete for an agent to call it correctly.
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 both parameters: 'value' is described as 'Epoch seconds/ms, an ISO 8601 string, or "now"' and timeZone as 'IANA timezone, e.g. "America/New_York"'. The description adds only the auto-detection nuance, which is a behavior rather than parameter semantics. Since the schema already fully documents the inputs, the description contributes minimal extra meaning, justifying the baseline score of 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?
The description states a specific action (convert), the resource (Unix epoch and human-readable time), and a key capability (auto-detects seconds vs milliseconds). It clearly distinguishes this from sibling utilities like generate_uuid or base64_encode, which serve entirely different purposes. The IANA timezone mention further specifies 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 explicitly advises 'Use this rather than doing the arithmetic in your head,' providing a clear reason to choose this tool over manual calculation. It does not explicitly list when not to use it or name alternatives, but among the siblings none are alternatives for conversion, so the guidance is sufficient for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a standard 5-field cron expression and list its next run times in a timezone. Handles the Vixie rule that day-of-month and day-of-week are OR'd when both are restricted — the case models most often get wrong. Rejects non-standard syntax (L, W, #) rather than guessing. Web version: https://buildutilities.com/cron-expression-generator
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| timeZone | No | UTC | |
| expression | Yes | e.g. "*/15 9-17 * * mon-fri" or "@daily" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already declare readOnlyHint and idempotentHint, the description adds valuable behavioral detail: the Vixie day-of-month/day-of-week OR rule and explicit rejection of non-standard syntax like L, W, and #. This goes well beyond the structured annotations and helps an agent predict edge-case 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 compact and front-loaded: purpose first, then the key edge-case rule, then the syntax rejection policy. The trailing web link is not necessary for tool invocation, so it slightly dilutes conciseness, but overall the text is efficient and well organized.
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 the input format, timezone handling, the most important cron parsing subtlety, and error behavior for unsupported syntax. It does not explicitly describe the return shape, but no output schema exists and 'list its next run times' is reasonably clear. There is a minor internal inconsistency: it says 'standard 5-field cron expression' yet the schema example includes '@daily', which is not a 5-field expression.
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 only 33%, so the description must compensate. It explains the expression and timezone semantics, but it does not mention the count parameter at all. Count is partially inferable from the schema's default and bounds, but the description adds nothing about how many runs will be returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Parse a standard 5-field cron expression and list its next run times in a timezone.' This clearly distinguishes the tool from all sibling utilities, which are unrelated generation, encoding, hashing, and formatting tools.
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 implies when to use the tool: whenever an agent needs to compute upcoming cron schedules. It does not explicitly state when not to use it or name alternatives, but no sibling tool serves a similar purpose. The rejection of non-standard syntax provides some usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a JSON Web Token's header and payload and report expiry. This DECODES ONLY — it does not verify the signature, so never treat the contents as trusted on the strength of this output. Models asked to read a JWT tend to invent its claims; this reads them. Web version: https://buildutilities.com/jwt-decoder
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The JWT, optionally prefixed with 'Bearer ' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses the critical limitation that signature verification is not performed, and the output should not be considered authenticated. This is essential behavioral context that annotations do not provide, and it directly addresses a common failure mode of LLMs.
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, zero filler. The core purpose is front-loaded, the critical caveat follows immediately, and the web link is a useful addition. 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?
For a single-parameter read-only tool with full schema coverage and strong annotations, the description covers purpose, behavior, and safety caveats. It even includes a web version link. Nothing an agent needs to call it 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?
Schema coverage is 100%, so the schema already fully documents the token parameter. The description does not add parameter-specific details beyond what the schema provides (e.g., the optional 'Bearer ' prefix is already in the schema). It adds context about what the tool does with the token, but that is more about purpose than parameter semantics, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Decode a JSON Web Token's header and payload') and distinguishes it from sibling decoding tools (base64, url) by focusing on JWT structure and expiry reporting. It is immediately clear what the tool does.
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 warns that this tool only decodes and does not verify signatures, instructing never to treat contents as trusted. It also notes the model's tendency to invent claims, which implicitly tells when to rely on this tool. No alternative is named, but no sibling offers JWT verification, so usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Line-by-line diff of two texts, marking - removed and + added. Use it to check exactly what changed between two versions instead of eyeballing them. Web version: https://buildutilities.com/text-diff-checker
| Name | Required | Description | Default |
|---|---|---|---|
| after | Yes | ||
| before | Yes | ||
| ignoreWhitespace | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is fully consistent with these. Beyond annotations, the description adds the line-by-line behavior and the +/- marker convention, which tells the agent what output to expect. It doesn't address edge cases (binary input, empty strings, very large texts), but for a read-only diff tool the annotations cover the safety profile and the description adds useful behavioral detail.
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 zero waste. The core purpose and output format are front-loaded in the first sentence, usage guidance follows, and the web-link reference is brief and optional. 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?
For a simple read-only tool with annotations covering safety and no output schema, the description covers purpose, output format, and usage. The main gap is ignoreWhitespace semantics, which is not explained in either the description or the schema (0% coverage). The web link is a minor addition but not core. Adequate but with one notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. 'Two texts' maps to the before/after parameters, but the description never mentions ignoreWhitespace, which is the third parameter. The meaning of before/after is reasonably inferable from 'diff of two texts', but the boolean option's behavior (whether whitespace differences are suppressed) is left entirely to the schema, which has no descriptions. Partial compensation for a 3-parameter tool.
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 specific verb and resource: 'Line-by-line diff of two texts, marking - removed and + added.' It states both the operation and the output format, making the tool's purpose unmistakable. None of the 19 sibling tools perform text diffing, so it is clearly distinguished from alternatives.
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?
'Use it to check exactly what changed between two versions instead of eyeballing them' gives explicit context for when the tool is appropriate. It doesn't name sibling alternatives or state when not to use it, but among siblings (UUIDs, passwords, encoding, JWT, regex) no alternative does diffing, so the guidance is sufficient for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Escape a string so it can be used as a literal inside a regular expression.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific behavioral context of escaping for regex literals, which goes beyond the 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?
A single, concise sentence with no fluff. It is front-loaded with the action and purpose, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple utility with one parameter and no output schema, the description provides enough context. It explains the input and the intended use without needing to detail every escaped character, which is a reasonable level of detail.
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 0%, so the description carries the burden of explaining the single 'text' parameter. The description states 'Escape a string', making it clear the input is the string to escape. This is sufficient for a single-parameter tool.
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 specific verb ('escape') and resource ('a string') with the precise purpose of using it as a literal inside a regular expression. This distinguishes it from siblings like test_regex (which tests regex) and other encode/decode utilities.
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 clearly implies the tool is for escaping strings for regex literal use, which differentiates it from other string utilities. However, it does not explicitly state when not to use it or mention alternatives, so some inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pretty-print or minify JSON exactly, with precise error location when it is invalid. Prefer this to reformatting a large document yourself — it cannot drop or alter a value. Web version: https://buildutilities.com/json-formatter
| Name | Required | Description | Default |
|---|---|---|---|
| json | Yes | The JSON text | |
| mode | No | pretty | |
| indent | No | ||
| sortKeys | No | Sort object keys — useful for diffing two payloads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by disclosing error behavior ('precise error location when it is invalid') and a guarantee ('it cannot drop or alter a value'), which are not in the annotations. This is useful context beyond the structured fields.
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?
Two sentences with no filler. The core purpose is front-loaded, followed by a usage preference and a link. Every sentence earns its place, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple formatting tool with annotations covering safety and a schema for parameters, the description is nearly complete. It mentions error location, which is a return behavior, and implies the output is formatted JSON. It does not explicitly state the return value, but that is easily inferred. A small gap, but not a significant one.
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 50% (json and sortKeys have descriptions; mode and indent do not). The description does not compensate for the missing parameter details – it only mentions 'pretty-print or minify' which relates to mode but does not explain indent or explicitly map the parameters. It adds minimal value beyond the schema and fails to bridge the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('pretty-print or minify') and resource ('JSON'), and adds a distinguishing capability ('precise error location'). It is clear and unambiguous, and no sibling tool performs JSON formatting, so it stands apart.
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 explicit guidance: 'Prefer this to reformatting a large document yourself' – this tells the agent when to use it. It does not name an alternative tool, but none exists among the siblings, so the context is sufficient. It could be stronger with explicit 'do not use when...' but it is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a cryptographically random password. Guarantees at least one character from every enabled set. Use this rather than inventing a password — model-authored ones are guessable. Web version: https://buildutilities.com/password-generator
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many passwords | |
| digits | No | ||
| length | No | Characters in each password | |
| symbols | No | ||
| lowercase | No | ||
| uppercase | No | ||
| excludeAmbiguous | No | Drop characters that look alike: l 1 I O 0 o |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false, so the description does not need to restate safety. It adds valuable behavioral context: the password is cryptographically random and guarantees at least one character from each enabled set. This goes beyond the annotations and helps the agent understand the algorithm.
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 waste. The purpose is front-loaded, and the web version link is a minor but useful addition. 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?
The description covers the core behavior and usage clearly. It does not specify the output format (e.g., array of strings when count > 1) or edge cases like all character sets disabled, but these are inferable from the schema defaults and the tool's simplicity. Overall, sufficient for an agent to call correctly.
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 only 43%, with the boolean parameters (digits, symbols, lowercase, uppercase) lacking descriptions. The description hints at 'every enabled set' but does not explicitly map these booleans to character sets. It partially compensates by implying the toggles, but an agent may still be uncertain about which parameters control which sets.
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?
Clearly states it generates a cryptographically random password and guarantees at least one character from every enabled set. The verb 'generate' with resource 'password' is specific, and it distinguishes itself from sibling tools like generate_uuid and generate_token by focusing on password generation.
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 instructs to use this rather than inventing a password, providing a clear when-to-use directive. It does not explicitly mention alternatives like UUID or token, but the context of password vs. those siblings makes the distinction implicit. No exclusions are stated, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a cryptographically random token — API keys, session ids, nonces, salts. Choose hex, base64url or alphanumeric encoding. Web version: https://buildutilities.com/random-string-generator
| Name | Required | Description | Default |
|---|---|---|---|
| bytes | No | Bytes of entropy before encoding | |
| count | No | ||
| encoding | No | hex |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the critical behavioral trait 'cryptographically random', which conveys non-determinism and security properties beyond the annotations. No contradiction 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 two concise sentences with no wasted words. The core purpose and encoding options are front-loaded, and the additional web link is a minor but acceptable appendage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple token generator with no output schema and only three parameters, the description covers the essential purpose and encoding behavior. It lacks explicit mention of return format (e.g., a string), but that is implied by the tool name and typical usage. The description is sufficient for an agent to call it correctly without ambiguity.
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 low (33%), only 'bytes' has a schema description. The description explains the 'encoding' parameter by naming the three options, but does not elaborate on 'bytes' (entropy) or 'count' (number of tokens). Given the low coverage, the description should compensate more fully; it partially does by explaining encoding but leaves the other two parameters underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and resource ('random token'), and immediately enumerates concrete use cases (API keys, session ids, nonces, salts). It also lists the encoding options, making the tool's role unambiguous and distinct from siblings like generate_uuid or generate_password.
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 provides clear context on when to use this tool (API keys, session ids, nonces, salts) but does not explicitly state when NOT to use it or name alternative tools. The listed use cases help an agent select it over generate_uuid or generate_password, but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate cryptographically random UUID v4 identifiers. Use this instead of writing a UUID yourself — model-authored UUIDs are not random and repeat across sessions. Web version: https://buildutilities.com/uuid-generator
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many UUIDs to generate | |
| uppercase | No | Return them uppercased |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior. The description adds the critical behavioral trait of cryptographic randomness and warns about the pitfalls of hand-written UUIDs, which is beyond the structured annotations. It does not mention output format or repetition, but those are implied.
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?
Two sentences with zero waste. The purpose is front-loaded, and the usage guidance follows immediately. The web link is a bonus, not fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description fully covers what an agent needs to call it correctly: purpose, usage context, and the key caveat about randomness. Nothing essential 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?
Schema description coverage is 100% for both count and uppercase parameters. The description does not add any parameter-specific meaning, but since the schema fully documents them, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Generate') and resource ('UUID v4 identifiers'), clearly distinguishing this from random string tools. The mention of 'cryptographically random' and the explicit contrast with model-authored UUIDs makes the purpose unambiguous.
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 instructs to use this tool instead of writing UUIDs manually, warning that model-authored UUIDs are not random and repeat across sessions. This provides clear when-to-use guidance and implicitly covers the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a cryptographic digest of text. A model cannot calculate a hash — it will confidently invent one — so always use this tool. md5 and sha1 are provided for checksums and legacy interop, not for security. Web version: https://buildutilities.com/hash-generator
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| encoding | No | hex | |
| algorithm | No | sha256 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral value beyond this: the warning that a model will hallucinate a hash, and the security caveat that md5/sha1 are not for security. No contradiction with annotations — 'compute a digest' is consistent with a non-mutating, idempotent operation.
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, front-loaded with the core purpose, followed by the critical behavioral warning and algorithm guidance. Efficient and each sentence earns its place. The trailing web URL is minor noise but does not detract meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter digest tool with no output schema, the description covers purpose, when to use, and algorithm security. The return format is not stated, but the output of a hash tool is self-evident (the digest string). The encoding parameter is the only notable gap, making this solid but not perfect.
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 0%, so the description carries the burden of parameter meaning. It does explain the algorithm parameter's security tradeoffs (md5/sha1 vs. secure options) and names the algorithms, adding real value. However, the encoding parameter (hex/base64) is left unexplained, relying on the enum names being self-explanatory. Partial compensation for the 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Compute a cryptographic digest of text.' This clearly distinguishes it from sibling tools like base64_encode, hmac_sign, and generate_uuid, so an agent can select it correctly without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a strong when-to-use directive: 'A model cannot calculate a hash — it will confidently invent one — so always use this tool.' It also provides algorithm-selection guidance (md5/sha1 for checksums and legacy interop, not for security). It does not explicitly name sibling exclusions (e.g., hmac_sign for keyed digests), but the core usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute an HMAC of a message with a secret key — webhook signatures, API request signing. Web version: https://buildutilities.com/hmac-generator
| Name | Required | Description | Default |
|---|---|---|---|
| secret | Yes | ||
| message | Yes | ||
| encoding | No | hex | |
| algorithm | No | sha256 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds no significant behavioral detail beyond the computation itself and does not discuss return format or failure behavior; this is adequate for a pure function but not especially informative.
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 main sentence is concise and front-loaded with the verb and object. The trailing 'Web version' URL is irrelevant to an agent selecting or invoking the tool and counts as mild noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stateless function, the description plus schema and annotations cover required inputs, supported algorithms, encoding options, and safety. There is no output schema and the description does not explicitly state the return value, but 'Compute an HMAC' makes the output type clear enough for this 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 description coverage is 0%, and the description only repeats 'message' and 'secret key,' adding little beyond the parameter names. It does not explain the encoding output format or the algorithm choice, so the optional parameters rely entirely on self-explanatory enum values 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 opens with a specific verb and object—'Compute an HMAC of a message with a secret key'—and reinforces the signing use cases. This contrasts with the sibling hmac_verify tool, so an agent can distinguish the signing operation without opening the schema.
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?
Concrete scenarios ('webhook signatures, API request signing') give the agent clear context for when this tool applies. It does not explicitly name alternatives or state when not to use it, so exclusions are missing but the intended use is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a message against an expected HMAC using a constant-time comparison. Use this to validate an inbound webhook signature rather than comparing strings yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| secret | Yes | ||
| message | Yes | ||
| algorithm | No | sha256 | |
| signature | Yes | The signature to check, hex or base64 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the valuable constant-time comparison detail, which is not in annotations. However, it does not disclose the return value or behavior on mismatch (e.g., boolean vs error), which is a gap given no output schema. Since annotations already cover readOnly, idempotent, and non-destructive, the added timing-safety context earns a 4.
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 two sentences, front-loaded with the core purpose and immediately followed by a usage directive. No fluff or redundancy—every word adds value.
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 gives purpose and usage but omits the return type or error handling, which is critical for an agent to know how to process the result without an output schema. It also does not mention the algorithm default or encoding specifics, though those are in the schema. Overall adequate but not fully complete for a verification 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 description coverage is only 25% (only the signature parameter is described). The tool description does not explain the 'secret' (shared key) or 'algorithm' parameters at all, and only vaguely references 'message' and 'expected HMAC'. It fails to compensate for the sparse schema, leaving the agent to infer parameter semantics from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Check a message against an expected HMAC') with a clear resource (message vs HMAC) and adds a concrete use case (validate inbound webhook). It implicitly distinguishes from the sibling hmac_sign by focusing on verification, and explicitly contrasts with manual string comparison.
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 provides a direct directive: 'Use this to validate an inbound webhook signature rather than comparing strings yourself.' This tells the agent exactly when to use the tool and what to avoid (manual comparison), making the selection decision unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn text into a URL-safe slug, transliterating accents and collapsing separators. Web version: https://buildutilities.com/slug-generator
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| maxLength | No | ||
| separator | No | - |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds behavioral detail beyond annotations by specifying transliteration of accents and collapsing of separators, which gives the agent insight into how the transformation works. It does not contradict the 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 two sentences and front-loaded with the core functionality. The first sentence is essential and clear. The second sentence provides a web link, which is extra but not verbose. It is appropriately concise, though the link could be considered non-essential for an AI agent.
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 tool is relatively simple, and the schema provides parameters with defaults and enums. However, the description lacks explanation of how 'maxLength' and 'separator' affect the output. While an agent might infer from the schema, the description does not clarify truncation or separator customization. Overall, it is adequate but with clear gaps.
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 0%, meaning the schema provides no textual descriptions for parameters. The description must compensate but does not. It mentions nothing about 'text', 'maxLength', or 'separator'. While the schema defines types, defaults, and enums, the description adds no semantic explanation, leaving agents to infer behavior from names alone.
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's function: 'Turn text into a URL-safe slug, transliterating accents and collapsing separators.' This is a specific verb+resource with concrete transformation details. It does not explicitly name sibling tools or differentiate itself, but the purpose is unambiguous and distinct from the listed siblings.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any use cases, conditions, or exclusions. It simply describes the operation without context, so an agent has no explicit direction on when to choose slugify over other transformation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Actually execute a regular expression against text and return every match with its index and capture groups. Use this instead of predicting what a pattern matches — reasoning about a regex is not the same as running it. Web version: https://buildutilities.com/regex-tester
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to search | |
| flags | No | Regex flags, e.g. gi, gm, gs | g |
| pattern | Yes | The pattern, without delimiters | |
| maxMatches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by specifying the exact output format (matches with index and capture groups). It also warns against reasoning about regex, a behavioral caveat beyond the 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 three sentences, front-loaded with the core action, then usage guidance, then a supplementary link. Each sentence serves a purpose, with no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only utility tool with annotations covering safety, the description explains the action, output, and when to use it. It lacks explicit details on flags behavior and the maxMatches limit, but these are present in the schema. Overall, it is sufficient for an agent to call correctly.
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 75%, with pattern, text, and flags documented. The description does not add parameter-specific meaning beyond the schema; maxMatches is not described in the schema but has default and constraints, so the description does not need to compensate.
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 executes a regex against text and returns every match with index and capture groups. It uses a specific verb and resource, and the mention of 'Use this instead of predicting' distinguishes it from reasoning or other regex-related utilities.
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 explicitly instructs to use this tool instead of predicting what a pattern matches, giving a clear when-to-use condition. While it doesn't name a specific alternative, it provides strong behavioral guidance and implies the tool is for actual execution rather than mental simulation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode percent-encoded text. Web version: https://buildutilities.com/url-codec
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context beyond the core action, but given the trivial nature of the operation and the annotation coverage, this is acceptable. No contradiction 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, front-loaded sentence with no superfluous words. It immediately states the operation and includes a helpful web-version link. Every word earns its place, making it a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple decode operation with a single parameter, annotations covering safety, and no output schema, the description is complete. The expected behavior and input are fully specified, and the web link adds optional context. Nothing an agent needs to call it 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?
Schema coverage is 0%, so the description must clarify parameter meaning. The description 'Decode percent-encoded text' explicitly defines that the 'text' parameter should contain percent-encoded content, adding value beyond the schema's mere 'type: string'. It conveys the required input format and intent effectively for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Decode') and resource ('percent-encoded text'), making the tool's purpose unambiguous. It clearly distinguishes from the sibling url_encode by focusing on decoding. The single-sentence definition is precise and leaves no room for misinterpretation.
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 usage is implied by the description and name, but there is no explicit guidance on when to use this tool versus alternatives like url_encode, or any mention of conditions or exclusions. While obvious for a simple utility, the description does not actively route the agent, so it misses the higher bar for explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Percent-encode text. component mode escapes & = ? / for use inside a query value; uri mode preserves them. Web version: https://buildutilities.com/url-codec
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | component | |
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral detail by specifying which characters are escaped in component mode versus preserved in uri mode, which is valuable context beyond the 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 brief, with the primary purpose stated first, followed by the mode distinction, and a supplementary web link. Every sentence earns its place; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, side-effect-free encoding tool with no output schema and straightforward parameters, the description covers purpose, mode behavior, and the text input implicitly. The return value (encoded string) is obvious from the operation. Annotations cover the safety profile, and no critical information 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?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It explicitly describes the mode parameter's two values and their effects. The text parameter is self-explanatory from the phrase 'Percent-encode text', so the description effectively compensates for the missing schema 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 clearly states the tool percent-encodes text, distinguishing it from siblings like base64_encode and url_decode. It also specifies two modes with concrete character-level behavior, leaving no ambiguity about what the tool does.
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 each mode ('component mode escapes & = ? / for use inside a query value; uri mode preserves them'), providing clear guidance on mode selection. However, it does not mention alternatives or when not to use this tool versus other encoding/decoding siblings, so it lacks explicit exclusions.
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.
v0.1.2analyze_textbase64_decodebase64_encodecheck_color_contrastconvert_timestampcron_next_runsdecode_jwtdiff_textescape_regexformat_jsongenerate_passwordgenerate_tokengenerate_uuidhash_texthmac_signhmac_verifyslugifytest_regexurl_decodeurl_encodeScored across 20 tools
Each tool targets a distinct utility: UUID, password, token, base64, URL, regex, hash, HMAC, timestamp, cron, JSON, JWT, diff, text analysis, slug, and color contrast. Even the three generators (UUID, password, token) are clearly separated by output format and use case.
Most tools follow a verb_noun pattern like generate_uuid, hash_text, decode_jwt, and test_regex. A few deviate—hmac_sign/hmac_verify invert the object-verb order, cron_next_runs has no verb, and slugify is a standalone verb—but the overall style remains readable and predictable.
At 20 tools, this sits in the 16-25 range that feels heavy for a single server, especially since it is a grab-bag of unrelated utilities rather than a focused workflow. That said, every tool is atomic and has a clear purpose, so the count is defensible even if slightly bloated.
The set covers the main developer-utility categories well: random generation, encoding, hashing/HMAC, time, JSON/JWT, regex, and text analysis. Minor gaps exist—such as JWT signature verification, HTML entity encoding, and regex replacement—but agents can work around these with existing tools or general knowledge.
238+ dev tools via MCP: JSON, QR, PDF, DNS, hash, UUID, code review, JWT, SSL, WHOIS, and more
Remote MCP server: 10 developer utilities (base64, JWT, DNS, UUID, URL, JSON, UA, IP lookup).
19 zero-setup utilities: JSON, regex, cron, hash, base64, CSV, JWT, UUID, YAML, semver, time.
49 developer tools via MCP: DNS, WHOIS, IP lookup, JWT, hashing, QR, and more.
