Compute a SHA-1 / SHA-256 / SHA-512 hex digest of UTF-8 text.
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"input": "<input>"
},
"name": "hash_text"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| algorithm | No | SHA-256 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose the two key behavioral facts an agent needs: the output is a hex digest string and the input is treated as UTF-8 text (deterministic, no side effects implied). It does not state that the operation is stateless/read-only or mention the default algorithm, but for a pure local computation the remaining gaps are minor.
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; the verb, the resource, the algorithm set, and the output format all land in one pass.
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 description itself explains the return value (hex digest), and both parameters are covered, which is enough for a two-parameter pure function. The unstated default algorithm and the unaddressed sha256_hash overlap are the only real omissions.
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 largely does, naming all three algorithm values and the UTF-8 text encoding of the input, covering both parameters. The only omissions are the SHA-256 default and the absence of a parameter/field mapping (e.g. that 'algorithm' is optional).
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 ... hex digest of UTF-8 text') plus the exact output form, which clearly separates it from siblings like base64_encode or uuid_generate. It does not, however, acknowledge the overlapping sibling sha256_hash, so the agent gets no help choosing between the two.
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 at all. With a sibling named sha256_hash sitting in the same toolkit, the single most useful sentence here would have been 'use this instead of sha256_hash when you need SHA-1 or SHA-512', and it is absent.
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.