Internet Janitor

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It explains meaningful edge-case behavior: scanning up to 20 non-empty rows and ignoring delimiters inside double quotes. It does not describe the output format or behavior when delimiters are ambiguous, but the core behavior is transparent.

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, tightly worded sentence that front-loads the main action and includes the most important constraints without unnecessary 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?

The tool has no output schema, no annotations, and only one parameter, so the description must carry more weight. It covers the input scope and key parsing behavior, but does not explain what the tool returns, how ambiguous cases are resolved, or what happens when no delimiter is found. These are relevant gaps for a detection tool.

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 only documents a string 'input' with a maxLength, providing no semantic detail. The description compensates partially by implying that input is text consisting of rows with delimiters and quoted content, but it does not explicitly describe the parameter's role or format beyond that.

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 identifies the tool's action ('Detect') and the specific resource (comma, semicolon, tab, or pipe delimiters). It also distinguishes the tool from its sibling normalization/filename tools, since none of those perform delimiter detection.

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 rather than explicitly stated: the tool detects delimiters in tabular text, which suggests when it should be used. However, it does not provide explicit guidance about when to choose it over alternatives or when it would be inappropriate to use.

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 burden. It openly states the tool will analyze data and point to another tool, implying no direct mutation. It could add detail on output format or what happens when no problem is found, but the core diagnostic behavior is clearly disclosed.

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 with no waste. The user-facing trigger is front-loaded and the behavior is stated immediately.

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 single-input diagnostic tool with no output schema, the description explains what it does and what it returns at a high level (a diagnosis and a pointer to a fixer). It does not enumerate possible output details, but it is sufficient for an agent to select and invoke the tool.

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?

There is one parameter with 0% schema description coverage, so the description must compensate. 'Show me the problematic data' clearly maps the `input` parameter to the data to be diagnosed, giving it meaning beyond the generic schema name.

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 clear diagnostic purpose: accept problematic data, identify likely formatting problems, and recommend a fixer tool. It distinguishes itself from sibling normalization/detection tools by being the diagnostic router rather than the fixer, though it does not name 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?

It establishes a clear trigger ('Something isn't working? Show me the problematic data') and indicates that the tool will route to a deterministic fixer. It does not explicitly state when not to use it or name alternatives, but the routing behavior implies that known, specific issues should go to the sibling fixer 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 full responsibility for explaining behavior. It lists accepted input forms but does not disclose the canonical output format, handling of unrecognized values, case sensitivity, or error behavior.

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, compact sentence that front-loads the purpose and immediately provides concrete examples. There is no redundant wording or unnecessary repetition of schema details.

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 single-parameter tool, the description is usable, but it is not fully complete. An agent can confidently pass a boolean-like string, yet it will not know what canonical form will be returned or what happens for invalid input, especially with no output schema or annotations.

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 only says input is a string; the description adds valuable examples of accepted representations like yes/no, on/off, and 1/0. However, with 0% schema coverage, it should also clarify normalization direction and edge cases, which it does not.

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 names a specific operation ('Normalize') and a specific resource ('boolean representations'), and gives concrete example inputs. This makes it clearly distinguishable from siblings like normalize-decimal and normalize-whitespace.

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 the tool should be used when input is a boolean-like string such as yes/no or 1/0. However, it does not explicitly say when not to use it or how to choose among sibling normalization 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?

The description discloses a non-obvious rule for ambiguous single separators followed by three digits, but uses the vague term 'flagged' without explaining the resulting behavior (error, marker, or special output). With no annotations, this ambiguity is a notable gap in 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?

Two sentences with zero filler: the first sentence front-loads the core transformation, and the second adds a relevant edge-case behavior. Every clause contributes meaning.

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 the main operation and one edge case, but it leaves unresolved the meaning of 'flagged' and does not describe return format or error behavior. Since there is no output schema and no annotations, these omissions limit the agent's ability to handle all outcomes 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?

With 0% schema description coverage, the description compensates by indicating the input is a US/EU decimal representation and that normalization applies to it. It does not explicitly name the parameter or provide examples, but the semantic intent is inferable and much richer than the bare 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 ('Normalize') and resource ('common US/EU decimal representations') with a defined output ('dot-decimal string'). This clearly differentiates it from siblings like normalize-boolean and normalize-whitespace, which target different data types.

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 decimal strings need conversion to dot-decimal format. However, it provides no explicit mention of when to use this tool over alternatives or any exclusions, leaving the agent to infer context.

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, the description carries the full behavioral burden and clearly states what will happen: repeated whitespace becomes one space and leading/trailing whitespace is removed. It could be more specific about which whitespace characters are included, but the core behavior is transparent.

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 one efficient sentence with no filler. The primary action is front-loaded, and every word contributes to understanding the tool's behavior.

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 one-parameter string transformation with no output schema and no annotations, the description is nearly complete. It omits only minor edge-case details such as the exact definition of whitespace, but the core input/output contract is clear.

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%, but the description effectively compensates by explaining exactly how the single 'input' string will be modified. It adds meaning beyond the plain string/maxLength schema, even though it does not explicitly name the parameter.

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 ('collapse repeated whitespace to one space and trim') and a clear resource (the input string). It unambiguously distinguishes this tool from siblings like detect-delimiter or normalize-boolean, which operate on different data aspects.

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 intended use is implied: call this when whitespace needs to be normalized. However, the description does not explicitly state when to prefer this over siblings or mention any exclusions, leaving the agent to infer the context.

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, the description carries the behavioral burden and does a reasonable job: it discloses the key transformation target and explicitly calls out reserved device-name protection. It does not specify details like which characters are replaced or how trailing dots/spaces are handled, but for a single-purpose conversion utility the main behavioral surprise is disclosed.

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 contains the core purpose and the most important edge-case behavior with no filler. Highly efficient and 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?

For a simple one-parameter transformation tool with no output schema, the description covers the essential context: input, target platform, and a critical safeguard. Minor gaps such as return-value format and exact sanitization behavior would improve completeness, but the tool's low complexity makes this sufficient for correct 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. It refers to 'a string' as the conversion input, matching the single 'input' parameter, and hints that the input may include reserved device names. It does not add meaningful constraint details beyond the schema, but with only one self-explanatory parameter the semantics are adequate.

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?

Description states a specific verb ('Convert') and resource ('a string into a Windows-safe filename'), with a distinctive edge case ('reserved device-name protection'). It is clearly differentiated from the normalize-* siblings, which operate on different data concerns.

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 tool's intended use is clear: any time a Windows-safe filename is needed. It does not name alternatives or explicitly state when not to use it, but sibling tools are sufficiently different that the decision is obvious from the purpose.

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