13 free utility tools for AI agents: web text, markdown, hashing, IDs, dates, units, JSON.
Scored across 13 tools
Most tools target clearly distinct operations, such as hashing, unit conversion, and summarization. There is minor overlap between random_token and uuid_generate (both random IDs) and between fetch_page_text and html_to_text (both return cleaned text), but descriptions make the boundaries mostly clear.
All names use snake_case and are descriptive, which is consistent. The pattern is not strictly verb_noun throughout, with noun_noun names like date_math, json_format, text_stats, and unit_convert mixed in, but this is a minor deviation.
13 tools falls squarely within the ideal 3-15 range for a general utility toolbox. Each tool represents a separate utility, and the set does not feel bloated or thin.
The server covers many common utilities but lacks obvious inverse operations, such as a decode counterpart to encode_text. Agents needing to decode base64, URL encoding, or hex will hit a dead end, which is a notable gap for a general toolbox.
Date utilities: now (current UTC time), add (add a duration to a date), diff (difference between two dates), weekday (day name for a date).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO date for add/weekday | |
| unit | No | millisecond/second/minute/hour/day/week | day |
| date1 | No | ||
| date2 | No | ||
| value | No | Amount for add | |
| operation | No | now |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full behavioral burden. It does disclose useful context ('current UTC time' for now), but it omits return formats, whether diff is signed or which argument is subtracted from which, the default unit for diff, and error behavior for malformed dates.
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 dense sentence with the four operations front-loaded and each gloss kept to a few words. No filler; the only mild cost is that packing everything into one sentence makes per-operation detail hard to find.
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?
Six parameters with no required fields, no annotations, and no output schema is a lot of ambiguity to resolve. The description names the operations but never maps required parameters per operation or describes return shapes, leaving the agent to guess how to call diff or weekday 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 50%, so the description must compensate and it only partly does: it ties 'date' to add/weekday and 'value' to add, but says nothing about date1/date2, nor how 'unit' applies across operations. The remaining parameters are undocumented in both places.
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 resource (date utilities) and enumerates four concrete operations with one-line glosses, so an agent can tell what the tool does at a glance. It does not differentiate from siblings like unit_convert, but those are unrelated enough that differentiation isn't critical here.
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 operation list implies which mode to select ('add' for duration arithmetic, 'diff' for two-date comparison, 'now' for current time), which is enough to pick an operation. There is no explicit when-not guidance and no statement of which parameters are required for which operation, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode text as base64, base64url, url-encoding, or hex.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| format | No | base64 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and only identifies the transformation. It does not state that the operation is side-effect-free, deterministic, requires no auth, whether the default format is base64, or what the return value looks like. For a pure-function utility this is thin, though the risk surface is low.
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 front-loaded sentence that lists the meaningful options with no filler. It is arguably under-specified rather than bloated, but structurally it 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 trivial two-parameter transform with no output schema, the description is minimally adequate: it tells you the encodings available. It omits the default (base64), the return shape, and whether encoding is reversible, which an agent would need for confident invocation.
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, and it partially does by spelling out the four format values including the human-readable 'url-encoding' for the enum value 'url'. It says nothing about the required 'text' parameter or its expected content/size.
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?
Names a specific verb (encode) and resource (text) and enumerates the four supported encodings, which pins down scope precisely. It implicitly separates itself from hash_text by being a reversible encoding rather than a digest, though it never names siblings explicitly.
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 when-to-use guidance, no exclusions, and no mention of alternatives such as hash_text or a hypothetical decode counterpart. The purpose is inferable, but the agent is left to decide on its own when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a web page (http/https) and return its cleaned readable text, truncated to max_chars.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full http(s) URL to fetch | |
| max_chars | No | Max characters to return (default 12000, max 50000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses two useful traits (text cleaning and truncation), but omits network failure behavior, timeouts, redirects, content-type handling, and whether any auth/headers are supported. Partial disclosure for a no-annotation tool.
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?
One sentence, front-loaded with the verb and resource, and every clause earns its place (protocol restriction, output format, truncation). 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?
For a two-parameter, no-annotation, no-output-schema tool, the description is minimal but adequate. It does not explain failure modes, redirect behavior, or what 'cleaned' entails, which an agent fetching arbitrary pages would plausibly need.
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%: url and max_chars are both fully documented in the schema, including the default and max cap. The description repeats the truncation concept but adds no syntax, format, or edge-case detail beyond the schema. 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 ('Fetch'), resource ('web page'), scope ('http/https'), and output ('cleaned readable text, truncated to max_chars'). This clearly distinguishes it from siblings like html_to_text (which likely converts an HTML string already in hand) and summarize_text.
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 http/https scoping implies a network fetch versus the local-only text utilities in the sibling list, but there is no explicit when-to-use guidance or named alternative (e.g., when to prefer html_to_text for already-retrieved markup). Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the AgentToolbox Terms of Use (as-is, liability-capped). Call this before relying on any tool in production.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does convey the nature of the content and that it is liability-capped, which hints at the legal standing of the response, but it says nothing about the size/format of what is returned or any prerequisites. Adequate but thin for a description-only tool.
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 short sentences: identity first, then the call condition. Every clause earns its place and there is no filler or repetition of schema 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?
With no parameters, no annotations, and no output schema, the description only needs to say what comes back and when to call it, and it does both in compressed form. It could be slightly more complete by indicating return format or size, but nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to document; per the rubric, a 0-param tool baselines at 4. The description correctly implies a no-argument call by never referencing any input.
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 (Read) and a specific resource (the AgentToolbox Terms of Use), with a scope qualifier ('as-is, liability-capped'). Nothing in the sibling list could be confused with it, so an agent can select it without opening a 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?
'Call this before relying on any tool in production' gives an explicit trigger condition, which is unusually clear for a zero-param tool. It stops short of saying when it is unnecessary (e.g., in sandbox or exploratory use), so it is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a cryptographic hash of text (sha-256, sha-384, or sha-512), returned as hex.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| algorithm | No | sha-256 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden: it does disclose the output encoding (hex), which is genuinely useful behavioral context, and algorithm choice is deterministic/one-way by implication. However, it says nothing about determinism guarantees, input encoding (UTF-8?), or whether the input is treated verbatim, which matters for a hashing tool.
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?
One sentence, front-loaded with the verb and resource, with the algorithm options and return format packed into a parenthetical. Nothing is wasted and nothing important is buried.
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 two-parameter, side-effect-free utility with no output schema, the description covers purpose, options, and return format adequately. Minor gaps remain around input encoding and the default-algorithm behavior, which is only visible in the schema's default field.
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%: the `text` parameter has no description and `algorithm` has only an enum and a default. The description restates the three algorithm values already present in the enum and adds output format, but does not clarify the `text` parameter's expected encoding or the default algorithm behavior.
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 ("Compute a cryptographic hash of text"), enumerates the supported algorithms, and specifies the return encoding (hex). It is unambiguous against siblings like encode_text, though it never explicitly contrasts itself with them.
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 choose this tool over alternatives (e.g., encode_text for reversible encoding) and no preconditions or exclusions stated. The purpose is clear enough that usage is inferable, but the description offers nothing explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Strip HTML tags/scripts/styles and return clean readable text.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | ||
| max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It mentions which elements are stripped (tags, scripts, styles) but does not disclose other behaviors such as handling of malformed HTML, entity decoding, or whether output preserves whitespace. It adds some value but falls short of full transparency.
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 sentence, front-loaded with the core action and result, no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and no annotations, the description is minimal but covers the primary function. It omits parameter semantics (especially max_chars) and output details, which would be helpful for an agent to call correctly. It is minimally viable but leaves 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%, so the description must compensate. It does not explain the 'html' parameter or the 'max_chars' parameter (which has a default of 12000). However, the baseline for 0 coverage with 2 params is 3 when the schema covers types; here the schema lacks descriptions, so the description provides no extra meaning, resulting in a low score. But the schema does have defaults, so the description could be worse; still, it adds nothing 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 verb (strip) and resource (HTML tags/scripts/styles) and clarifies the output (clean readable text). This clearly distinguishes it from siblings like markdown_to_html (opposite direction) and fetch_page_text (which fetches rather than converts).
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 purpose implies usage context (converting HTML to text), but there is no explicit when-to-use or when-not-to-use guidance relative to alternatives like fetch_page_text or summarize_text. Adequate but leaves inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate JSON and reformat it: pretty (indented), minify, or custom indent width.
| Name | Required | Description | Default |
|---|---|---|---|
| json | Yes | ||
| style | No | 'pretty', 'minify', or an indent number | pretty |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It never discloses the failure mode on invalid JSON (error vs. diagnostic payload), whether it is a pure read-only transform, or any input size limits — the most important traits for a validator.
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 front-loaded sentence with the action first and the modes enumerated compactly. No filler or restatement of the tool name.
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 no output schema and no annotations, the description should ideally state what is returned (formatted string vs. structured result) and what happens on invalid input. For a two-parameter utility it is workable but leaves the validation outcome ambiguous.
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%: the 'style' parameter is already documented in the schema with almost identical wording, while 'json' has no schema description and none is supplied either. The description adds the useful detail that a custom indent width is a number, but only marginally 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 specific verbs (validate, reformat) and resource (JSON), and enumerates the three output modes. No sibling among the listed utilities (text encoding, hashing, unit conversion, etc.) handles JSON, so no differentiation is needed.
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 three modes imply when each style applies, but the description never states when to choose this tool or how it behaves versus a plain text formatter. Usage is inferable rather than stated, and there are no explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert Markdown to HTML (headings, bold, italic, code, links, lists, quotes).
| Name | Required | Description | Default |
|---|---|---|---|
| markdown | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It usefully scopes supported syntax (headings, bold, italic, code, links, lists, quotes), which tells the agent what input is handled, but it omits whether output is a fragment or full document, how unsupported syntax or malformed input is treated, and whether the operation is pure/side-effect-free.
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 front-loaded sentence with the core verb-resource pair first and the supported-construct list as a compact parenthetical. Nothing is wasted, though the parenthetical could have been spent on more decision-relevant detail.
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, annotation-free, output-schema-free converter, the description covers purpose and supported syntax but leaves return-shape ambiguity (fragment vs. full HTML document) and error behavior unexplained. Adequate but not fully self-sufficient.
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% for the single 'markdown' parameter, so the description must compensate. It implicitly confirms the input is Markdown source text, but adds no detail about expected format, escaping, or size limits beyond the schema's type declaration; the parameter name is self-evident enough that this gap is minor.
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 ('Convert Markdown to HTML') and enumerates the supported constructs, so the agent knows exactly what transformation happens. It does not name the inverse sibling html_to_text, but the direction of conversion is unambiguous from the name 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?
There is no when-to-use or when-not-to-use guidance, and no reference to alternatives such as html_to_text for the reverse direction. Usage is only implied by the tool name.
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 string (for ids, passwords, nonces).
| Name | Required | Description | Default |
|---|---|---|---|
| length | No | ||
| charset | No | alphanumeric, hex, urlsafe, numeric, ascii, or a custom character string | alphanumeric |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose one genuinely important trait: the output is 'cryptographically random', which tells the agent this is a secure generator rather than a weak pseudo-random one. It says nothing about entropy source guarantees, rate limits, or what the returned value looks like beyond being a string.
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 front-loaded sentence with no filler and zero redundancy; purpose and use cases land immediately. It is arguably a touch thin for a tool whose parameters are half-documented, but it is not bloated and 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 no annotations, no output schema, and one of two parameters undocumented, the description should carry more weight than it does. It omits the default length (32), the default charset behavior, and the token's character composition, all of which an agent needs to call it correctly without guessing.
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 50%: the charset enum-ish values are documented but 'length' has no description at all. The tool description never mentions either parameter, so it does not compensate for the gap, leaving the 'length' parameter wholly undocumented across schema and description.
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 ('Generate a cryptographically random token string') plus concrete use cases (ids, passwords, nonces), so the purpose is unambiguous. It does not, however, distinguish itself from the sibling uuid_generate, which is a closely related random-identifier tool an agent could easily confuse it with.
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 parenthetical '(for ids, passwords, nonces)' implies the contexts where this tool fits, which is more than nothing. But it offers no when-not guidance and never mentions uuid_generate or hash_text, the siblings whose territory overlaps most, so the agent is left to infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extractive summary: returns the N most representative sentences of a text, in original order.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| sentences | No | Number of sentences (default 3, max 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the important trait that output is verbatim sentences kept in original order (no rewriting), but says nothing about determinism, input length limits, or cost.
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 sentence with the method stated first and the return shape immediately after. No filler, nothing that fails to earn 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?
There is no output schema or annotation, but the description effectively explains the return value (N sentences, original order), which is the main thing an agent needs. Only minor gaps remain around input size limits and how ties in 'representative' are broken.
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 50%: 'sentences' documents default 3 and max 10, while 'text' is undocumented. The description's 'N most representative sentences' loosely maps N to the sentences parameter but adds no bounds, default, 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 operation (extractive summarization) and resource (text), and disambiguates the method as extractive rather than abstractive. No sibling tool overlaps with summarization, so the agent can route to it unambiguously from the name plus first clause.
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 only implied: the agent infers 'use this to condense text' from the name and the word 'summary'. There is no explicit when-to-use, when-not-to-use, or named alternative among the text-processing siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Text statistics: character/word/sentence counts, reading time, and Flesch reading-ease score.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the output dimensions (counts, reading time, Flesch score), which is genuinely useful behavioral information. However, it omits whether the computation is local/pure, whether the Flesch score assumes English text, or any length limits — meaningful gaps for a no-annotation tool.
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 front-loaded sentence with the resource named first and the outputs enumerated compactly; nothing is redundant. It is dense without being cryptic, though the list-heavy fragment style leaves little room for structure.
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?
There is no output schema and no annotations, so the description usefully compensates by enumerating the returned stats. Given the trivial single-parameter input, what an agent needs to invoke it correctly is essentially covered; only language/edge-case caveats are 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?
One parameter with 0% schema description coverage, so the description must compensate; it only implicitly identifies the input as text and adds no constraints such as maximum length, language, or encoding. The parameter name is self-evident, keeping this at a minimum-viable level.
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 resource (text) and enumerates exactly what is computed: character/word/sentence counts, reading time, and Flesch reading-ease. This clearly separates it from siblings like summarize_text or encode_text. It stops short of naming an alternative, so it is clear but not sibling-differentiating.
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 only implied: an agent can infer you call this when you want metrics rather than a summary, but there is no explicit statement of when to use this versus summarize_text or what conditions make it appropriate. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between units: length (mm/cm/m/km/in/ft/yd/mi), weight (mg/g/kg/oz/lb), temperature (c/f/k), data (b/kb/mb/gb/tb).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It usefully discloses the accepted input vocabulary (the exact unit abbreviations per category), but says nothing about failure behavior for incompatible categories, case sensitivity of tokens, rounding/precision, or the shape of the returned value. For a low-risk pure-computation tool this is a moderate but not fatal gap.
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?
One well-formed sentence, front-loaded with the core action, then the supported domains. Every token earns its place and there is no restatement of the tool name or 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?
With no output schema and no annotations, the description should also indicate the return format and how invalid or cross-category conversions are handled; it does neither. The enumerated unit vocabulary partially compensates, but an agent still has to guess at output type and error semantics.
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 schema gives only the names 'from', 'to', and 'value'. The description compensates well by enumerating the legal string values for the two unit parameters, which is the single most important missing piece. It does not explicitly tie those lists to the 'from'/'to' params, nor state that both must belong to the same category or that 'value' is the numeric quantity.
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), then enumerates the four supported measure families with concrete unit tokens. No sibling in the tool list performs conversion, so selection is unambiguous from the 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?
Usage is only implied by the verb: there is no explicit 'use this when' statement, no note about what happens on cross-category requests (e.g., m to kg), and no alternative tool referenced. Because no sibling overlaps this domain, the implied usage is sufficient to route correctly, but nothing beyond that is offered.
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 values.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many (1-100, default 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does disclose the meaningful trait that values come from a cryptographically random source (vs. e.g. a pseudorandom token). It says nothing about rate limits, output ordering/format, or uniqueness guarantees across calls.
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 front-loaded sentence with zero waste. Appropriate size for a trivial utility tool.
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?
No output schema exists, but the tool is simple: one optional parameter fully documented in the schema and a predictable return shape implied by 'values' (plural). Nothing critical is missing, though stating that a list is returned would close the last 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 100%, so the count parameter (1-100, default 1) is already fully documented in the schema. The description adds nothing about the count behavior, making the baseline 3 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 values) with the added qualifier 'cryptographically random'. It does not explicitly distinguish itself from the sibling random_token, but the resource is specific enough that an agent can tell them 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?
No when-to-use guidance, no mention of when to prefer random_token or hash_text instead, and no exclusions. For a simple generator this is tolerable but the description provides no routing signal to siblings.
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.
date_mathencode_textfetch_page_textget_termshash_texthtml_to_textjson_formatmarkdown_to_htmlrandom_tokensummarize_texttext_statsunit_convertuuid_generate13 micro-tools for agents: read pages, verify email, convert, validate, diff, extract. AI-operated.
Web tools for AI agents: scrape pages to Markdown, audit SEO, detect tech stacks, check sitemaps
13 privacy-first network, auth & web tools for AI agents — no API key, 60 req/min free.
44 tools for AI agents: Trends, SERP, SEO audits, screenshots, weather, FX, whois, RSS.
Add one secure layer between your agents and this server.