DepTime

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered; the description adds useful context by enumerating what the response contains (present/missing per symbol, rejected kwargs, deprecation notes, hints) and pinning the check to the installed version. It stops short of stating limits or edge behavior for invalid dotted paths, so not a full 5.

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?

Three tight sentences: capability first, return contents second, routing third. No filler, and the most decision-relevant information (what it checks, what it returns) is front-loaded before the sibling routing.

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 a full output schema, complete parameter descriptions and annotations covering safety, the description only needs to fix scope and routing — which it does. It makes clear the target is the installed version and that results are per-symbol, leaving nothing an agent needs ambiguous before calling.

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% and all three parameters are documented inline, including the 100-symbol cap and dotted-path examples, so the baseline is 3. The description only restates that kwargs are the ones you 'plan to pass' and that checking is batched — no additional syntax, format or constraint guidance beyond the 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?

The description opens with a specific verb and scope: 'Batch-check that symbols, and the keyword arguments you plan to pass, exist in a specific version of a package.' That is a precise verb (batch-check) plus two resources (symbols, kwargs) qualified by version, which an agent can immediately distinguish from diff_versions or coverage.

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 names the canonical use case ('preflight code against the version you have installed') and routes to two named alternatives with the conditions that select them: symbol_history for one symbol across all releases, explain_error after an exception. This is explicit when-to-use plus alternatives, exactly the top of the scale.

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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: it takes no arguments and absence from the list means DepTime cannot answer about that package — a useful precondition an agent couldn't infer from annotations.

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?

Three short sentences, each earning its place: purpose first, then the failure implication, then the calling guidance. Nothing is padded or redundant.

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?

An output schema exists so return shape needn't be described, annotations carry the safety profile, and there are no parameters. The description supplies exactly the missing pieces — scope and the consequence of a package being absent.

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?

Zero parameters, so the baseline of 4 applies; the description confirms 'takes no arguments,' matching the empty schema. No additional parameter meaning is needed.

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 and resource: 'Lists indexed packages and version ranges,' which is a distinct object from what siblings like symbol_history or diff_versions operate on. It's clear, but it never names a sibling to explicitly differentiate itself, so it falls 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?

'Takes no arguments; call it first when unsure whether a package is covered' gives a concrete usage trigger, and the missing-package warning explains the consequence of skipping it. There's no explicit when-not-to-use or named alternative, so it stops at 4.

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?

Annotations already cover safety (readOnly, idempotent, closed-world), so the description's job is to add behavior: it does, with result ordering ('most severe first') and the default that added symbols are excluded. It stops short of discussing permissions or result volume, but that is minor for a read-only query.

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 dense sentences, front-loaded with purpose and scope, followed by the sibling routing. Every clause (date form, symbol restriction, ordering) 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?

With an output schema present, return values needn't be described, and the description covers purpose, scope, ordering, and sibling routing. Only minor gaps remain around the limit/truncation interaction, which the schema already handles.

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 100%, so all six parameters are already documented. The description's mention of date-based from_version and the 'symbols your code uses' filter largely restates the schema, adding only the training-cutoff framing; include_added and limit are not touched.

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?

Specific verb+resource (diffing a package's versions) with explicit scope: breaking changes and deprecations between two versions or since a date. It also names the sibling it is not for (symbol_history) so an agent can discriminate without opening the schema.

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?

Gives concrete usage contexts ('when upgrading, or for code written against an older release') and names the alternative for the single-symbol case. It lacks an explicit when-not/exclusion, but the routing cue is clear.

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?

Annotations already establish readOnlyHint=true, openWorldHint=false, and idempotentHint=true. Beyond that, the description adds important behavior: it explains what evidence is returned, that passing installed versions yields an exact answer, that unexplained errors return empty findings 'rather than a guess', and that callers should inspect `note` and `not_covered`.

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 trigger conditions, then the return value, then the exact-answer guidance, and finally the limitation. Every sentence contributes useful routing or behavioral information, with no wasted text.

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 output schema, the description does not need to fully document return values, but it still summarizes the key findings and explicitly covers the empty-result and not_covered behavior. Together with the fully described input schema, this makes the definition complete 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 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that passing installed versions produces 'an exact answer', which tells the agent why and when to supply that optional 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 diagnostic action, 'explain' a Python error, and enumerates the exact exception classes it covers: ImportError, ModuleNotFoundError, AttributeError, and TypeError. It also states the concrete result ('what changed, in which release, the deprecation message, replacement candidates with evidence, and the version pin'), which clearly separates it from the sibling tools like symbol_history and diff_versions.

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 explicit call conditions: 'Call this when a third-party Python library raises...' followed by the exact exception types. It does not explicitly name alternatives such as check_symbols or diff_versions or state when not to use this tool, so it falls short of a full 5.

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?

Beyond the annotations, the description discloses what the history includes: first and last release, signature changes, deprecations, removals, and replacement candidates. It also clarifies an important edge case: an unindexed path is not an error and returns ever_seen=false.

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 two sentences, front-loaded with purpose, then usage guidance, edge-case behavior, and the alternative tool. Every clause carries 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?

Given the tool's complexity, annotations, and existing output schema, the description is complete enough to support correct selection and invocation. It covers purpose, usage, non-error behavior, and sibling-tool routing.

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 both parameters are already well documented. The description adds concrete examples like package='httpx' and path='httpx.Client.__init__', but does not meaningfully expand parameter semantics beyond the 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?

The description states a specific verb and resource: version history of one public symbol. It gives concrete examples and explicitly distinguishes the single-symbol use case from the sibling check_symbols tool for many symbols.

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 explicitly says when to use it: before writing code against an API remembered from training data. It also names the alternative check_symbols and the condition that selects it: many symbols at one installed version.

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