IndiaDigital

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

Annotations already declare readOnlyHint=true, idempotent and non-destructive, but the description adds genuinely new behaviour: the link renders client-side in the viewer's browser, offers Download and Share, and nothing is uploaded or stored server-side. That privacy/no-side-effect claim is the kind of context annotations cannot express, and it is consistent with readOnlyHint. It omits the cost/authorisation implications of step-based generation (viewer's own keys, ₹ confirmation) that live only in the 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?

Three short sentences, front-loaded with the transformation and its result, followed by what opening the link does and the no-storage guarantee. No filler and every sentence carries information an agent needs.

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 non-trivial tool with 12 parameters, nested objects and an output schema (so return values need no explanation), the description covers input modes, the resulting artefact and side-effect profile adequately. It falls short of fully complete because it gives no guidance on prerequisite or validation siblings and no hint about error behaviour for malformed plans or templates.

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 already 83%, so the baseline is 3; the description earns more by framing brief, template+fields, style+media and plan as alternative entry paths, which clarifies that most of the 12 parameters are mutually exclusive modes rather than a flat bag of options. It still does not state precedence when multiple modes are supplied at once.

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 (turn ... into a link) plus the concrete artefact (a https://indiadigital.org/video/make/ URL) and enumerates the four input shapes that produce it: brief, template+fields, style+media, or plan. An agent can immediately tell this is the 'render a shareable video URL' tool rather than a planner or lister. It does not name the sibling tools (list_video_templates, get_edit_plan_schema, validate_edit_plan) that feed those inputs, so differentiation is implied rather than explicit.

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 four named input modes give clear, actionable context for how to invoke the tool depending on what the agent already has. There is no explicit 'when not to use this' and no routing to siblings such as validate_edit_plan before passing a plan, or list_video_templates to obtain a template id, which is a real gap for a 12-parameter tool.

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 this as a safe, idempotent, read-only, closed-world computation, so the description is not obligated to restate that. It instead contributes domain knowledge the schema lacks: the current valid main rates and the special-case rates for gold and rough stones, which is genuinely useful behavior context for a pure calculation 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?

Two tight sentences with zero filler. The primary behavior (add vs extract) is front-loaded, and the rate enumeration follows as supporting 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?

An output schema exists, so return values need not be explained, and the core add/extract semantics plus rate values are covered. The remaining gap is the percent-vs-fraction representation of `rate`, which matters for a calculator but is a narrow omission rather than a structural one.

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 33%, with just `inclusive` documented, so the description must carry more weight. Listing concrete rate values adds real meaning to the `rate` parameter, but it never clarifies whether rate should be supplied as 18 or 0.18, nor does it describe the `amount` parameter, leaving a genuine ambiguity for a calculation tool.

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+resource pair and clearly distinguishes the two operations it supports: adding GST to an amount versus extracting GST from an inclusive amount. Neither sibling tools nor the title alone would convey that bidirectional behavior, though it does not explicitly contrast itself with siblings like compare_tax_regimes or salary_in_hand.

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 two modes are stated, which implies that the `inclusive` flag selects between them, but the description never says so directly or explains when to prefer this tool over tax-related siblings. Usage is inferable but not spelled out.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds one piece of behavioral context beyond them - that some cases are 'compulsory' regardless of turnover - but does not say which conditions trigger that (e.g. e-commerce selling or inter-state goods supply), leaving the agent to guess the mechanism.

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 filler; the decision to be made is stated first and the factors follow. It is slightly dense, since 'compulsory cases' is left undefined, but nothing is wasted.

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 values need no explanation, and the read-only nature is fully covered by annotations. The remaining gap is minor: the two optional boolean parameters that likely drive compulsory registration are not explained anywhere in the definition.

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 40%: state and turnover are documented in-schema, while supplies' enum values, ecommerceSeller and interStateGoods have no descriptions. The description gestures at turnover and 'what it sells' and hints at compulsory cases, but never maps the two boolean flags to the compulsory-registration logic, so meaning is partially - not fully - compensated.

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 (check) and a specific decision (whether GST registration is mandatory for a business in an Indian state), plus the factors considered: turnover, category of supplies, and compulsory cases. This is clearly distinguishable from siblings like calculate_gst or compare_tax_regimes, though it never names those alternatives 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 implies the use case (determining registration obligation before registering) but gives no explicit when-to-use/when-not guidance and no routing to siblings such as calculate_gst for actual tax computation. Usage is inferable rather than stated.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without description help. The description adds two useful behavioral facts beyond that: the calculation is restricted to resident individuals and excludes capital-gains/special-rate income. It says nothing about the assumptions baked in (which deductions apply under the new regime, whether the result includes cess/surcharge), which is meaningful context for a tax estimator.

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, both load-bearing: one defines the computation and its output, the other carves out the excluded income types. The primary purpose is front-loaded and there is no filler.

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 and annotations are rich, so the description need not explain return values, and the tax-year context comes from the title. However, for an 8-parameter financial calculator with only 38% schema coverage, the description leaves too much undefined — deduction caps, units, and what each input contributes to the comparison are not addressed.

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 38%, so the description is expected to carry parameter meaning — but it mentions no parameter at all. Six of the eight inputs (age, nps, hraExempt, healthInsurance, homeLoanInterest) have no documentation anywhere, leaving the agent to infer deduction semantics and units from field names alone.

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 ("Estimate income tax") and states the scope that defines the tool: both regimes, resident individual, with a comparative verdict ("say which is cheaper"). It does not name any sibling tool, but the sibling list is dominated by unrelated utilities, so the purpose stands on its own.

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 gives a real usage boundary — "Excludes capital gains and other special-rate income" — telling the agent when this tool is NOT sufficient. What it lacks is an explicit alternative for those cases (e.g., a capital-gains calculator) or a pointer to salary_in_hand for take-home pay, so the routing guidance stops short of the top score.

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 readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context by specifying that rates are daily reference rates rather than live rates. It does not disclose rounding/precision, rate source, or whether any spread is applied to the result.

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 wording; the rate basis is placed as a trailing qualifier where it belongs. Nothing in the sentence could be cut without losing 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 and rich annotations, the description only needs to convey scope and rate semantics, which it does. The main residual gap is precision/rounding behavior and clarity on whether arbitrary cross-rates are supported, but that is minor for a simple three-parameter conversion 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 67%, with the two currency-code parameters documented as ISO codes with examples; only amount lacks a description. The description hints at the supported currency universe (150+) and an INR-centric axis, but adds no syntax or format guidance beyond the schema. Against a moderately well-documented three-parameter schema, this is slightly above baseline.

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 (convert currency) plus the rate basis (daily reference rates) and currency coverage (150+). It doesn't differentiate from siblings, but none of the listed siblings overlap with currency conversion, so ambiguity risk is low. The phrase 'between rupees and 150+ currencies' leaves slightly unclear whether non-INR pairs are supported.

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 by the tool name and purpose — an agent will know to call it for currency conversion. However, there is no explicit guidance on when not to use it (e.g. when live intraday rates are needed, as with live_gold_silver_price) and no mention of prerequisites such as valid ISO codes or supported pairs.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that the output includes examples and that 'recipe' is the default, which is modest additional context for an otherwise purely descriptive lookup.

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 compact sentence with the return value front-loaded and the parameter semantics embedded parenthetically, with no wasted wording. Slightly denser parenthetical phrasing would benefit from splitting, but nothing is superfluous.

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, rich read-only annotations, and a single optional enum parameter, the description says enough to invoke the tool correctly. The only gap is its lack of relationship to sibling tools such as validate_edit_plan and build_video_link.

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 enum member has no inline documentation, so the description carries the burden. It does so effectively by explaining that 'recipe' selects the video recipe schema and is the default, while 'plan' selects the full edit plan 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 names the exact resource returned (JSON Schema of the video recipe or the full edit plan) and its two modes, so an agent knows precisely what the call yields. It does not differentiate itself from the sibling validate_edit_plan, which is the main thing keeping it from 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?

It states that 'recipe' is the default and that 'plan' returns the fuller schema, which implies usage (fetch this before constructing or validating an edit plan). However, there is no explicit when-to-use or when-not-to-use guidance and no pointer to validate_edit_plan as the downstream step.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuine value by promising provenance metadata (sources and last-verified dates), which is behavior beyond the annotations. However, it never states what happens when id is omitted despite zero required parameters, nor whether an omitted id returns all topics or errors.

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 that names the returned data, its provenance and its freshness with no filler. It is well sized for the tool, though the space saved is not redirected to the missing parameter guidance.

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 values need not be explained, and the annotations cover the safety profile. What remains missing is the calling contract for a 29-value enum with no required parameters: which id to pass, and what a bare call does. For a keyed reference-lookup tool, that gap is material even if small in scope.

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 description never mentions the sole parameter, id, or how to choose among the 29 enum values. The enum slugs are somewhat self-descriptive, but nothing explains whether id is optional, what a no-id call returns, or how topics map to the returned slab/rate data. 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?

States a specific verb and resource set: returns tax slabs, GST rates, thresholds and dates with sources and verification dates. This distinguishes it from computing siblings like calculate_gst or compare_tax_regimes, which produce derived answers rather than sourced reference data. It does not mention the id keying, so an agent still has to open the schema to learn the tool is a per-topic lookup.

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 'sources and date last verified' framing suggests this is the tool for authoritative reference values rather than calculations. There is no explicit when-to-use, no statement of when to prefer calculate_gst or compare_tax_regimes, and no guidance on whether to call it before or after a computation to cite rates.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds behavior beyond that: it tells the agent which fields matter and instructs it to hand the URL to the user for local processing, which is an actionable behavioral directive rather than a restatement.

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 first front-loads what the tool retrieves, the second states the required follow-up action. Nothing is 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?

Because an output schema exists, the description need not explain return values, and the privacy directive is a useful addition. The critical gap is provenance of the required id and the relationship to search_tools, without which an agent cannot reliably invoke this tool in a 19-tool family.

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 single parameter 'id' has 0% schema description coverage, so the description carries the full burden of explaining it, yet it never says what kind of id this is or where to get one (search_tools, list_video_styles, etc.). It describes return fields instead, leaving the only input essentially undefined.

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 and resource ('Get a tool's description, accepted files, limitations and its URL') and enumerates exactly what comes back, so an agent knows precisely what this call yields. It never distinguishes itself from the sibling discovery tool search_tools, which an agent would need in order to obtain the required id.

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 by the content list, and there is one clear post-call directive: surface the URL to the user for private on-device processing. However, there is no explicit when-to-use versus search_tools, and no statement that the id must come from a prior listing/search call.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that each item carries its questions and allowed answers, which hints at the shape of each entry but largely duplicates what the output schema already provides.

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 filler or repetition. The closing clause about questions and allowed answers is mildly redundant with the output schema, but it does set expectations about item structure at negligible cost.

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 parameters, a full output schema, and rich annotations, most structured burden is already carried elsewhere. The remaining gap is contextual: the description never ties 'Smart Answers' to the clinics naming or to run_clinic, leaving the agent to guess how the listing feeds the execution 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 tool takes no parameters, so there is no parameter semantics to explain; the standard baseline for a zero-parameter tool applies. The description correctly avoids inventing arguments that the empty schema does not support.

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?

Uses a specific verb ('List') and names the resource ('Smart Answers'), with the added scope of questions and allowed answers. The one weakness is that the tool name says 'clinics' while the description says 'Smart Answers', so the agent must infer that these are the same resource, and the sibling run_clinic is not referenced.

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 listing purpose implies the natural usage — enumerate available items before calling something like run_clinic — but nothing is stated explicitly. There is no when-not-to-use note and no mention of the related run_clinic tool, so routing between the two is left to inference.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without description help. The description adds only that the catalog spans both edit styles and music styles, a modest but genuine clarification of scope beyond the annotations. It says nothing about catalog size, static vs. user-specific results, or how the entries should be consumed.

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?

It is a single short line with no filler, but it is a sentence fragment that reads as a dangling noun phrase rather than a front-loaded statement of what the tool does. The parenthetical example list is useful but dominates the space that should have carried the verb and scope.

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 parameters, rich annotations, and an output schema present, the structural burden is low and the description is not required to explain return values. Still, it omits the two things an agent needs most here: how this differs from list_video_templates and that the returned styles feed downstream tools like build_video_link or validate_edit_plan.

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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema coverage is 100% and the schema is an empty object, so no compensating explanation is required.

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 the resources (edit styles, music styles) and gives concrete examples of style categories (before/after, product launch, wedding, explainers), which clarifies what a 'style' actually is. However, it never states the verb or outcome — that this returns a catalog of available styles — and it does not distinguish itself from the sibling list_video_templates, so an agent could plausibly confuse the two.

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, no mention of what the returned styles are for, and no routing to or from alternatives such as list_video_templates, get_edit_plan_schema, or build_video_link. The agent must infer the invocation context entirely from the tool name.

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, destructiveHint=false and openWorldHint=false, so safety and idempotency are covered. The description adds real value by disclosing that returned templates include fields, media rules and example values — content the annotations cannot convey — but it says nothing about result volume, pagination, or whether the list is exhaustive.

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 tight sentences, front-loaded with the resource description and ending with the cross-tool usage note. Nothing is redundant, though the sentence is densely packed and would benefit from slightly clearer framing of the two filter parameters.

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, read-only listing tool with an output schema and full annotation coverage, the description supplies what is needed: what the results contain and how they feed build_video_link. The remaining gap — how filtering behaves and how large the result set is — is minor.

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%: 'query' is documented with examples in the schema while the 'category' enum carries no description. The description partially compensates by listing domains (festival, birthday, wedding, real estate, events) that map onto several enum values, but it does not explain how query and category combine or whether category is a hard filter.

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 resource (fill-in-the-blanks video templates) and enumerates the domains it covers (festival greetings, shop offers, birthdays, weddings, etc.), plus what each template carries (fields, media rules, example values). It stops short of an explicit verb like 'list' or 'search', and never contrasts itself with the sibling list_video_styles, so the template-vs-style distinction 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?

The phrase 'Use with build_video_link {template, fields}' usefully tells the agent this is a discovery step feeding a link-builder, which is genuine workflow guidance. However, it provides no guidance on when to use this versus list_video_styles, no guidance on query vs category filtering strategy, and no exclusions.

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, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety and freshness-from-outside profile is covered. The description's real contribution is explaining that two figures come back — an international spot price and an Indian estimate including customs duty — which clarifies what the numbers mean. It says nothing about data staleness or source, despite the tool being labelled 'live'.

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 stating the resource, unit, currency and pricing basis, with no filler. Nothing can be trimmed without losing 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?

An output schema exists, so return formatting need not be explained, and annotations carry the safety profile. The description covers what is measured, the unit, the currency, and both price bases, which is what an agent needs to invoke it correctly. Only the omitted-metal default and the meaning of 'live' (refresh cadence) are left open.

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 single 'metal' parameter has no documented meaning in the schema. The description does say 'gold or silver', which effectively enumerates the accepted values. However, the parameter is optional (0 required) and the description never says what happens if it is omitted, so the gap is not fully closed.

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 resource and unit: current gold or silver price per gram in rupees, plus the two pricing bases (international spot and Indian market estimate with customs duty). That is far more specific than the bare name. It stops short of differentiating from siblings such as convert_currency, which could plausibly be reached for a similar request.

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 guidance, and no mention of the sibling tools that might compete (currency conversion, general facts lookup). The agent must infer the use case from the name and the single clause about pricing bases.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact -- missing answers fall back to defaults -- but says nothing about how answers must be keyed, what happens with unrecognized question keys, or whether results vary with prior state beyond idempotency.

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 purpose is front-loaded, which is good, but the entire clinic enum is re-listed inline, largely duplicating structured schema data. The parenthetical labels justify some of that bulk, yet the result reads as a single sprawling sentence that an agent must parse rather than a tight, scannable definition.

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, the description needn't explain return values, and annotations cover safety, so the remaining burden is input behavior. Default handling is disclosed and the clinic catalog is complete. The one meaningful hole is the key format for the answers object, which is not covered anywhere.

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 carries the burden. The clinic enum values are largely self-describing and the labels add a small amount of gloss, but the free-form 'answers' object is left completely opaque: neither schema nor description states that keys should be question identifiers obtained from list_clinics. That gap leaves the second parameter under-specified.

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 concrete outcome (a personal answer with reasons and next steps) and enumerates all twelve clinics with human-readable labels, so an agent knows exactly what each call produces. It also distinguishes itself from list_clinics by routing discovery there. It stops short of a crisp verb+resource framing -- 'get a personal answer' is softer than naming the operation -- but the clinic catalog removes most ambiguity.

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 real usage guidance: 'call list_clinics to see questions' tells the agent how to discover valid inputs, and 'Unanswered questions use defaults' sets expectations for partial input. However, it gives no guidance on when to pick run_clinic versus overlapping siblings such as compare_tax_regimes, check_gst_registration, or calculate_gst, even though clinic names like 'old-vs-new-tax-regime' collide directly with them.

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=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so safety behavior is covered. The description adds that the figure is an estimate and lists the deduction components, but it omits the assumptions that drive the number (financial year, standard deduction, how PF is capped), which are the details that would let an agent judge the output's reliability.

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 the input, output, and deduction breakdown front-loaded; there is no filler and nothing an agent must read past to understand the core operation.

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 values need no explanation, and the description covers the main computation logic including the optional regime. The main residual gap is the absence of any assumption or limitation statement for a financial estimate tool with five parameters and region-specific tax rules.

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 60%; the two undocumented parameters are pfMode and regime, whose enums are largely self-explanatory. The description does implicitly illuminate the 'regime' parameter by naming new/old tax regimes and reinforces that PF is a factor, but it adds no detail on pfMode's capped/full/none semantics beyond what the enum already conveys.

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 transformation: 'Estimate monthly take-home pay from yearly CTC' after naming the exact deductions (PF, professional tax, income tax). This clearly separates it from siblings like calculate_gst or compare_tax_regimes, though it never names an alternative tool 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?

Usage is implied by the 'yearly CTC' and 'new or old regime' framing, which signals an India salaried-income context. However, there is no explicit statement of when to choose this tool versus compare_tax_regimes, which sits in the same problem space and could plausibly be confused with 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact – that a built-in current small-savings rate is used when ratePct is omitted – but says nothing about compounding conventions, which rate year is used, or how FD/RD tenure is defaulted when months is absent.

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 filler; the scheme list is front-loaded and the rate-default caveat follows immediately. Every clause carries information an agent needs.

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-value explanation is rightly omitted. However, for a 5-parameter calculator with two required fields, the description leaves ambiguity about tenure selection (years vs months) and default tenure for FD/RD, which an agent must resolve 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 coverage is 60%, and the description usefully clarifies the ratePct parameter ('unless a rate is given') and that amount means yearly deposit for PPF/SSY versus principal for FD versus monthly for RD. The scheme enum and the interaction between years and months still rely on the schema, so baseline 3 applies.

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 the computed quantity (maturity value) and enumerates the four supported schemes (PPF, Sukanya Samriddhi, fixed, recurring deposits), so an agent can map it against siblings like calculate_gst or salary_in_hand. It stops short of an explicit verb phrase such as 'computes/returns', which keeps it from 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?

There is no explicit when-to-use or when-not-to-use statement, and no alternative tool is named. The clause about falling back to current small-savings rates implies the intended context (quick estimates in INR) but it is left to inference.

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 read-only, idempotent, non-destructive, and non-open-world behavior, so the description does not need to repeat safety basics. It adds useful context by stating that results are links and that file tools run in the user's browser with files never uploaded, which is meaningful privacy and execution 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 front-loaded with the main action and stays compact while covering search scope, result type, and browser execution behavior. Each sentence adds useful information without repetition or filler.

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 annotations and output schema, the description covers the important catalog scope, result format, and browser safety context well. It is only slightly incomplete because it does not explain the limit parameter or clarify routing against get_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 query parameter is already documented in the schema with examples, and the description adds relevant search-scope examples such as PDFs, images, text, calculators, and task presets. The limit parameter remains undocumented in both schema and description, so parameter coverage is only partially compensated.

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 clear verb and resource: search 200+ free tools, and it enumerates the tool categories plus presets and clinics. It does not explicitly distinguish itself from siblings such as get_tool, though the search vs retrieve distinction is reasonably 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?

The description implies this is the discovery entry point by naming categories, task presets, and decision clinics, which helps an agent decide when to search. However, it gives no explicit when-to-use or when-not-to-use guidance relative to siblings like get_tool or list_clinics.

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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds one genuinely useful disclosure — 'Dates can be extended by notification' — warning that returned dates may differ from official amended deadlines. Beyond that it adds nothing about scope, freshness, or the subscribe link's purpose.

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, front-loaded sentences with no filler; the purpose lands first. Saved from a 5 only because the enum restatement consumes most of the word count without adding 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?

An output schema exists, so return values needn't be explained, and the caveat about notification extensions is valuable. However, for a tool with a 0%-documented two-parameter schema, the description leaves the count parameter and the meaning of 'normal' versus extended dates unexplained.

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 carry parameter meaning and it largely does not. The calendar enum values are merely restated (already visible in the schema) and the 'count' parameter — 1 to 24, undocumented anywhere — is never mentioned or explained.

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: 'Next normal due dates from a compliance calendar', and names the calendar families it covers. An agent can tell this is a read-lookup for Indian tax/GST deadlines and it is not easily confused with any sibling (calculate_gst, check_gst_registration, etc.).

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 by 'compliance calendar' and 'next due dates', but the description gives no explicit when-to-use or when-not-to-use guidance and doesn't point to a related sibling. It also doesn't say a 'calendar' value is required, though the schema does.

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 readOnly/idempotent/non-destructive, so the lower bar applies. The description still adds real value by naming the repair categories (template names, aspect words, Dropbox links, option values, dates) and disclosing that it returns both errors and warnings, which tells the agent the call is self-healing rather than a pure pass/fail gate.

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, no filler, with the precondition ("before building a link") front-loaded and the repair/error behavior following immediately. 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 12-parameter, nested-object tool with an output schema and strong annotation coverage, the description covers the essential framing: it validates and repairs rather than builds. The only gap is that it never notes the tool can assemble a plan from loose inputs (brief, style, media, steps), which an agent only learns from the schema.

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 83% and the description mentions no individual parameters, so per the baseline this lands at 3. The schema already carries the heavy lifting (enum meanings, step shapes, CORS notes), and the description adds nothing beyond acknowledging the recipe/plan inputs.

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?

"Check a recipe (or a bare edit plan) before building a link" gives a specific verb (check/repair), a specific resource (recipe or edit plan), and explicitly positions it as the pre-flight step ahead of build_video_link, so an agent can separate it from the sibling that actually produces a link.

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 supplies a clear when-to-use rule: run it before building a link, accepting either a full recipe or a bare plan. It does not state when-not to use it or what to do if validation returns errors, but the sequencing guidance is unambiguous.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context, which it does: it flags that link recipes render 'in the browser that opens the link' and that media hosting carries CORS considerations and platform limits. Those are behavioral caveats an agent would not learn from the annotations alone. Return shape is not described, but an output schema exists, so that gap is acceptable.

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 segments, with the imperative 'Read first' front-loaded ahead of the topic list. The parenthetical about browser rendering is the only dense part, and it earns its place by qualifying how link recipes behave.

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 zero-parameter guide tool with full annotations and an output schema, the description supplies adequate scope: it tells the agent what domains the documentation covers and what constraints (CORS, limits) to expect. Nothing essential to calling it is missing.

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 tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter hints are present.

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 identifies this as an instructional/readme resource ('How bots make videos') and enumerates the topic areas it covers: video-by-link recipes, templates, styles, edit plans, media hosting, and limits. That is enough to distinguish it from the actionable siblings (build_video_link, list_video_styles, validate_edit_plan), though the phrasing 'How bots make videos' is slightly indirect about the fact that it returns documentation rather than performing an action.

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?

'Read first' gives an explicit ordering cue that places this ahead of the video-building siblings. It does not name a specific alternative tool or state what to do after reading, but the sequencing guidance is clear and actionable.

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