hash_md5Hash text to an MD5 hex digest. Useful for checksums, cache keys, dedupe keys, and Gravatar-style identifiers. MD5 is broken for anything security-related: never use it for passwords or to verify authenticity.
Returns { md5, algorithm, bytes }. Limit: None. The work is local and costs nothing.. Allow up to 10s for a response. Free, no account, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to hash. Up to 1 MB of UTF-8. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full responsibility and does well: it discloses the return format ('Returns { md5, algorithm, bytes }'), clarifies limits ('Limit: None'), and notes it's 'Free, no account, no API key.' However, it contains a minor inconsistency with 'The work is local' yet 'Allow up to 10s for a response,' which could confuse—hence not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively compact but includes a couple of typos ('costs nothing..' with double period) and somewhat redundant notes about being free. It front-loads the core purpose and adds valuable context, but could be tightened without loss.
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 all necessary context for a tool of this simplicity: purpose, use cases, security warning, return value structure, limits, and pricing/authentication requirements. It is complete given the small schema and lack of output schema.
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% (only 'text' parameter, described as 'The text to hash. Up to 1 MB of UTF-8'). The description adds no further semantics about the parameter beyond restating 'Hash text,' 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?
The description opens with 'Hash text to an MD5 hex digest,' which clearly states what the tool does with a specific verb and resource. It further elaborates with use cases like checksums and cache keys, making its purpose unmistakable. Though siblings are unrelated, the description's clarity stands independently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (checksums, cache keys, dedupe keys) and, crucially, when not to: 'MD5 is broken for anything security-related: never use it for passwords or to verify authenticity.' This provides clear usage boundaries and appropriate alternatives (though not naming other tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct, specific purpose. Overlapping check tools (AI visibility vs robots) are explicitly differentiated with clear guidance on when to use each. Generate vs validate JSON-LD, screenshot vs markdown conversion, and other similar-sounding tools are all clearly separated by their descriptions.
Most tools follow the verb_noun pattern (build_, capture_, check_, detect_, generate_, hash_, validate_), but page_to_markdown breaks the convention with a noun-based name instead of a verb-noun form. This outlier creates a minor inconsistency in an otherwise predictable naming scheme.
13 tools is well within the recommended 3-15 range. Each tool provides a distinct, useful capability for web analysis, content generation, or conversion, and none feel redundant. The count is well-scoped for a 'free tools' server without being overwhelming.
The set covers a broad spectrum of web utilities: URL construction, screenshots, various checks (favicon, robots, social preview, AI visibility), tech detection, content generation (alt text, JSON-LD, llms.txt), and text conversion (markdown, hashing). Minor gaps such as a link checker or performance test exist, but the overall coverage is comprehensive for its intended audience.