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

No annotations exist, so the description carries the full burden, and it does disclose meaningful operational behavior: a $0.01 per-call charge in USDC on Base (eip155:8453) settled via x402 in params._meta["x402/payment"], plus the HTTP endpoint. That payment requirement is critical context an agent would otherwise miss. However, it says nothing about defaults for missing inputs, timezone handling, error behavior, or output shape, leaving significant behavioral gaps for a zero-annotation 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?

The text is front-loaded with the purpose, then pricing, then transport, and every sentence is load-bearing with no filler. It is compact and scannable, though the pricing/payment sentence is dense with identifiers that could be split for readability.

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, and the description does at least characterize the result (minutes remaining plus an in-business-hours flag) and the payment requirement, which covers a lot for a paid endpoint. What is missing is any semantics for the three optional inputs and any statement of defaults, which matters because nothing is required and an agent must guess how to call it.

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% with three string parameters (tz, from, promise) and no required fields, so the description must compensate and largely does not. 'Promise deadline' loosely maps to the `promise` param and business-hours framing hints at `tz`, but `from` (presumably the start instant) and the format/format-of dates expected for `promise` and `from` are never explained, nor is what happens when they are omitted.

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 resource (business-hours SLA maths) and its two outputs: business minutes remaining to a promise deadline and whether that deadline falls inside business hours. The verb is implicit ('compute') but the resource and result are precise enough that an agent knows exactly what comes back. It does not name sibling alternatives (agentkit__deadlines, bizcal_api__workdays), so it falls short of full differentiation.

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, no prerequisite statement, and no routing to alternatives such as agentkit__deadlines or bizcal_api__workdays despite several siblings covering overlapping calendar/deadline territory. The purpose sentence lets an agent infer the use case, but nothing explicit is offered.

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