Agent Utility Network

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

With no annotations provided, the description carries the burden of behavioral transparency. It discloses determinism and the name-scoped transformation, but does not clarify whether the operation is purely computational with no side effects, what specific normalization rules apply, or how edge cases are handled.

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 concise sentence that front-loads the core operation and key property (deterministic canonical form). There is no redundant or filler content.

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 tool, the basic invocation is clear, but the canonical form is not defined and there is no output schema. An agent cannot predict the exact return value or edge-case behavior, which is a noticeable gap given the lack of 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?

Schema coverage is 0%, but the description defines the sole parameter as an organization/entity name, adding meaning beyond the schema's bare string type. It stops short of a 5 because it gives no examples or details about what forms are acceptable or what 'canonical' means concretely.

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 operation—normalizing an organization/entity name—and a clear outcome: a deterministic canonical form. It is clearly distinguishable from sibling tools by its unique subject and action, even without explicit comparison.

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 clear context: use this tool when an organization/entity name needs to be converted to a canonical, deterministic form. It does not provide explicit exclusions or alternatives, but none of the sibling tools overlap with this purpose, so the guidance is sufficient.

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 bears the full burden of behavioral disclosure. It states the input and output at a high level, but does not explain error handling on unrepairable input, the exact return type, or the scope of transformations applied.

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 sentence with no filler and front-loads the core action and result. Every word contributes to the tool's purpose.

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 tool, the description provides a minimum viable explanation of what the tool does. However, the absence of annotations and output schema means the description should at least hint at error behavior or return format, which it does not.

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 provides 0% description coverage, but the single parameter 'input' is self-explanatory given the tool name and description. The description adds the context that the input is malformed JSON, though it does not elaborate on formatting expectations beyond the schema's string type.

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 uses a specific verb ('Repair') with a clear resource ('common malformed JSON') and states the outcome ('return valid structured JSON'). This clearly distinguishes it from the unrelated sibling tools like entity_normalize and network_capabilities.

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 malformed JSON input needs to be corrected, which is meaningful but not explicit. It does not state when to avoid using it, mention alternatives, or describe limitations such as which malformations are covered by 'common'.

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 and it does add useful behavioral context: the tool's behavior switches based on task presence (recommendation vs catalog listing) and the utilities it surfaces are 'paid', implying commercial implications. But it does not explain what a 'best-fit' result looks like, whether invoking the tool itself incurs cost, or what it returns, which are notable gaps for an unannotated tool.

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 of about 22 words carries both usage modes with zero filler. The primary mode (discover best-fit) is front-loaded and the alternate mode (inspect catalog) follows naturally in the same sentence.

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 2-optional-param tool, the description adequately covers the invocation logic and the role of task. However, with no output schema and no annotations, the return shape is undisclosed and budgetUsd remains unexplained, leaving an agent to guess at both the result format and the budget parameter's semantics.

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 explain both parameters. It effectively documents task ('Describe a task in natural language to discover the best-fit...'), but budgetUsd is never mentioned; the schema only states it is a positive number. Without a budgetUsd explanation, an agent cannot tell whether it is a filter, a constraint on recommendations, or something else.

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 action ('discover the best-fit paid AUN utility') plus an alternate mode ('inspect the full utility catalog'), which clearly identifies what the tool does. It implicitly differentiates from the data-processing siblings (entity_normalize, json_repair, text_extract_signals) as the only discovery/catalog tool. However, the loaded term 'paid AUN utility' is unexplained jargon, so it stops short of a 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 is explicit about the two invocation modes: provide a natural-language task to get a recommendation, or omit it to receive the full catalog. This gives clear decision context on how to call the tool. It does not name alternatives or exclusion conditions relative to the sibling tools, but for a self-contained discovery tool that guidance is less critical.

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 of behavioral disclosure. It clearly states what gets extracted, but it does not disclose the output format, whether all occurrences are returned, how matches are structured, or edge-case behavior for malformed text. Some transparency is present, but significant behavioral details are missing.

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 short, front-loaded sentence that uses no filler. Every word adds meaning by naming the tool's action and the exact signal types extracted.

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 is simple in terms of inputs, and the description makes invocation clear. However, with no output schema and no return-value description, an agent is left to guess what the extraction result looks like. That is a meaningful completeness gap for a tool whose entire value is the structured output it produces.

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 defines text as a min-length string with no description, while the description clarifies that text is the source from which signals are extracted. For a single obvious parameter, this adequately compensates for the 0% schema description 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 names a specific verb ('extract') and resource ('text') and enumerates exactly which signals are produced: URLs, emails, money amounts, and ISO dates. This is specific enough to distinguish the tool from siblings like entity_normalize, json_repair, and network_capabilities, which handle different 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 description implies the tool should be used when a caller needs these signal types pulled out of text, but it never states when not to use it or explicitly contrasts it with alternatives. Usage context is only implicit through the listed extraction targets.

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