drwho.me developer tools

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 discloses the tool's function (decoding) and input types (base64/base64url), but does not mention error handling (e.g., for invalid input), performance, or output specifics beyond UTF-8. This is adequate but lacks rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste—every word contributes to understanding the tool's purpose and usage. It is front-loaded and appropriately sized for a simple 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?

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is mostly complete for basic use. However, it could benefit from mentioning error cases or output details, which are not covered by structured fields, leaving a minor 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?

The schema description coverage is 100%, so the schema already documents the 'input' parameter fully. The description adds minimal value by reiterating the parameter type ('Base64 or base64url string'), but does not provide additional syntax or format details. With high schema coverage, the baseline is 3, but the slight reinforcement earns a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Decode') and resource ('a base64 (or base64url) string'), with the target format ('to UTF-8') precisely defined. It distinguishes from its sibling 'base64_encode' by specifying the opposite operation, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly suggests usage when you have a base64/base64url string and need UTF-8 output, but it does not explicitly state when to use this tool versus alternatives like 'url_decode' or 'jwt_decode' for other encoding types. The context is clear but lacks explicit exclusions or comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It specifies the encoding standard ('standard base64') and input format ('UTF-8 string'), which adds useful context beyond the basic operation. However, it doesn't disclose potential limitations like maximum input size, error handling for invalid UTF-8, or whether the output includes padding characters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes all necessary information without unnecessary elaboration. Every word earns its place in this minimal but complete description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple transformation tool with one parameter (100% schema coverage) and no output schema, the description is reasonably complete. It specifies the transformation type, input format, and output format. However, without annotations or output schema, it could benefit from mentioning what the tool returns (e.g., 'returns the base64-encoded string').

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 fully documents the single 'input' parameter. The description adds marginal value by reinforcing that the input is a 'UTF-8 string' (already in schema) and connecting it to the encoding operation. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('encode') and resource ('UTF-8 string') with the transformation target ('standard base64'). It distinguishes from its sibling 'base64_decode' by specifying encoding rather than decoding, and from other siblings by focusing on base64 encoding specifically.

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 context (when you need to encode a UTF-8 string to base64) and distinguishes from 'base64_decode' by specifying encoding. However, it doesn't provide explicit when-not-to-use guidance or mention alternatives like other encoding methods that might be available.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the method ('via Cloudflare DoH') but doesn't disclose critical traits like rate limits, error handling, response format, or whether it's a read-only operation (implied but not stated). This leaves significant gaps for agent understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. Every word earns its place by specifying the action, resource, and method concisely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup tool with no output schema and no annotations, the description is minimally adequate. It covers the basic purpose and method but lacks details on return values, error conditions, or operational constraints, leaving the agent with incomplete context for reliable use.

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%, with clear parameter documentation in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., no examples or edge cases), so it meets the baseline for high schema coverage without compensating value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Resolve a DNS record') and resource (DNS records via Cloudflare DoH), listing the exact record types supported. It distinguishes itself from siblings like ip_lookup by specifying DNS resolution rather than IP geolocation or other data transformations.

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 guidance is provided on when to use this tool versus alternatives. While it implicitly suggests usage for DNS resolution, there's no mention of prerequisites (e.g., internet connectivity), limitations (e.g., rate limits), or comparisons to other DNS tools that might exist elsewhere.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the external service provider ('ipinfo.io'), which is useful context for rate limits or reliability. However, it doesn't mention authentication needs, rate limits, error handling, or whether this is a read-only operation, leaving behavioral gaps for a tool that makes external API 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?

The description is a single, well-structured sentence that efficiently conveys purpose, input, output, and service provider without any wasted words. It's appropriately sized and front-loaded with the core action.

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 no annotations and no output schema, the description covers the basic purpose and return data types adequately. However, for a tool that interacts with an external API (ipinfo.io), it lacks details on error responses, rate limits, or output structure, which would help an agent use it more effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already documents the single parameter 'ip' as an IPv4 or IPv6 address. The description adds value by reinforcing the input types and linking it to the lookup purpose, but doesn't provide additional syntax or format details beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Look up') and resource ('an IP address'), specifies the input types ('v4 or v6'), and lists the exact return data ('geolocation, ASN, and ISP'). It also distinguishes from siblings by mentioning the specific service provider ('via ipinfo.io'), which none of the other tools reference.

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 context by specifying the input types and return data, helping an agent understand when this tool is appropriate. However, it doesn't explicitly state when not to use it or name alternatives among siblings (e.g., dns_lookup for domain resolution), missing full comparative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns a 'pretty-printed string or a parse error,' which covers basic output behavior, but lacks details on error handling (e.g., error format), performance (e.g., size limits), or side effects. This is insufficient for a tool with potential validation complexities.

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 extremely concise and front-loaded, consisting of a single sentence that directly states the tool's function and output. Every word earns its place, with no redundant or vague language, making it efficient for quick comprehension by an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (JSON formatting/validation), no annotations, and no output schema, the description is minimally adequate. It covers the core purpose and output types but lacks details on error formats, input constraints, or usage context. This is the bare minimum for such a tool, scoring a 3.

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 fully documents both parameters (input and indent). The description adds no additional parameter semantics beyond what the schema provides, such as examples of valid JSON input or implications of indent choices. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('format and validate JSON') and resource ('JSON'), distinguishing it from sibling tools like base64_encode or uuid_generate. However, it doesn't explicitly differentiate from potential similar JSON tools that might exist elsewhere, keeping it at 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like debugging JSON data, preparing JSON for display, or validating user input, nor does it reference sibling tools or other JSON-related operations. This leaves the agent without context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it decodes into three parts and explicitly states it does not verify the signature, which is crucial for understanding its limitations. However, it lacks details on error handling, output format, or performance aspects like rate limits.

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 front-loaded with the core purpose in the first sentence and adds a critical limitation in the second. Both sentences earn their place by providing essential information without waste, making it efficient and well-structured.

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 the tool's low complexity (one parameter, no output schema, no annotations), the description is mostly complete: it explains what the tool does and its key limitation. However, it could benefit from mentioning the output structure (e.g., JSON objects for header/payload) or error cases, leaving minor gaps in contextual detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single required parameter 'token' as a JWT compact serialization. The description does not add meaning beyond this, as it doesn't provide additional syntax or format details. Baseline 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Decode a JWT') and the exact output ('into its header, payload, and signature parts'), distinguishing it from siblings like base64_decode or json_format by focusing on JWT structure. It also explicitly notes what it does NOT do ('Does NOT verify the signature'), which further clarifies its scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (to decode a JWT without verification), but it does not explicitly mention when NOT to use it or name alternatives (e.g., for signature verification). Given the sibling tools, it's implied this is for JWT-specific decoding, but no explicit exclusions or comparisons are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the operation but doesn't mention error handling (e.g., for invalid encoding), performance characteristics, or what happens with malformed input. For a tool with no annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized for a simple tool and front-loads the essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is adequate but minimal. It covers the basic operation but lacks details on error cases or output format, which could be helpful for an agent. The absence of an output schema means the description should ideally hint at return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with the parameter 'input' clearly documented as a 'Percent-encoded string'. The description doesn't add any additional parameter semantics beyond what the schema already provides, so it meets the baseline for high schema coverage without extra value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Decode') and resource ('percent-encoded URL component'), making it immediately understandable. However, it doesn't explicitly differentiate from its sibling 'url_encode' beyond the obvious decode/encode distinction, which prevents a perfect score.

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 for percent-encoded URL components but doesn't provide explicit guidance on when to use this tool versus alternatives like 'base64_decode' or 'url_encode'. No when-not-to-use scenarios or prerequisites are mentioned, leaving usage context somewhat vague.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 discloses the core behavior (percent-encoding for URLs) but lacks details on encoding standards (e.g., RFC 3986), handling of special characters, error conditions, or output format. The description is accurate but minimal, leaving behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the purpose ('Percent-encode a string') and adds necessary context ('for use in a URL component'). Every word earns its place with zero waste, making it highly concise and well-structured.

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 the tool's low complexity (one parameter, no annotations, no output schema), the description is reasonably complete for basic use. It covers the what and why, but lacks details on encoding behavior or output. For a simple utility tool, this is adequate though not exhaustive.

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%, with the parameter 'input' documented as 'String to encode'. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('percent-encode') and resource ('a string'), with the explicit purpose 'for use in a URL component'. It distinguishes from sibling tools like 'url_decode' by specifying encoding rather than decoding, and from 'base64_encode' by focusing on URL-specific encoding.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool ('for use in a URL component'), which implicitly suggests alternatives like 'base64_encode' for non-URL contexts or 'url_decode' for the reverse operation. However, it does not explicitly state when NOT to use it or name specific alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 mentions parsing into components but does not disclose behavioral traits such as error handling (e.g., for invalid input), performance characteristics, or output format details. This leaves gaps in understanding how the tool behaves beyond its basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the purpose and key details without any wasted words. It is appropriately sized for a simple tool with one parameter, making it easy to understand quickly.

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 the tool's low complexity (one parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and output components but lacks details on behavioral aspects and error handling, which are important for a parsing tool. This results in a minimal viable description with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with the parameter 'ua' clearly documented as 'User-Agent header value'. The description adds no additional meaning beyond this, as it does not elaborate on parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('parse') and the resource ('User-Agent string'), with explicit details about the output components ('browser, OS, device, and engine components'). It distinguishes this tool from siblings like base64_decode or url_encode by focusing on user-agent analysis rather than data transformation or encoding/decoding.

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 when a User-Agent string needs parsing, but it does not provide explicit guidance on when to use this tool versus alternatives or any exclusions. Given the sibling tools are unrelated (e.g., encoding/decoding, DNS lookup), the context is clear but lacks detailed comparative advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose any behavioral traits like performance characteristics, error handling, or whether generation is deterministic or has side effects (e.g., network 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?

The description is a single, efficient sentence with zero waste—it directly states the tool's purpose and key details (v4/v7). It's appropriately sized and front-loaded, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is complete enough for basic use. However, it lacks details on output format (e.g., string representation) and behavioral context, which could be helpful despite the simplicity.

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 fully documents the single 'version' parameter with enum values. The description adds minimal value by mentioning v4 and v7, but doesn't provide additional semantics beyond what the schema specifies (e.g., differences between versions).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Generate') and resource ('UUID'), specifying both v4 (random) and v7 (time-ordered) variants. It distinguishes from sibling tools like base64_encode or json_format by focusing exclusively on UUID generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by mentioning both UUID versions (v4 for random, v7 for time-ordered), which suggests when to choose each. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., no mention of why UUIDs are needed over other identifiers) or any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.