AstroTune — Vedic astrology (Jyotish)

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

No annotations are provided, so the description carries the full burden. It usefully discloses that BAV and SAV are combined into a single response and that birth time is mandatory, but it says nothing about computation cost, permissions, or how failures are surfaced beyond what the schema already notes. Adequate but thin for a no-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?

Two tightly packed sentences that front-load what is produced and then the key prerequisite. No filler, though the line about lagna as 'one of the eight sources' is terse to the point of being cryptic without domain knowledge.

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. But for an 8-parameter tool with 25% schema coverage and no annotations, the description omits parameter guidance and error handling that an agent would need. It covers the essentials (what it computes, birth time needed) and little more.

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 only 25% across 8 parameters, and the description does not compensate: it does not explain ayanamsa choices, lang, place, or utc_offset. Only the birth-time requirement is hinted at, and the informative notes (chart_id conflict, time_ambiguous) live in the schema, not the description.

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 computation: Ashtakavarga (Parashari) bindus across 12 signs for seven grahas (BAV) plus the consolidated SAV, returned in one response. An agent can tell this apart from generic chart tools like natal_chart or varga_chart. It stops short of explicitly naming a sibling to prefer over it, but the domain term is precise.

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 a prerequisite (birth time is required, with lagna as one of the eight sources), which implies when the tool is applicable. However, there is no explicit when-to-use versus alternatives such as varga_chart, nor any exclusion guidance. Usage is inferred rather than directed.

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 burden. It does add one valuable trait: 'Толкования нет' — the agent knows the output is raw astrological data and must not expect conclusions. But it omits anything about permissions, the date/time/place vs. chart_id input modes, or rate/ambiguity 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?

Three short sentences, front-loaded with what the call returns and then the topic-selection rule. No filler, though the listing of topics in the first clause duplicates the topic enum already in the schema.

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, but for a 9-parameter tool with a required-topic plus optional chart-input options, the description leaves the input model largely unexplained. An agent cannot tell how date/time/place relate to chart_id or what utc_offset's retry flow implies without opening 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 only 11% with 9 parameters, and the description explains only topic (how to pick it). The other eight — date, time, place, lang, ayanamsa, chart_id, geonameid, utc_offset — get no meaning added beyond their names, and the crucial interaction between birth data and chart_id is never clarified.

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 the resource concretely: for a given life-topic question it returns the topic's houses with sign and ruler, the grahas in them, the topic's varga, and the current period. That is specific enough to separate it from natal_chart, varga_chart, or dasha_timeline, though the verb itself ('get/retrieve') is left implicit.

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 tells the agent to pick topic itself based on the question and warns that no interpretation is produced, which is genuine guidance. However, it never names an alternative tool or states when NOT to use this one (e.g. vs. natal_chart or explain_chart_section), so the routing guidance is implied rather than explicit.

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 of behavioral disclosure. It discloses that the tool does not perform rectification and will report commonalities, possible lagnas, and indeterminacies. This is useful but does not mention output format, assumptions about timezone, or how it handles incomplete inputs. The description adds value beyond the name but leaves behavioral details to the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences with no redundant words. It front-loads the core purpose and then immediately clarifies the non-rectification exclusion. Every sentence earns its place, and the structure is optimal for quick comprehension.

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 has 8 parameters and an output schema, yet the description is minimal. It doesn't explain how to construct the input (e.g., time format), what the output contains beyond vague references to lagnas and indeterminacy, or any prerequisites (e.g., whether place is required for correct lagna calculation). Given the complexity and the lack of parameter guidance, the description is insufficient for an agent to call the tool correctly without additional inference.

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 compensate. It mentions the concept of a time window but does not explicitly explain any parameters, including the required time_from and time_to. Optional parameters like ayanamsa, place, geonameid, chart_id, and lang are not addressed at all. The description provides no additional meaning beyond the schema's basic types, leaving the agent to infer parameter semantics.

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 clearly states the tool's purpose: given a birth time window, it determines what is constant across the window, which lagnas are possible and when, and what is indeterminate. It also explicitly distinguishes itself from rectification by saying 'do not choose one lagna for a person,' which separates it from sibling tools like rectification-related ones.

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 provides clear usage context: use when birth time is known as a window (e.g., 'between 13 and 16'). It gives an explicit exclusion ('Not rectification') and a directive to not pick a single lagna, which tells the agent when not to use this tool. However, it doesn't name alternative tools or elaborate on when to prefer this over other astrological tools, leaving some inference required.

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

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

No annotations are provided, so the description carries the full burden. It does disclose genuine behavioral traits — the default body set, the years ≤ 0.15 gate for the Moon, and that retrogradation is always reported with nakshatra/combustion being opt-in — but it says nothing about cost, latency, output shape (mitigated by the output schema), or whether date/time/place are mandatory in practice.

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 dense sentence that front-loads the core purpose ('Транзиты') and then packs the qualifiers compactly. Nothing is padded, though the parenthetical-heavy structure costs some 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?

The presence of an output schema removes the need to explain return values, and the two schema descriptions (chart_id, utc_offset) cover the trickiest inputs. Still, for an 11-parameter tool with 18% coverage, the description omits any explanation of the date/time/place trio and lang, leaving notable gaps.

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 only 18% across 11 parameters, so the description must compensate. It adds real meaning for a few of them (defaulted bodies, the years threshold governing the Moon), but leaves date, time, place, lang, geonameid, and nakshatra/combustion unflagged in prose, so most parameters remain undocumented.

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 resource (transits) and enumerates the concrete outputs it computes: graha positions and sign changes, retrogradation, and optionally nakshatras/combustion. It is far more than a restatement of the name, but it never distinguishes itself from potentially overlapping siblings such as sky_now or panchanga, leaving the agent to infer the boundary.

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 statement of when to pick this tool over sky_now, dasha_timeline, or panchanga. The only usage-like information is an embedded default (Saturn/Jupiter/Rahu/Ketu) and a threshold (Moon only when years ≤ 0.15), which hints at configuration rather than routing guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it mostly doesn't: it never says whether the call is read-only, what the response shape is, or how it handles ambiguity. A hint about the time_ambiguous/utc_offset recovery path exists, but only in the schema, not the description. The behavioral profile is thin for an 8-parameter 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 dense sentences, front-loaded with the core action and the ayanamsa constraint, then the routing rule. No filler. Slightly terse given the parameter surface, but structurally efficient.

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, but with 8 parameters at 13% schema coverage and no annotations, the description leaves most inputs (date/time/place vs. chart_id/geonameid) unexplained, including how chart_id and explicit date/time/place interact. Incomplete for the tool's complexity.

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 only 13% across 8 parameters, so the description must compensate and largely fails to. It explains ayanamsas (count range 2–5, examples) but says nothing about date, time, place, chart_id, geonameid, utc_offset, or lang semantics beyond what the schema enumerates.

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+resource: comparing a single chart across 2–5 ayanamsas and reporting whether the lagna sign, Moon sign, or nakshatra change. It distinguishes itself from verify_external_chart by name. It stops short of fully spelling out the scope (e.g., which chart fields are compared) but is clearly not a tautology.

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 an explicit trigger scenario ("почему на другом сайте другая лагна", when you don't have the other site's numbers) and an explicit alternative for the opposite case ("есть их числа — verify_external_chart"). The when/when-not/alternative triad is fully present.

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 does well: it discloses that a missing time makes the Moon sign twofold, that 'points' then becomes a min…max range, that 'kutas' resolves combinations[0], and that with unambiguous data min=max. It also preempts a wrong inference by stating no percentage is returned. Auth, rate limits and error paths (time_ambiguous) are left to 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 dense sentences that front-load the core purpose before the ambiguity caveats. No filler, though the middle sentence is tightly packed and slightly hard to parse on first read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the ambiguity behavior is covered. Still, for an 11-parameter tool with 18% schema coverage, location and language parameters go unexplained, leaving gaps an agent would have to guess at.

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 18% across 11 parameters, so the description must compensate; it explains the pivotal time-ambiguity semantics behind first_time/second_time, and the schema documents the utc_offset fallbacks. However, place, geonameid, and lang parameters carry no added meaning from the description.

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: matching two people's compatibility by ashtakoot (8 kutas), returning a score and reason per kuta plus a total. That scope is unmistakably distinct from sibling chart tools like natal_chart, varga_chart, or compare_methods.

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 useful output-side guidance ('Процента нет — не вычисляйте его') and explains how to read results when birth time is absent, but never states when to choose this tool over siblings or what prerequisites/alternatives exist. Usage is only implied by the tool's domain.

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 available, so the description carries the full behavioral burden. It discloses the response contract: two numbers representing matching and indeterminate records, and instructs the agent to report both. It also gives corpus size and sign-range context, though it omits details like auth, rate limits, or the precise definition of indeterminate.

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 with no filler: purpose, output contract, and sibling routing are all present and front-loaded. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and the input schema defines enums and limits, the description fills the main remaining gaps: what is counted and how to present the result. The undefined 'indeterminate' category and unmentioned lang parameter are minor gaps that are largely recoverable from the schema and enums.

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 compensate. It meaningfully explains znak (0–11, 0 = Aries) and ties 'graha' to the graha parameter, but it does not explain the lang parameter or the graha enum values beyond their existence. The compensation is partial rather than complete.

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 task: identify which famous people in a 76k-person corpus were born with a given graha in a given sign and count them. It also specifies the output contract and distinguishes the tool from research_query by pointing comparison use to that sibling. The purpose is unmistakable despite the informal phrasing.

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 explicitly routes the comparison use case to research_query, effectively telling an agent when corpus_search is not the right tool. It does not enumerate all alternatives or exclusions, but the stated boundary covers the most relevant sibling ambiguity.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that full=true is 'тяжёлый' (heavy/expensive) and that birth time is required, but it does not state whether the tool is read-only, what permissions are needed, or how required birth data must be supplied. This is adequate but leaves clear gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded paragraph that conveys purpose, depth semantics, prerequisites, date-range behavior, the heavy full option, and the sibling alternative with no wasted words. The semicolon-separated structure keeps it dense but navigable.

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 11 parameters and low schema description coverage, the definition should do more to explain how to supply birth data and the remaining inputs. It does cover the critical usage context and the existence of an output schema removes the need to describe return values, but the gap on most parameters leaves it only minimally sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 18%, so the description must compensate for many undocumented parameters. It explains depth (1–3 mapping to maha/antar/pratyantar dasha), full, and from_date/to_date, but leaves date, time, place, geonameid, lang, and chart_id largely unexplained beyond their bare names or schema notes.

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 (Vimshottari dasha periods) and what it returns: the current period and what follows. It also explicitly distinguishes itself from the sibling life_events, so an agent can route 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?

It states the context for use ('какой идёт сейчас и что дальше'), explains the depth levels, notes birth time is required, tells how to query past years via from_date/to_date, warns that full=true is heavy, and explicitly redirects event-date queries to life_events. This is complete when/when-not guidance.

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

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

With no annotations, the description carries the full burden. It discloses that output includes explanations with sources and a level (calculated or tradition), and states it avoids predictions. It also notes the need for birth time. This is transparent about the tool's behavior, though it does not explicitly state read-only status or failure modes, which are minor for an explanation 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 description is a single, dense sentence that front-loads the core purpose and constraints. Every clause adds value: the sections covered, the explanation style, the source/level attribute, the exclusion of predictions, and the birth-time requirement. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the output schema covers return values, the description does not explain how to provide input (e.g., whether chart_id substitutes for birth data, or the relationship between date/time/place and geonameid). The tool has 8 parameters and only the section is clearly described. It is complete for the core section parameter but incomplete regarding the other optional inputs.

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 compensate. It only addresses the 'section' parameter (by enumerating its possible values) and mentions the need for birth time, but does not explain date, time, place, ayanamsa, chart_id, or geonameid. Most parameters are left unexplained, making it hard for an agent to know which combinations are valid.

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 ('explain'), the resource ('chart section'), and the specific sections (lagna, Moon, dasha). It also explicitly excludes predictions and advice, which differentiates it from sibling tools like dasha_timeline that provide timelines rather than explanations. The purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it explains chart sections and explicitly states it does not provide predictions or advice, which serves as a when-not. It also mentions the prerequisite of birth time. However, it does not name alternative tools or explicitly state when to use this one over others, so it falls short of a 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?

No annotations are provided, so the description carries the full burden. It implies a write/submit action ('report') but does not disclose side effects, auth requirements, or what happens after submission (e.g., creates a record). It does provide guidance on what to include, which is helpful, but the actual behavior of the tool (e.g., that it records feedback) is only implied, not stated explicitly.

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, focused sentence that front-loads the primary purpose and immediately clarifies scope (server problems, not calculations). It provides actionable guidance without any filler. Every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters but only 1 required (title), and the schema covers 80% of them. The description explains the overall purpose and what to include, which is sufficient for an agent to call it correctly. The output schema exists (not shown here), so return values are covered elsewhere. The description does not explain the 'kind' enum or default values, but those are in the schema. Overall, complete enough for a feedback submission 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 80% (high), so baseline is 3. The description adds semantic value by explaining how to fill parameters: 'tool, arguments, expected vs actual' maps directly to the 'tool', 'body', and 'meta' fields. It also clarifies the purpose of 'title' (a short summary) implicitly. This goes beyond the schema's field descriptions, so a 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: reporting problems with the server itself, not calculations. It specifies the exact scenarios (tool misbehaving, missing parameter/field, unclear refusal) and provides a precise instruction on what to include. This distinguishes it from feedback_list (which lists feedback) and other calculation-related tools.

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 explicitly says 'not about calculations' (when-not) and gives clear context for when to use: when the tool behaves unexpectedly. However, it does not mention feedback_list as an alternative for viewing existing feedback, nor does it state when NOT to use this tool for other purposes. So it's clear context but lacks explicit alternative routing.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the tool returns both existing reports and their responses, and scopes the content to this server. However, it does not disclose that the show parameter defaults to 'open', meaning closed/resolved feedback is hidden by default — an agent checking before feedback_add could miss already-resolved threads. This is a meaningful behavioral gap.

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 zero waste: the first states the core function, the second gives the decisive usage routing. The key scoping fact ('about this server') is front-loaded, and the sibling pointer ends the description economically. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. Six optional parameters with sensible defaults, a clear domain scope, and explicit routing to feedback_add make this nearly complete for a lookup tool. The only real omission is the default open-only filtering behavior, which an agent should know before relying on this as a pre-add check.

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 description mentions no parameters, so it adds nothing beyond the input schema. Schema coverage is 67% (q, kind, tool, status are described), and the two undocumented parameters are largely self-explanatory: show has an enum (open/closed/all) and limit has min/max/default. The schema carries the load, so a baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the resource ('what has already been reported about this server') and the response side ('and the responses to it'), and explicitly names the related sibling feedback_add, making the tool distinguishable. However, the verb is implicit in the tool name rather than the description, and the phrasing "что уже сообщено" is passive/indirect, 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?

"Смотрите перед feedback_add" is an explicit directive telling the agent when to consult this tool: before adding new feedback. This directly routes to the one relevant sibling and is clear enough for the domain. It does not enumerate exclusions or discuss other sibling tools, but given feedback_list's narrow scope, that is a minor omission.

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 behavioral burden. It usefully discloses that the search accepts names in any language and that date affects the UTC offset for the relevant historical period. However, it does not mention behavior around limit, language selection, or ambiguous/missing matches.

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 tight sentences with no filler: the main purpose and examples come first, and the date nuance follows. It earns its length, though it could have used the space to clarify lang and limit without becoming verbose.

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 and has an output schema, so return-value details are not required. The main call path is clear and defaults make basic invocation safe, but the lack of guidance for lang and limit, plus the absence of any annotation, leaves the description minimally viable rather than fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains date explicitly and makes query semantics clear through the main purpose, but lang and limit receive no explanation at all, leaving an agent to guess their exact roles.

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 clearly identifies a specific function: mapping a place name in any language to a geonameid for calculations, with concrete examples (Koln, Leningrad). It is not a tautology and no sibling appears to be a place geocoder, though it does not explicitly contrast with any sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: use this when you need a geonameid from a place name and, optionally, the historical UTC offset via date. It does not state exclusions or alternatives, but the context is sufficient for a straightforward lookup 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose a real prerequisite (birth time is required) and the flexibility of the date format, but it says nothing about whether the call is read-only, how many periods are returned per event, or any limits — leaving meaningful behavioral gaps for a no-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?

Dense and front-loaded: purpose, then date-format guidance, then prerequisite, then the sibling alternative — no filler. Slightly terse in places (the prerequisite could be more prominent) but every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with an output schema, the description covers the core contract (events in, dasha periods out) and the birth-time requirement. It is incomplete on the multiplicity of ways to supply time/place (chart_id, geonameid, place, utc_offset) and on the recovery path hinted at by the utc_offset schema note (time_ambiguous), which the agent needs in the failure case.

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 only 22%, so the description must compensate, and it does add value by explaining the event date granularity (2018-02 or 2018, day optional) and the birth-time requirement. However, it says nothing about lang, ayanamsa, chart_id vs geonameid/place/utc_offset, or how those alternative location/time inputs interact, leaving most of the 9 parameters unexplained.

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: given a person's life-event dates, it returns the mahadasha/antardasha running for each in one call. It explicitly names the sibling it is not (dasha_timeline) and gives concrete examples («переехал в феврале 2018»), so an agent can distinguish it from the 19 sibling tools 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?

Routes the agent explicitly: use this tool when the person has supplied event dates, and use dasha_timeline for the full series of periods. The condition is clear but there are no exclusions or additional preconditions beyond 'requires birth time'.

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

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

With no annotations provided, the description carries the full burden. It mentions choghadiyas, abhijit, and 'valid or removed by some rule', but does not explain how results are computed, what rules apply, or any limitations. It also omits details on parameter requirements or edge cases.

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 concise, two sentences, and front-loads the core functionality. It is efficient, though phrases like 'годен или снят каким правилом' introduce slight ambiguity without affecting overall structure.

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?

Although an output schema exists, the description lacks guidance on how to specify location, date range format, or any required inputs. For a tool with 5 optional parameters, more context is needed 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 0%, so the description must compensate, but it does not explain any of the five parameters (city, lang, date_to, date_from, geonameid). The only hint is the date range concept, which is not mapped to the actual parameter names.

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 clearly states the tool searches for good days and hours over a segment up to 31 days, and explicitly notes it is a general selection, not for a specific purpose. This provides a specific verb and resource, but does not name any sibling tool for 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?

The description gives a clear exclusion: it is not for a specific matter, implying it is for general use. However, it does not name alternative tools or explicitly state when to choose this over others like panchanga, leaving some ambiguity.

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, so the description carries the burden and does well: it discloses the conditional degradation without time, the chart_id round-trip, and the input_conflict error behavior. It omits permissions/rate-limit context, but for a stateless computation tool that is minor.

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?

Dense, front-loaded sentences: output summary first, then input guidance, then mode options, then the chart_id/error contract. 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?

With an output schema present, return-value detail is rightly omitted, and core usage is covered. But for an 11-parameter tool with near-zero schema descriptions, the unexplained ayanamsa and house_system enums leave the agent guessing about meaningful inputs.

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 9% across 11 params, so the description must compensate. It explains date/time, place/geonameid, detail, and chart_id, but leaves ayanamsa, house_system, lang, podrobno, and utc_offset unexplained, so coverage is only partial.

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?

Names the specific resource (натальная карта / jyotish) and enumerates its outputs (grahas by sign/house, lagna, Moon nakshatra, current dasha), so an agent knows what it computes. It does not explicitly contrast itself with siblings like varga_chart or chart_transits, but the resource is distinctive.

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 conditions: place OR geonameid, time optional with the exact consequence of omitting it (no lagna/houses/dashas), and reuse of chart_id instead of date/time/place. It even flags that supplying a conflicting field yields input_conflict. It just doesn't name alternative tools for adjacent needs.

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, yet it discloses nothing about read-only vs. mutation behavior, permissions, rate limits, or what 'sun_state/sun_unavailable' means. The agent cannot infer behavioral traits from this text.

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 compact sentence with no filler, and the tool name is front-loaded. Every word is used, though the structure is cryptic rather than helpful.

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 6 parameters, no annotations, and 0% schema description coverage, the description is far too sparse to be complete. It does not explain the tool's purpose, when to use it, or what most parameters mean, despite an output schema existing for return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for 6 parameters, and the description only notes the mutual exclusivity of city and geonameid. It says nothing about date, lang, detailed, podrobno, or even confirms what city/geonameid represent, failing to compensate for the absence of schema descriptions.

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 'Панчанга в любом месте' merely restates the tool name with a location modifier. It states no verb or resource beyond the name, leaving the tool's actual function (calculation? lookup? list?) unexplained and indistinguishable from siblings like muhurta_search.

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 partial constraint ('city/geonameid, не оба') but no guidance on when to use this tool versus alternatives such as muhurta_search or natal_chart. The cryptic 'sun_state/sun_unavailable' fragment offers no actionable usage context.

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

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

With no annotations provided, the description carries the full disclosure burden. It does add real behavioral context: the tool computes a proportion against the whole corpus baseline, returns an interval, and ignores houses. But key behaviors remain undisclosed — what the 'interval' statistically is (confidence interval?), how empty occupation groups are handled, and whether occupation vs occupation_qid are treated as alternatives or filters.

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 dense sentence that front-loads an illustrative example query, then gives the precise computation, the interval, and the signs-only scope. Every clause earns its place; there is no filler or repetition of schema 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?

An output schema exists and covers return values, and the core computation plus the signs-only limitation are described, which is adequate for the simple required-parameter pair (graha, znak). Yet for a 5-parameter statistical tool, the description leaves gaps: the meaning of the interval, the interaction between occupation and occupation_qid, and when this tool should be chosen over sibling corpus/comparison tools are all unresolved.

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 40%, below the 50% threshold, so the description must compensate. It partially does: it explains that znak 0 is Aries (matching the schema min/max but adding semantic meaning) and clarifies that occupation is a word and that the query binds a graha to a sign. However, it does not clarify the relationship or precedence between occupation and occupation_qid, nor add anything about lang or the graha enum values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific computation: share of a graha in a sign (znak 0–11, 0=Aries) within an occupation group compared against the share in the whole corpus of known people, with an interval. This is a precise verb+resource statement that goes beyond a vague label. However, it does not explicitly differentiate itself from plausible siblings like corpus_search or compare_methods, so an agent may still need to open other schemas to disambiguate.

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 context is implied through the concrete example query (

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

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

With no annotations provided, the description must carry the behavioral disclosure burden. It does state the scope ('this moment') and the main returned elements (planets by sign, Moon nakshatra/pada, tithi), which makes the read-only snapshot intent clear. However, it omits any mention of timezone/default time source, astronomical system, or output precision, leaving some behavioral ambiguity.

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 compact sentence that front-loads the most distinguishing information: real-time sky without a personal chart. Every phrase contributes substance, and 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 tool with one optional parameter and an output schema, the description covers the core idea and principal return content. Still, it leaves out usage guidance versus the closely related 'panchanga' tool and does not specify time or location assumptions, so an agent could call it with incomplete context.

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 does not explain the 'lang' parameter. The parameter name and enum values (ru/en) make its language-selection meaning reasonably inferable, but the description adds no semantic value beyond that. The optional nature and default reduce the impact of this gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource clearly: the current sky without a person's chart, listing the included elements (grahas by signs, Moon nakshatra with pada, tithi). It distinguishes itself from natal-chart tools via 'без карты человека', but lacks a direct action verb and does not explicitly differentiate it from the sibling 'panchanga'.

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 guidance about when to use this tool instead of alternatives. The phrase 'without a person's chart' implies it is not for natal-chart calculations, but it never names 'panchanga', 'astro_context', or other siblings, nor does it state the conditions that should lead an agent to choose this 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?

With no annotations, the description carries the full behavioral burden. It discloses that birth time is required and that other vargas return not_available, which is useful limitation context and does not contradict any structured field. It omits auth/rate-limit details, but for a read-only chart calculator those are likely non-issues.

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?

Single compact paragraph, front-loaded with the chart type and supported vargas, then prerequisites and limitations. Every clause adds relevant information with 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?

The tool has 9 parameters, 0 required, and an output schema, so some omissions are tolerable. The description covers varga selection, the time prerequisite, and unsupported-varga behavior, but it does not explain how place, ayanamsa, or chart_id/geonameid should be used, leaving key input context 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?

Schema description coverage is only 11% (just utc_offset) across 9 parameters. The description mentions varga selection and the birth-time requirement, but leaves date, place, lang, ayanamsa, chart_id, and geonameid undocumented, so it fails to compensate for the sparse 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?

States it computes a divisional (varga) chart, lists the exact supported vargas (D2, D3, D7, D9, D10, D12), and notes that the varga parameter selects among them. It implicitly distinguishes itself from natal_chart by scope, but does not name a sibling tool for explicit 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?

Gives the precondition that birth time is required and states that unsupported vargas are not calculated (return not_available), which sets expectations. However, it does not say when to choose this over natal_chart or how it relates to ashtakavarga or other sibling tools, leaving usage context implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool does not adjudicate correctness, which is a useful limitation. It also hints that it will explore ayanamsa and time-zone/dst variations. However, it does not state whether the operation is read-only, what output it produces, or any other behavioral constraints, leaving important gaps.

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 compact and every clause conveys relevant information: the triggering scenario, the parameter numbering, and the tool's limitation. It is front-loaded with the main use case. While it is a run-on with embedded clauses, it is not verbose and could be considered appropriately concise for the amount of context given.

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 complexity (10 optional parameters, no annotations), the description is incomplete. It does not explain how to supply the external values (via moon_sign/nakshatra/lagna_sign or via chart_id), whether date/time/place must be provided to compute our chart, or what the output should look like. An agent would struggle to invoke this tool correctly based solely on this description, even with the output schema present.

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 compensate for all parameter meanings. It explains the numbering for signs (moon_sign, lagna_sign) and nakshatra, and mentions ayanamsa and time as variables. But it leaves date, time, place, chart_id, geonameid, and lang unexplained, and does not clarify how external numbers map to the parameters. This is insufficient for a 10-parameter 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 clearly conveys that the tool addresses a mismatch between externally provided chart values and our own chart, searching for explanations in ayanamsa or time settings. It does not explicitly name a sibling tool, but the scenario is specific enough to distinguish it from related tools like natal_chart or compare_methods. The verb 'verify' is implied through the context of checking external numbers.

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 provides a clear usage scenario: when a user supplies numbers from another site or astrologer that disagree with our chart, this tool is used to investigate the cause (ayanamsa or time-related factors). It also states a limitation ('doesn't decide who is right'), setting expectation. However, it does not explicitly mention alternatives or when not to use it, so it stops short of full guidance.

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

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

With no annotations, the description carries the full burden. It discloses that the tool only reports what is and isn't calculated, and that the agent should not improvise calculations. It does not mention side effects, but the tool is inherently read-only and informational.

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, compact sentence that front-loads the core function (what is calculated) and immediately provides the critical usage instruction. Zero wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple informational tool with one parameter and an output schema present, the description is complete. It states what the tool does, how to behave with it, and the existence of an output schema covers the return format.

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 only parameter is 'lang' with an enum and default in the schema. The description does not mention it, but the schema fully covers its meaning. Since coverage is 0% but the parameter is trivial and self-explanatory, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: it tells the agent what the server calculates and what it does not, serving as a capability reference. It is distinct from all sibling tools, none of which are about server capabilities, and the verb 'calculate' is specific to the domain.

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 usage context: use it before promising a method to a person, and explicitly tells the agent not to fill in missing calculations itself. It does not name alternatives but implies when to consult this tool (before making promises).

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