textkit (paid)

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

With no annotations, the description carries the full burden. It does add genuinely useful behavioral context that structured data lacks: the tool is paid ($0.005 per call) and the payment rail (USDC on Base). However, it stays silent on whether holidays are excluded, how invalid/reversed dates behave, and what the result looks like.

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 that front-loads the operation and appends the pricing detail in parentheses. Zero wasted words.

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 paid utility with no annotations, no output schema, and 0% parameter documentation, the description is too thin — date format, boundary inclusivity, holiday handling, and return type are all unaddressed.

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% — both 'from' and 'to' are untyped, undescribed properties. The description only says 'between two dates' and never specifies the accepted date format (ISO 8601, epoch, etc.) or whether the bounds are inclusive, so it fails to compensate for the coverage gap.

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 (count) and resource (business days) plus the scope qualifier (between two dates, weekends excluded). This cleanly distinguishes it from sibling tk_describeDate, which operates on a single date rather than a range.

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, when-not-to-use, or alternative guidance is given. An agent can infer the purpose is a date-range computation, but nothing states prerequisites or when a sibling would be preferred.

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 supplied, so the description carries the full disclosure burden. It does add a genuinely useful non-obvious trait: the tool is paid ($0.005 per call, USDC on Base), which an agent needs before invoking. However, it says nothing about determinism, invalid-date handling (e.g., Feb 30), or timezone assumptions.

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 tight sentence that front-loads the purpose, then the output fields, then the pricing. Nothing is redundant and no sentence 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?

With no output schema and no annotations, the description compensates well by listing all returned fields and disclosing the payment model. The remaining gap is input validity behavior and parameter conventions, which leaves it just short of fully self-contained.

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 three required numeric parameters, and the description adds no format or range detail beyond implying they form a calendar date. An agent cannot tell from the text whether month is 1-12 or a name, or whether day is 1-31, so the description does not compensate for the coverage gap.

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 gives a specific verb and resource ('Describe a calendar date') and enumerates the exact outputs (weekday, ISO week, day of year, quarter, leap year, weekend), which makes the tool's function unambiguous. It does not explicitly contrast itself with the nearest sibling tk_businessDays, but the listed return fields make the boundary inferable.

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 explicit when-to-use or when-not-to-use statement and no named alternative. Usage is only implied by the enumerated output fields, which suggest the tool is for deriving calendar metadata from a date. Adequate for a simple pure-computation utility, but no routing guidance is provided.

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 does disclose a genuinely useful non-schema behavior: it is a paid call ($0.005 per call, USDC on Base). It says nothing about ambiguous-result handling, error behavior for non-byte input, or what happens with empty/invalid arrays.

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 front-loaded sentence that leads with the verb and resource, then the concrete output set, then cost. Nothing is wasted, though appending the pricing clause in the same sentence slightly muddies the single-purpose read.

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 single-parameter, no-output-schema utility, the description covers purpose, the set of possible results, and the payment requirement, which is essentially everything an agent needs to invoke it. Minor gaps are the lack of any note on ambiguity or failure modes.

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% for the single 'bytes' parameter, so the schema already documents it; baseline 3 applies. The description adds only mild nuance by framing it as a 'byte string' rather than an array.

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+resource ('Detect the encoding of a byte string') and enumerates the candidate encodings it can return, which makes the operation concrete. It does not explicitly distinguish itself from the closest sibling, tk_detectFormat, so an agent still has to infer the boundary between encoding detection and format 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 only implied: the enumerated encoding list and the 'byte string' input hint at when it applies, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. tk_detectFormat). For a one-shot utility this is adequate but leaves the agent to infer routing.

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. It does disclose genuine operational context that annotations could not: this is a paid tool costing $0.005 per call settled in USDC on Base, which matters for an agent deciding whether to invoke it. However, it says nothing about the return shape, behavior on unrecognized input, or the full set of detected formats ('and more' is left undefined).

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 front-loaded sentence: the verb and resource come first, the format list sharpens scope, and the pricing parenthetical is a compact and relevant trailing detail. Nothing is redundant or padded.

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 should clarify what is returned (e.g., a format label, null when unrecognized). It also leaves the detectable set open-ended with 'and more', which limits the agent's ability to predict results. Adequate to call the tool, but not complete for a classifier with zero structured return documentation.

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% and the single 'value' parameter has no description, so the description must compensate. The enumeration of detectable formats does tell the agent what kinds of string values are meaningful inputs, but it adds no syntax, length, or format-constraint detail beyond the obviously-named string 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?

States a specific verb (Detect) and resource (the format of a string) and enumerates the detectable formats (uuid, email, url, jwt, iban, semver, etc.), which cleanly separates it from sibling tools like tk_detectEncoding and tk_scriptDetect. An agent cannot confuse this with any other sibling.

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 and no mention of alternatives, despite close siblings such as tk_detectEncoding and tk_scriptDetect that also classify input strings. The only usage signal is the implied 'give me a string, get its format', which leaves the agent to infer routing.

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 usefully discloses pricing ('$0.003 per call, USDC on Base'), which is a behavioral trait, but it does not describe the return format, edge-case handling, or Unicode behavior for a tool with no output schema.

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 front-loaded sentence that includes the core operation, unit, and cost with no filler. Every clause contributes useful 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?

For a simple one-parameter computation, the description explains the metric and cost but omits what the return value looks like and how edge cases are handled. Without an output schema or annotations, those gaps leave the definition only minimally complete.

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% and there is one required parameter, 'text'. The description only implies that the input is a string, without adding constraints, encoding expectations, or examples that would compensate for the empty schema documentation.

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 computation ('Shannon entropy') on a specific resource ('a string') with a clear unit ('bits per character'). It does not explicitly differentiate from sibling text utilities, though the operation is distinct enough that confusion is unlikely.

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 use this tool versus alternatives, nor any prerequisites or exclusions. The description only explains what it computes, not the context in which an agent should select it.

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 burden. It usefully discloses cost and payment mechanism ('$0.003 per call, USDC on Base') and that it is dependency-free and deterministic ('stable'), which is real behavioral context. However, it omits error behavior, whether both 32 and 64-bit digests are always returned, and any authentication/payment prerequisites.

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 efficient, front-loaded sentence with no waste; the core purpose leads and the pricing detail trails. The parenthetical pricing is slightly extraneous to the operation itself but still earns its place as cost disclosure.

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 hashing tool with no output schema, the description covers the essentials, but it leaves ambiguity about whether both bit-widths are returned and in what format. The payment model is mentioned but not explained as a prerequisite.

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 0%, so the description must compensate, but the single parameter 'text' is fairly self-evident. The description adds nothing about its format, encoding expectations, or size limits, leaving the schema to carry it.

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 verb and resource ('Compute a stable FNV-1a content fingerprint') plus the output variants (32 and 64 bit). No sibling tool performs hashing, so it is inherently distinguished, though it does not explicitly contrast itself with the other token utilities.

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 use this tool versus the many sibling utilities (e.g. tk_entropy, tk_detectFormat). The description states what it does but never addresses selection context or prerequisites beyond implying payment.

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 behavioral burden. It helpfully discloses cost ($0.003/call, USDC on Base), but says nothing about output format, handling of malformed input, or limits, leaving the mutation/read profile and return structure unstated.

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 naming the core function first and appending the cost detail. Nothing is wasted, though the parenthetical pricing slightly dilutes the core purpose statement.

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 one-parameter counting utility with no annotations or output schema, the description covers the essential purpose and metrics. It stops short of explaining what the response contains (individual counts per unit) and any behavioral constraints, which would matter for autonomous 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?

There is a single parameter ("text") with 0% schema description coverage, so the description must compensate. The phrasing implies the input is the string to measure, which is nearly self-evident for a counting tool, but the parameter name is never explicitly tied to its meaning or format.

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 clear verb ("Count") and a specific resource ("user-perceived characters (graphemes)"), and even clarifies the multiple metrics produced (vs. code points, UTF-16 units, bytes). It is distinguishable from near siblings like tk_unicodeNormalize and tk_detectEncoding, though it never names them 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?

The description gives no guidance on when to reach for this tool versus alternatives such as tk_detectEncoding or tk_scriptDetect, nor any prerequisites. The only ancillary info is pricing, which is not usage 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. It does add genuinely useful non-obvious context by disclosing the cost model ($0.005 per call, USDC on Base), but it never states what happens to non-homoglyph Unicode, whether the fold is lossy, or the output format.

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 compact sentence that front-loads the action and resource, then adds purpose and pricing. No filler or repetition; every clause carries 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?

For a one-parameter utility with no output schema, no nested objects, and no annotations, the description covers the essential action, output direction (to ASCII), and cost. It could say slightly more about return format and handling of unmapped characters, but it is largely 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 100% for the single 'text' parameter, so the schema already documents the input. The description adds no syntax, encoding, or format detail beyond what the schema provides, 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 (fold), resource (Unicode homoglyphs) and the outcome (ASCII output to detect spoofed domains/usernames/handles). It is clearly distinguishable from most siblings, though it does not explicitly separate itself from the related tk_unicodeNormalize tool, which could plausibly also map lookalike characters.

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 stated goal of detecting spoofed domains, usernames and handles; there is no explicit 'use this when' or 'use X instead' guidance. The presence of tk_unicodeNormalize and tk_scriptDetect among siblings makes the missing routing guidance a real gap.

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 behavioral burden. It usefully discloses the cost model ($0.003 per call, USDC on Base), which is important beyond the schema, but it omits whether the function is pure/side-effect-free, how invalid input is handled, and any authentication requirements beyond payment.

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 redundant clauses. The cost parenthetical is compact and earns its place by conveying billing 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?

For a simple formatting utility with no output schema, the description does state the output style ('KB and MiB values'), which is helpful. However, it leaves the input parameter type unclarified and does not explain edge cases, so it is only minimally complete.

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%, and the single parameter 'bytes' is completely undocumented in the schema. The description only repeats 'a byte count' without specifying type, units, sign handling, or allowed format, adding almost no meaning beyond the parameter 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 specific verb ('Format') and resource ('a byte count') and names the output format ('human-readable size with KB and MiB values'). This is clear enough to distinguish it from all sibling utilities like tk_detectEncoding or tk_graphemeCount.

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 explains what the tool does but gives no guidance on when to use it versus alternatives, nor any preconditions or exclusions. Usage is only implied by the verb 'Format'.

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 burden. It does disclose a genuinely useful behavioral fact — a per-call cost of $0.005 in USDC on Base — but says nothing about what 'flag' returns (boolean? list?), whether results are deterministic, or the read-only nature of the operation.

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 zero waste, front-loading the core capability and appending the pricing caveat last. 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?

No output schema exists, so the description should say what a caller receives; it never explains whether the result is a script list, a spoofing verdict, or both. Pricing and purpose are covered, so it is usable but incomplete 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?

Only one parameter and schema description coverage is 100%, so the schema already documents 'text to analyse' fully; the baseline 3 applies. The description adds no format or syntax guidance beyond what the schema provides.

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+resource ('Detect which Unicode scripts a string uses') plus a concrete second capability ('flag mixed-script spoofing'). It is distinguishable from most siblings, though it never mentions the closely-related tk_homoglyphFold or tk_unicodeNormalize, so the boundary with those is left to inference.

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 prerequisites, and no named alternatives among the many text-analysis siblings (homoglyphFold, unicodeNormalize, detectEncoding). The spoofing phrase hints at a security use case, but nothing tells the agent when this tool beats its neighbours.

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 burden. It does disclose two real behavioral traits — accent stripping and per-call cost ($0.003, USDC on Base) — which is genuinely beyond the schema. However it is silent on what maxLength actually does (truncate, word-boundary trim, or error), how the separator interacts with existing punctuation, and what the return value looks like.

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 that front-loads the core action and packs the two modifying behaviors plus pricing into one readable clause. No filler, no repetition 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?

No output schema and no annotations mean the description is the only source of behavioral context, and for a four-parameter tool it leaves gaps: the effect of maxLength on output shaping, separator interaction, and the return type. It is adequate for a simple deterministic transform, but not complete.

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%: 'lowercase' and 'separator' only carry default hints, while 'text' and 'maxLength' have no schema description at all. The description compensates for maxLength's semantics ('optional length limit') and covers the accent-stripping behavior tied to text, but says nothing about lowercase or separator, leaving the 3-baseline appropriate rather than exceeded.

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 concrete verb and resource ('Convert a title into a clean URL slug') plus two specific behaviors: accent stripping and an optional length limit. That is enough for an agent to know exactly what comes out, though it never distinguishes itself from the closest neighbor, tk_unicodeNormalize, which also touches accent/diacritic handling.

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; the input type ('a title') is the only implicit cue about context. No alternative tool is named, and nothing tells the agent how this differs from tk_unicodeNormalize or tk_homoglyphFold for text-mangling tasks.

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 burden. It usefully discloses output behavior ('report the first differing position') and a per-call price with payment chain ($0.003 per call, USDC on Base), which is uncommon and valuable context, but it says nothing about error conditions, pure-function guarantees, or how payment is authorized.

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: operation, options, output, and cost. Nothing is redundant and nothing buries the lead.

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 text utility with no output schema, the description covers the operation, the option set, one aspect of the return value, and pricing. It stops short of describing the full response shape, but that is a minor gap for a simple transformation 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?

Schema coverage is only 50% and the schema itself has no enum for 'form' — the description supplies the concrete valid values (NFC, NFD, NFKC, NFKD), which is real added meaning. 'text' remains undocumented but is self-evident from the description's 'Normalize text'.

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 precise verb and resource ('Normalize text') and enumerates the four normalization forms, plus what it reports back. It does not explicitly name or distinguish itself from siblings like tk_homoglyphFold or tk_slugify, but the operation is 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?

There is no guidance on when to choose this tool versus alternatives such as tk_homoglyphFold or tk_slugify, and no guidance on which of the four forms to pick or when not to use it. Usage must be inferred entirely from the name.

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