Exact local utils: QR, hashing/encoding, JSON Schema, cron, markdown, diff, units, JWT, random.
Scored across 10 tools
Each tool targets a clearly distinct utility: cron parsing, hashing/encoding, JSON Schema validation, JWT decoding, Markdown conversion, QR generation, randomness, text diffing, text stats, and unit conversion. There is no meaningful overlap in purpose, so an agent can select the right tool unambiguously.
Almost all tools follow a consistent snake_case noun_verb or noun_noun pattern (cron_explain, hash_encode, text_diff, unit_convert). A couple of names deviate slightly (qr_code, random_gen), which reduces predictability but remains readable and consistent in style.
Ten tools is well-scoped for a general-purpose utility server. Each tool covers a distinct common utility, so there is no filler or redundancy in the set.
The surface covers a broad set of common developer/text/data utilities and includes encode/decode, validation, and conversion operations. Some adjacent utilities are missing (e.g., standalone base64/URL encoding, JSON formatting, regex testing), but core workflows are covered and no tool leaves a major dead end.
Explain a cron expression in plain English and list its next N run times in any time zone — catch a schedule mistake before it fires at 3 am. Supports 5-field and 6-field (seconds) cron, ranges, steps, L/W/#, and nicknames (@daily, @hourly…). Price: free. Errors: returns isError with a message for invalid input or an upstream failure (not charged).
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA time zone for the next-run times. Default "UTC". | UTC |
| count | No | How many upcoming run times to list. Range 1-50. Default 5. | |
| expression | Yes | Cron expression, 5 fields (or 6 with seconds), e.g. "*/15 9-17 * * 1-5". |
| Name | Required | Description |
|---|---|---|
| tz | No | |
| valid | No | |
| meaning | No | |
| next_runs | No | |
| expression | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral facts: pricing ('free') and error contract ('returns isError with a message for invalid input or an upstream failure (not charged)'). It stops short of richer context like latency or output shape, but the output schema covers the latter.
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 tightly packed sentences front-loaded with purpose and payoff; the syntax-support and pricing/error details follow without filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and the annotations carry the safety profile. The description still supplies the error contract, pricing, and accepted syntax, so nothing an agent needs to invoke 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 baseline is 3, but the description adds meaningful semantics for the expression parameter by enumerating supported syntax: 5-field and 6-field (seconds), ranges, steps, L/W/#, and nicknames (@daily, @hourly). That tells the agent what inputs will be accepted beyond the schema's single example.
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 (explain) and resource (cron expression) plus a second concrete deliverable (next N run times in any time zone). No sibling tool does cron work, so the agent can identify it immediately from name and description alone.
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?
Gives a clear motivating use case ('catch a schedule mistake before it fires at 3 am') that tells the agent when this is the right tool. It does not name any alternative or exclusion, but no plausible sibling competes for this task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hash data (SHA-256/512, SHA3, Keccak-256, BLAKE2, MD5, SHA-1, RIPEMD-160, HMAC) and convert between utf8, hex, base64, base64url and base58 — exact, in one call. Useful for signatures, content addressing, EVM selectors (keccak of a function signature), and decoding blobs agents are handed. Input can itself be hex/base64/base58. Price: free. Errors: returns isError with a message for invalid input or an upstream failure (not charged).
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Data to hash or re-encode. | |
| hashes | No | sha256, sha512, sha3-256, sha3-512, keccak256, blake2b512, blake2s256, md5, sha1, ripemd160. 0-12 items. Default ["sha256","keccak256"]. | |
| hmac_key | No | if set, HMAC instead of plain hash (utf8 key) | |
| input_encoding | No | How the input string is encoded. One of "utf8", "hex", "base64", "base58". Default "utf8". | utf8 |
| Name | Required | Description |
|---|---|---|
| bytes | No | |
| hashes | No | |
| encodings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds value beyond them by disclosing pricing (free) and error behavior (returns isError, not charged), plus the 'exact, in one call' determinism claim.
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?
It is front-loaded with the core capability and packs use cases, pricing, and error semantics into a compact form with no filler. Slightly dense, but every clause 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?
With an output schema present, return values need no explanation. The description covers algorithms, encodings, use cases, pricing, and error handling, leaving nothing essential for correct invocation unstated.
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 parameters are documented regardless. The description nonetheless adds meaning: it notes the input can itself be hex/base64/base58, mentions HMAC behavior, and lists base64url, which the schema enum omits.
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 set (hash and encode/decode) with enumerated algorithms and encodings, and clarifies it does both in one call. An agent can immediately tell this apart from siblings like jwt_decode or text_stats.
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 names concrete use cases (signatures, content addressing, EVM selectors, decoding handed blobs), which gives clear context for when to reach for it. It stops short of stating when NOT to use it or naming an alternative, but no sibling overlaps meaningfully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate JSON data against a JSON Schema (draft-07/2019-09/2020-12, formats like email/uri/date-time) and get every error with its exact path — check tool I/O before acting on it. Ajv, strict about types, all errors reported. Pass data and schema as JSON values (or JSON strings). Price: free. Errors: returns isError with a message for invalid input or an upstream failure (not charged).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | any JSON value (or a JSON string with parse_strings=true) | |
| schema | Yes | The JSON Schema to validate against. | |
| parse_strings | No | true = if data is a string, parse it as JSON first. Default false. |
| Name | Required | Description |
|---|---|---|
| valid | No | |
| errors | No | |
| error_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuinely new behavioral facts beyond them: the validator is Ajv and strict about types, all errors are reported, the call is free, and invalid input or upstream failure returns isError rather than a normal result. That is substantive added context, though it omits whether it is a local or network 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?
Front-loaded with purpose, then a use-case clause, then operational notes; nothing is wasted. It is slightly crowded and fragmented by the clipped "Ajv, strict about types, all errors reported." and "Price: free." fragments, which read like stitched-together metadata.
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?
An output schema exists, so return values need no prose, and the description still covers error behavior and cost. Combined with the annotations, an agent has enough to call it correctly; the only real gap is the absence of parse_strings semantics and whether third-party $ref resolution is supported by the open-world validator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents data, schema, and parse_strings, making 3 the baseline. The description adds only that data and schema may be passed as JSON values or JSON strings, but it never mentions parse_strings, the flag that actually governs string parsing, so it contributes marginal meaning over the schema.
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 and resource ("Validate JSON data against a JSON Schema") and immediately scopes it with supported drafts and formats like email/uri/date-time. Among siblings like address_check, email_check, and jwt_decode, it is unmistakably the generic schema validator, and the added "check tool I/O before acting on it" frames the exact use case.
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 phrase "check tool I/O before acting on it" gives a concrete situation that selects this tool over the domain-specific checkers. However, it never names an alternative explicitly or states when not to use it (e.g., for validating a specific address or email, use address_check/email_check instead), so routing still requires inference.
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 claims, show issued/expiry times in plain dates and whether it has expired — optionally verify an HS256/384/512 signature with a secret. Decoding does not need the key. Never paste production secrets into third-party tools you do not trust; verification here is local and nothing is stored or logged. Price: free. Errors: returns isError with a message for invalid input or an upstream failure (not charged).
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The JWT (three base64url parts). The signature is not verified. | |
| secret | No | optional HMAC secret to verify HS* signatures |
| Name | Required | Description |
|---|---|---|
| header | No | |
| expired | No | |
| payload | No | |
| issued_at | No | |
| signature | No | |
| expires_at | No | |
| not_before | No | |
| seconds_left | No | |
| alg_none_warning | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive safety, so the bar is lower, and the description adds real context beyond them: verification is local, nothing is stored or logged, pricing is free, and errors return isError without charge. It stops short of full disclosure (e.g. no rate-limit or output-shape notes), but the additions are genuinely useful.
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?
Purpose and the core capability are front-loaded, and each subsequent sentence (key optionality, secret-handling caution, pricing, error behavior) carries distinct information. It is slightly long for a two-parameter tool, but nothing is filler.
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?
An output schema exists, so return values need not be explained in the description. The description covers purpose, key semantics, security posture, pricing, and error behavior, leaving little an agent needs to invoke 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%, so both parameters are already documented in the schema, establishing the baseline of 3. The description adds the specific HMAC algorithm names (HS256/384/512) and clarifies the key is unnecessary for decoding, which is marginal added value over the schema.
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 and resource ('Decode a JSON Web Token's header and claims') and specifies exactly what it surfaces (issued/expiry dates, expiry status) plus an optional signature-verification capability. No sibling tool overlaps with JWT decoding, so it is unambiguously distinguishable.
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?
Gives clear operating context: 'Decoding does not need the key', clarifying that the secret is only required for optional HS256/384/512 verification. No named alternatives exist among siblings, but it never states when one would reach for this tool rather than a generic decoder, keeping it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert Markdown to clean HTML (GitHub-flavoured: tables, task lists, fenced code) or HTML back to Markdown. marked for md→html, Turndown for html→md. Scripts/styles are dropped on html→md. Price: free. Errors: returns isError with a message for invalid input or an upstream failure (not charged).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Target format. One of "html", "markdown". Default "html". | html |
| input | Yes | Markdown or HTML to convert. |
| Name | Required | Description |
|---|---|---|
| to | No | |
| output | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive and openWorld, so the bar is lower. The description still adds real value beyond them: scripts/styles are dropped on html→md (a data-loss disclosure), the tool is free, and errors surface via isError without charging.
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?
Front-loaded with the primary direction, then flavor, libraries, transformation caveat, pricing and error behavior in four dense, non-redundant sentences. Nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation. The description covers direction, supported extensions, destructive transformation, cost, and error semantics — everything an agent needs 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%, so both parameters (target enum and raw input) are already documented, establishing a baseline of 3. The description restates the two conversion directions but adds no syntax or format detail beyond the schema.
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 bidirectional verb+resource: convert Markdown to clean HTML or HTML back to Markdown, with the flavor named (GitHub-flavoured: tables, task lists, fenced code). No sibling tool in the list performs format conversion of Markdown/HTML, so it is unambiguously distinguishable.
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 two directions and the default target are made clear, which tells the agent when each mode applies, but it does not name exclusions or alternatives. Since no sibling overlaps, the direction split is enough context to select correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a QR code for any text, URL, Solana Pay / wallet address or Wi-Fi login — as a PNG (base64 data URL) or SVG, with size, margin, colours and error correction. Rendered on our server. For Wi-Fi pass wifi_ssid + wifi_password; for Solana Pay pass a solana: URI as text. Price: free. Errors: returns isError with a message for invalid input or an upstream failure (not charged).
| Name | Required | Description | Default |
|---|---|---|---|
| dark | No | Foreground colour as #rrggbb. Default "#000000". | #000000 |
| size | No | Image width/height in pixels. Range 64-2048. Default 512. | |
| text | No | Text or URL to encode (ignored when wifi_ssid is set). | |
| light | No | Background colour as #rrggbb. Default "#ffffff". | #ffffff |
| format | No | PNG (base64 data URL) or SVG markup. One of "png", "svg". Default "png". | png |
| margin | No | Quiet-zone width in modules. Range 0-16. Default 2. | |
| wifi_ssid | No | Wi-Fi network name; makes a join-network QR instead of text. | |
| wifi_password | No | Wi-Fi password (with wifi_ssid; omit for open networks). | |
| error_correction | No | Error-correction level: L 7%, M 15%, Q 25%, H 30%. One of "L", "M", "Q", "H". Default "M". | M |
| Name | Required | Description |
|---|---|---|
| svg | No | |
| format | No | |
| encoded | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds traits annotations cannot express: server-side rendering, 'Price: free', and error semantics ('returns isError with a message for invalid input or an upstream failure (not charged)') — the charge-on-failure disclosure is exactly the kind of behavioral context an agent needs.
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?
Single dense paragraph that is front-loaded with what the tool makes and its outputs before moving to mode-specific instructions, cost and errors. Every clause carries information, though the semicolon-chained clauses make it slightly cluttered rather than crisply segmented.
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 9-parameter tool with an output schema, the description covers the gaps that structured data leaves open: which input mode to choose, that rendering happens server-side, that it is free, and how failures surface. Nothing an agent needs in order 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 description coverage is 100%, so the per-parameter meanings (colours, size range, margin, error-correction percentages, enum values) are already documented and baseline is 3. The description goes beyond by explaining the cross-parameter relationship between text, wifi_ssid and the solana: URI form, which the schema only hints at.
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 (make) and resource (QR code) and enumerates the accepted payloads: text, URL, Solana Pay/wallet address, Wi-Fi login. It also names the two output artifacts (PNG base64 data URL or SVG), so an agent knows exactly what this produces. No sibling tool overlaps, so no differentiation burden remains.
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?
Gives concrete invocation guidance for the two special modes: 'For Wi-Fi pass wifi_ssid + wifi_password' and 'for Solana Pay pass a solana: URI as text.' This resolves the ambiguity of the multi-mode input, though it offers no explicit when-not-to-use and there are no alternative tools to route against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cryptographically secure randomness: UUID v4/v7, passwords, API-key-style tokens, integers in a range, dice, coin flips, or a fair shuffle / pick from a list. Node's CSPRNG. Output is generated fresh per call and never stored or logged. Price: free. Errors: returns isError with a message for invalid input or an upstream failure (not charged).
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Highest integer (kind=int). Default 100. | |
| min | No | Lowest integer (kind=int or dice sides). Default 1. | |
| kind | No | What to generate. One of "uuid4", "uuid7", "password", "token", "int", "shuffle", "pick", "coin", "dice". Default "uuid4". | uuid4 |
| count | No | How many values to generate. Range 1-100. Default 1. | |
| items | No | List to shuffle or pick from (kind=shuffle or pick). 0-1000 items. | |
| length | No | Length for passwords and tokens. Range 4-256. Default 20. | |
| symbols | No | Include symbols in passwords. Default true. |
| Name | Required | Description |
|---|---|---|
| kind | No | |
| result | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds meaningful context beyond the annotations: Node's CSPRNG source, fresh generation per call, no storage or logging, free pricing, and that errors return isError without being charged. The annotations only declare readOnly/openWorld/idempotent/destructive=false, so the security and billing disclosures are genuinely additive. It stops short of describing output format or pagination, but with an output schema present 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 dense sentences, capability list front-loaded, then guarantees and pricing/error notes. No filler and nothing redundant with the title.
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 multi-mode generator with 7 optional params and an output schema, the description supplies the security, freshness, no-logging, pricing, and error-handling context an agent needs to decide to call it. Only minor gaps remain (e.g. return shape for count>1), which the output schema likely covers.
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 every parameter (min, max, kind, count, items, length, symbols) is already documented in the schema with defaults and ranges. The description names the kinds but adds no syntax, format, or constraint detail beyond the schema, so baseline 3 applies.
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 and resource with an explicit enumeration of the nine output kinds (UUID v4/v7, passwords, tokens, ints, dice, coin, shuffle/pick), which lets an agent confirm capability without opening the schema. No sibling tool in the list covers secure randomness, so differentiation is inherent and stated via 'cryptographically secure'.
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 covers what it generates and mentions 'free' and error behavior, but never states when to prefer this tool over an alternative (e.g. hash_encode for deterministic IDs) or any prerequisites. Usage is implied by the kind list rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diff two texts: unified diff (patch format), a line/word-level change list, and similarity % — compare versions of a doc, config or code. jsdiff. mode=lines gives a unified patch; mode=words gives word-level changes for prose. Price: free. Errors: returns isError with a message for invalid input or an upstream failure (not charged).
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | Original text. | |
| b | Yes | Changed text. | |
| mode | No | Diff granularity. One of "lines", "words". Default "lines". | lines |
| context | No | Unchanged lines of context around each change in the patch. Range 0-20. Default 3. |
| Name | Required | Description |
|---|---|---|
| changes | No | |
| unified | No | |
| identical | No | |
| chars_added | No | |
| chars_removed | No | |
| similarity_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral context: pricing ("Price: free") and error behavior ("returns isError ... for invalid input or an upstream failure (not charged)"). It omits limits like input size caps, but the added error/cost disclosure is meaningful 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?
Front-loads the core operation and outputs, then mode clarification, then price/error notes. Dense but each clause earns its place; the em-dash output list and shorthand "jsdiff" are slightly packed but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained. The description covers purpose, mode selection, cost, and error handling, leaving nothing an agent needs in order 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%, so the baseline is 3. The description adds semantic value by explaining what each mode actually yields ("unified patch" vs "word-level changes for prose"), which the terse schema field does not convey, though it says nothing about 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?
States a specific verb and resource ("Diff two texts") and enumerates the three outputs (unified diff, line/word change list, similarity %), so an agent knows exactly what it produces. Among siblings like text_stats and markdown_convert, the diff-and-compare scope is 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?
Gives concrete usage context ("compare versions of a doc, config or code") and routes mode selection ("mode=lines gives a unified patch; mode=words gives word-level changes for prose"). It lacks explicit when-not conditions or named alternatives, 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.
Count characters, words, sentences, lines and paragraphs, estimate LLM tokens, reading time and readability (Flesch), and pull out every URL, email, @handle, #tag, number and crypto address. Token count is an estimate (~4 characters per token for English; code and non-Latin scripts differ). Extraction uses strict patterns; EVM addresses are checksum-validated. Price: free. Errors: returns isError with a message for invalid input or an upstream failure (not charged).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text (or a URL when extract=true) to analyse. | |
| extract | No | true = if text is a URL, fetch the page and analyse its readable text. Default true. |
| Name | Required | Description |
|---|---|---|
| lines | No | |
| words | No | |
| extracted | No | |
| sentences | No | |
| characters | No | |
| paragraphs | No | |
| readability | No | |
| reading_minutes | No | |
| estimated_tokens | No | |
| flesch_reading_ease | No | |
| characters_no_spaces | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/destructive/openWorld, so the bar is lower, yet the description adds real context: token count is an approximation with the ~4 chars/token caveat, extraction uses strict patterns, EVM addresses are checksum-validated, the tool is free, and errors surface via isError without being charged. Missing only rate-limit or response-shape notes.
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?
Front-loaded with the capability list, followed by useful qualifiers on token estimation, extraction strictness, pricing, and errors. Dense but each sentence carries information; no filler.
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?
An output schema exists so return values need no explanation. The description covers the main behavioral caveats, error mode, and pricing, leaving only minor gaps such as limits on input size or network-fetch cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the extract-URL behavior and adds a caveat about token estimation accuracy, but does not add much meaning beyond what the schema already documents for text and extract.
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 specific verbs and resources: counting characters/words/sentences/lines/paragraphs, estimating tokens, reading time, Flesch readability, and extracting URLs/emails/handles/tags/numbers/crypto addresses. This is clearly distinguishable from siblings like text_diff and markdown_convert.
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?
Usage is implied by the enumeration of capabilities, but there is no explicit guidance on when to prefer this over e.g. web_read or text_diff, nor any stated exclusions or prerequisites. The extract parameter hints at web-page analysis but the routing condition is not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between units of length, mass, volume, temperature, speed, area, time, data size, energy, power, pressure, frequency and more — or list every unit a value converts to. Exact conversion tables (convert-units). Use abbreviations: m, km, mi, ft, kg, lb, oz, l, gal, C, F, K, km/h, mph, knot, B, KB, MB, GB (binary, 1 GB = 1024 MB), J, kWh, W, Pa, bar, psi, Hz… Price: free. Errors: returns isError with a message for invalid input or an upstream failure (not charged).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | omit to get every compatible unit | |
| from | Yes | Source unit, e.g. "mi", "kg", "degF", "GB". | |
| value | Yes | Number to convert. |
| Name | Required | Description |
|---|---|---|
| to | No | |
| from | No | |
| value | No | |
| result | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely useful behavioral context beyond them: pricing ('free'), error semantics (returns isError on invalid input or upstream failure, not charged), the conversion-table source, and the binary convention (1 GB = 1024 MB). It does not describe rate limits or return shape, but the error/charging disclosure is meaningful added value.
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?
Front-loads the purpose, then supporting detail (abbreviations), then operational notes (price, errors). Dense but every sentence contributes; the long unit enumeration is the only slightly padded element, though it usefully scopes coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and the description covers purpose, accepted inputs, error behavior and cost. It is nearly complete for a simple converter, with only the overlap against time_convert left unaddressed.
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 each parameter is already documented and the baseline is 3. The description adds meaning beyond the schema: concrete abbreviation examples (mi, degF, GB, knot...), the binary data-size definition, and the special semantics of omitting 'to' to enumerate all compatible units.
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 (Convert) and resource (units) and enumerates the covered categories, plus a distinct second mode ('list every unit a value converts to'). It is clear what the tool does, but it never distinguishes itself from the closely overlapping sibling time_convert (or markdown_convert), which the category list 'time' arguably touches.
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 usage through the 'omit to get every compatible unit' note and the abbreviation list, but it gives no explicit when-to-use vs alternatives guidance and never explains how to choose this tool over time_convert for time units. Usage is inferable rather than stated.
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.
cron_explainhash_encodejson_schema_validatejwt_decodemarkdown_convertqr_coderandom_gentext_difftext_statsunit_convertExact hashing, base64/hex/URL encoding, JWT decoding and UUIDs for AI agents. No auth required.
19 zero-setup utilities: JSON, regex, cron, hash, base64, CSV, JWT, UUID, YAML, semver, time.
13 deterministic agent utilities: timezone, cron, RRULE, currency, regex, diff, hashing & more.
Developer toolkit: UUID, timestamp, unit conversion, JSON tools, and QR code (SVG). Free.
Add one secure layer between your agents and this server.