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

With no annotations, the description carries the behavioral burden and does well: it discloses that the tool accepts every room in a single call and returns per-room compliance status, severity, remedies, and an overall score. It does not explicitly state whether the operation is read-only or whether it stores anything, but the audit-oriented framing strongly implies a non-mutating evaluation.

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 front-loaded sentences: the first defines the primary action and output, and the second immediately handles the alternative-tool routing. There is no filler and nothing structurally out of order.

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

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

For a single-parameter tool with full schema coverage and no output schema, the description supplies what is needed: the operation, the output shape, the batching behavior, and the sibling alternative. An agent can invoke it correctly without additional 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 already 100%, so the baseline is 3; the description adds useful framing by emphasizing that rooms must be passed 'with the compass zone it actually occupies.' This reinforces the schema's intended usage beyond what the field descriptions alone provide.

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 ('Audit an entire floor plan for Vastu compliance') and clearly differentiates this from the single-room sibling. It also summarizes the return payload (per-room verdict, severity, remedy, overall score), so an agent can tell exactly what this tool produces.

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

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

It explicitly routes the agent: use this tool for a whole floor plan in one call, and use vastu_room_placement instead if only a single room needs guidance. That is a clear when-to-use and when-to-use-alternative statement, leaving little 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?

With no annotations, the description carries the disclosure burden and does well: it flags the estimate as coarse and unverified and explicitly says it is not field calibration. It omits specifics like the underlying model, output units, and whether date affects the returned value beyond what the schema hints.

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, front-loaded with purpose and followed by the critical accuracy caveat; 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?

There is no output schema, so the description should clarify the return — units (degrees east/west), sign convention, and precision — to fully prepare an agent. It covers the accuracy caveat but leaves the shape of the result undefined.

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

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

Schema coverage is 100% — lat, lon, and the optional ISO date (with 'today' default) are fully documented in the schema. The description adds no meaning beyond that, which is acceptable at the 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?

States a specific verb ('look up') and resource ('coarse magnetic-declination reference estimate for India'), including the geographic scope. No sibling tool computes declination, so the agent can place it unambiguously among the vastu/vedika 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 implies the use case (compass correction) and warns against over-trusting the output, but never states when to call this versus alternatives or what prerequisites apply. Usage is inferable rather than explicitly 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?

With no annotations, the description carries the full burden and does disclose the key behavior that it infers and places rooms itself and returns up to 3 ranked variants. It does not say whether this is a synchronous call or an async job (the vastu_job_* siblings suggest jobs exist elsewhere), how costly it is, or what the 'ranked variants' are ranked by.

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 compact clauses: the contrastive input mode is front-loaded and the return shape closes it out. There is no filler and 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?

No output schema exists, and the description covers the return only as 'up to 3 ranked variants' without describing what a variant contains or how ranking is decided. For a tool with nested, mandatory parameters and no annotations, that leaves meaningful gaps in what the agent can expect.

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

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

Schema description coverage is 100%, so the nested plot and requirements fields are already documented in detail. The description adds a useful mental model (plot dimensions plus a room programme, BHK/bathrooms/parking/pooja) but no syntax or constraint detail beyond the schema, so baseline 3 holds.

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 ('Generate a Vastu-compliant floor plan') and scopes the input mode explicitly ('from a high-level brief instead of an explicit room list'). It is clear what it produces and how it differs from an explicit room-list approach, though no sibling tool is named so the distinction from vastu_room_placement must be inferred.

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 selection condition: use this when you only have a high-level brief rather than an explicit room list. There are no explicit exclusions or named alternatives (e.g., when to prefer vastu_room_placement or vastu_audit_floor_plan), so the routing is implied rather than 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?

The readOnlyHint already signals a safe read operation, and the description adds useful behavioral context beyond annotations: no arbitrary URLs are fetched and reads do not charge. It does not cover authorization requirements or error behavior, but it adds meaningful safety and cost context.

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 three sentences, front-loads the core action, and every sentence adds useful information. There is no redundant restatement of the name or annotations.

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 annotations cover the safety profile. The description supplies enough context on stable IDs, completed items, URL scope, and cost, though it could say more about prerequisite job state and failure modes.

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?

With 0% schema description coverage, the description must carry parameter meaning. It identifies jobId and itemId as stable IDs for a completed item, which is helpful, but it does not explain the ID formats or constraints beyond what the schema's pattern/minLength rules already enforce.

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: fetch the completed item artifact and original receipt using stable job and item IDs. It is more specific than the bare name, but it does not explicitly distinguish itself from the sibling vastu_job_results tool.

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 implies this is for retrieving an exact completed item by stable IDs, and notes that HTML reports use format:html at submit. However, it does not explicitly say when to use this tool versus vastu_job_results or what prerequisites are required, such as the job being completed.

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 disclose the critical cost consequence: in-flight items can still finish and bill, while the cancel call itself does not charge. It stops short of covering idempotency, behavior on already-completed or already-cancelled jobs, and required permissions.

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 action and followed immediately by the billing caveats. Every sentence adds a distinct, decision-relevant fact 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?

An output schema exists, so return values need not be explained, and the billing caveat covers the main behavioral unknown. The remaining gap is that 'job items' (plural, item-level) sits uneasily against a job-level jobId without clarifying whether the whole job or selected items are cancelled.

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 jobId parameter is never mentioned in the description, so nothing explains its format (vjob_ + 32 hex) or whether it addresses a job or an individual item. Low ambiguity because there is only one param, but 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+resource ('Cancel ... job items') with an explicit scope qualifier ('unstarted'), which lets an agent distinguish it from status/results siblings. It doesn't name the sibling to use if the job is already in flight, but the action itself 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 'unstarted' qualifier implies when the tool is applicable and hints at the boundary case (already-started items), but there is no explicit direction such as checking vastu_job_status first or what to do if cancellation is partial. 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?

readOnlyHint=true already signals a safe read, and the description adds genuinely useful behavioral context on top: paging is cursor-driven, a null cursor terminates the loop, and results have a 7-day lifetime. That expiry window is the kind of lifecycle detail annotations cannot express. It does not say what happens if the job is still running or the jobId is unknown, which keeps it short of a 5.

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

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

Three short sentences, each carrying distinct information, with the core action front-loaded before the pagination and expiry details. Nothing is redundant with the schema or annotations.

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

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

An output schema exists, so return-shape explanation is correctly omitted, and the read-only nature is covered by annotations. However, for a job-scoped reader sitting alongside vastu_job_status and vastu_job_artifact, the description never establishes the division of labour or what state the job must be in, which is the main thing an agent needs before calling it.

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

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

Schema description coverage is 0%, so the description carries the burden, and it only half-delivers: it explains the cursor contract (pass verbatim, null terminates) but says nothing about jobId beyond what the regex pattern shows. There is also an unremarked naming mismatch — the description says "nextCursor" while the schema property is "cursor" — leaving the agent to infer that nextCursor is the response field copied into cursor.

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?

"Read one results page with per-item response, receipts and artifacts" gives a specific verb (read) and resource (results page) and hints at the payload contents. It stops short of naming why an agent should pick this over the adjacent vastu_job_status or vastu_job_artifact, so the boundary between the three job tools 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?

The only usage instruction is pagination mechanics ("Pass nextCursor verbatim; null ends pagination"), which tells the agent how to iterate but not when to call this tool versus vastu_job_status or vastu_job_artifact. There is no statement of prerequisites such as the job needing to be complete before results exist.

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; the description reinforces this and adds the useful fact that billing data can be read without incurring a charge, which is real context an agent would otherwise hesitate over. Beyond that it says nothing about polling behavior, status values, or freshness, so the addition is modest.

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 the read-only guarantee front-loaded after the purpose. Nothing wasted, though the second sentence is partly redundant with the annotations.

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 detail is not needed, and the safety profile is covered. Still missing is how an agent obtains a valid jobId and how statuses should be interpreted or polled, which matters for a job-tracking endpoint.

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

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

Schema coverage is 0% and the description never mentions jobId, its expected vjob_ prefix format, or where to obtain it. With one required parameter completely undocumented outside the raw pattern, the description fails to compensate for the missing 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?

Specific verb (read) plus the resources returned (job status, counts, billing), which separates it from vastu_job_results and vastu_job_cancel. It never names those siblings explicitly, so the boundary is inferred rather than stated.

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: an agent can infer this is the polling/status check for a submitted job. There is no explicit guidance on when to use it instead of vastu_job_results or vastu_job_cancel, and no mention that jobId comes from vastu_job_submit.

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 full behavioral burden and delivers the non-obvious parts: batch cap of 1-1000, mandatory idempotency-key retention, and the billing model ('quote is maxCharge', 'only successful items charge', 'no job fee'). What it omits is equally behavioral — that submission is asynchronous and produces a job, and that failures are per-item rather than all-or-nothing.

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 tool does and zero boilerplate. The trade-off is telegraphic fragments ('Quote is maxCharge') that cost a re-read, but nothing is padded.

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?

Return values are covered by the output schema, and billing/idempotency are handled. For a tool this complex — a 3-variant oneOf request with nested item inputs — the description still doesn't explain the submit-then-poll lifecycle or how to handle partial item failures, which is the main thing an agent needs to call it correctly.

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, and it partially does: it enumerates the three operation kinds and names `idempotencyKey` ('Idempotency-Key') with its retention requirement. It adds nothing about `items`, per-item `id`, `webhookId`, or the `grid`/`plot`/`rooms`/`format` input shapes, leaving the largest part of the schema undocumented in prose.

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 (Submit) and the resource (assessment / plan analysis / report inputs) plus the batch bound of 1-1000, which maps cleanly onto the three `operation` variants in the schema. It does not name any sibling, so an agent can't tell from the description alone whether this or `vastu_generate_plan` / `vastu_operation` is the right entry point.

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 only usage instruction is 'Retain the Idempotency-Key', which is a hygiene rule rather than a when-to-use rule. There is no mention of when to prefer this batch endpoint over `vastu_generate_plan`, nor that follow-up state is read via `vastu_job_status` / `vastu_job_results` — an agent must infer the whole job lifecycle from sibling names.

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

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

With no annotations, the description carries the full burden, and it does real work: it discloses the provenance constraint (Brihat Samhita 53.43-48), that 28 of 81 squares have no seated devata, and that polygon fitting is a computed convention rather than scriptural measurement. It does not mention input-validation failure modes (e.g., degenerate or self-intersecting polygons), which is the main remaining gap for a pure computation 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?

Front-loaded with the action in the first sentence, and the subsequent sentences are all substantive scheme definitions rather than filler. It runs slightly long and the embedded verse citation is dense, but every clause carries information an agent needs to pick a scheme.

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 three-parameter computation tool with no output schema, the description supplies the missing return semantics ('Returns which mandala cell/devata falls where on the plot') and the interpretation caveat. Only edge-case behavior and the coordinate/units assumption (deferred to the schema) are absent.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds genuine meaning beyond the schema's terse 'Which mandala grid to project' by unpacking all three enum values and their content. The bearingDeg parameter is left entirely to the schema, which handles it adequately.

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?

Opens with a specific verb+resource: 'Project a Vastu Purusha Mandala grid onto a plot polygon', then defines each of the three schemes so the agent knows what output shape to expect. It never names or contrasts the closest siblings (vastu_audit_floor_plan, vastu_generate_plan, vastu_room_placement), so the differentiation work 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?

Scheme-level guidance is strong ('brahmasthan = just the central sacred zone that must stay unbuilt'), and it correctly cautions that fitting to your polygon is a computed convention rather than a classical measurement. But there is no statement of when to reach for this tool instead of the audit/placement/generate-plan siblings, so usage is only 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?

No annotations exist, so the description carries the full behavioral burden, yet it says nothing about what happens on an unknown or malformed op, whether calls execute synchronously or hand off to a job (notable given the vastu_job_submit/status/artifact siblings), or what side effects a given operation may have. The only behavioral hint, that batches/assessments need an idempotency key, comes from the schema, not the description.

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 core routing statement is front-loaded and the usage rule closes the description, which is good structure. The inline list of 18 examples is useful but dense and could be trimmed or grouped without losing selection signal.

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 the highest-complexity tool here (143 polymorphic operations, nested params object, no output schema), the description is enough to attempt a call but omits key operational facts: how to enumerate valid suffixes, sync-vs-job behavior, and error semantics. It is minimum viable rather than 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 coverage is 100%, so baseline is 3; the op parameter is fully documented in the schema including the leading-slash trimming. The description adds value by enumerating 18 concrete suffix examples, but the polymorphic `params` body is left entirely to the schema's vague 'shape depends on the operation', and no guidance is given on how to discover per-operation shapes.

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 action (invoke any Vastu Shastra operation) and the precise addressing mechanism (path suffix under /v2/astrology/vastu/). It also explicitly distinguishes itself from the dedicated vastu_* siblings as the escape hatch for the remaining 143-operation surface, so an agent can tell immediately whether this is the right tool.

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 an explicit routing rule: use this for the long tail not covered by dedicated vastu_* tools, and 'Prefer a dedicated vastu_* tool when your need matches one.' The 18 example suffixes further make concrete which families of operations fall here, leaving little 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?

With no annotations, the description carries the full load and does disclose key traits: the data is static (implying stable, repeatable results) and it is a 'Billed reference operation,' which is operationally important for an agent deciding whether to call it. It does not describe response shape or whether repeated calls are cached/free, leaving a gap for a billed 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?

Front-loaded with the core statement, and the long enum gloss is dense but each entry earns its place given the opaque slugs. Minor deductions: the billing note sits as a dangling final fragment instead of being surfaced earlier, and the run-on enumeration could be segmented for faster scanning.

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

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

For a single-enum, no-output-schema lookup tool this is nearly complete: it covers what each table is, that nothing is computed, and that the call is billed. It stops short of indicating the shape of the returned rows (e.g., columns or record granularity), which is the one thing an agent must guess.

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 already 100%, but the description goes well beyond it: cryptic slugs like 'mandala-45-devatas' and 'gate-obstructions' are decoded into what they actually contain, including the Brihat Samhita 53.76-81 provenance. That is real semantic value the enum alone cannot provide.

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 ('Look up a static Vastu Shastra reference table') and immediately scopes it against computational siblings with 'no calculation, no building input required.' It then enumerates every enum value with a plain-language gloss, so an agent knows exactly which table answers which question.

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?

'No calculation, no building input required' gives a clear selection signal that separates this from vastu_audit_floor_plan / vastu_room_placement / vastu_generate_plan, which presumably need building input. However, no sibling is named explicitly and there is no stated 'do not use this for X' exclusion, so the routing is inferred rather than prescribed.

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 supplied, so the description carries the full burden, and it does disclose the response content (compliance, severity, recommended zone, remedy) plus the read-only framing implied by 'Get'. The note about 'one dedicated backend endpoint per room type' hints at per-call cost/no batching. It stops short of stating explicitly that nothing is mutated, or what happens with invalid room/zone combinations.

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, front-loaded with purpose and return content, then the disambiguation. The 'one dedicated backend endpoint per room type' clause is the weakest line — it is an implementation detail that earns only marginal place and could be cut or moved.

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-param, read-only lookup with no output schema, the description is nearly sufficient: it lists the returned fields and the scope boundary. What it omits is failure behavior (e.g., unknown room/zone pair) and whether guidance is deterministic — minor for this tool class but not nothing.

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

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

Schema coverage is 100% with two fully enumerated parameters, so the schema already defines valid values and their meanings. The description reinforces the key semantic ('specific (or proposed) compass zone', one room at a time) but adds no format or edge-case detail beyond that. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Get Vastu Shastra placement guidance for ONE room type in a specific compass zone') and enumerates exactly what comes back: compliance verdict, severity, recommended zone, remedy. It explicitly names the sibling it is not (vastu_audit_floor_plan) and the scope difference (one room vs whole building), so an agent can route correctly without opening either 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?

The final sentence gives an explicit alternative and the condition that selects it: use vastu_audit_floor_plan for a whole building. The '(or proposed)' parenthetical also tells the agent this works for hypothetical placements, not just existing ones — a real usage distinction that is otherwise easy to miss.

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 usefully discloses plan-based availability, latency drivers, and a billing-terms link, but it omits auth requirements, error behavior, and whether the endpoint is strictly read-only aside from conversation state.

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 purpose and then adds operational caveats without becoming bloated. The billing sentence is a production-use caveat rather than invocation guidance, but it is relevant enough to justify 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 ten-parameter tool with nested objects, no annotations, and no output schema, the description covers invocation context and some operational caveats. It still leaves return-shape, auth, and error-handling details implicit, so it is adequate but not 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 100%, so the schema already explains all ten parameters in detail, including enums and nested birth-detail objects. The description mainly restates the system enum, birth-details condition, and conversationId purpose rather than adding syntax or constraints beyond the schema.

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

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

The first sentence states a specific verb and resource: send natural-language astrology questions to the Vedika API, with birth details when needed. It is clear this is the general-purpose chat endpoint, but it does not explicitly differentiate itself from the many specialized sibling tools such as vedika_birth_chart or vedika_dasha.

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 some usage context: birth details are required when the operation needs them, system selects Vedic/Western/KP, and conversationId is for follow-ups. However, it never says when to choose this tool over the specialized astrology siblings or when not to use it, leaving the main routing decision implicit.

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, and it does disclose the paid cost ($0.025/call) plus what each mode returns and the score ranges (0-8 per sign, max 337 SAV). It does not explicitly state that the call is a side-effect-free computation or discuss any auth/permission requirements.

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?

Four dense sentences, front-loaded with the definition and then mode behavior, interpretation threshold, and cost. Every sentence carries usable information with no padding.

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 7-parameter calculation tool with no output schema, the description covers what both modes return and how to read the scores, which is the essential context. Minor gaps (no mention of the polar-latitude rejection or how the schema handles a missing planet with type=planet) are covered by the schema itself.

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

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

Schema description coverage is 100%, so every parameter including the type enum and planet enum is already documented. The description restates the planet vs sarva distinction but adds little beyond what the schema says other than interpretation of the resulting scores.

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

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

Specific verb (Calculate) plus a named resource (Ashtakavarga) and immediately defines the system: 8-fold division scoring each planet across 12 signs, 0-8 points. It also distinguishes its two output modes, so an agent can tell it apart from vedika_strength or vedika_dasha.

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 clear situational context ("Used for timing events") and interprets results ("Signs scoring 28+ in SAV are strong for transits"), which tells the agent when the output matters. It stops short of naming an alternative sibling or stating when not to use 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?

With no annotations, the description carries the full burden and does disclose key traits: the ephemeris used, the default ayanamsa, and per-call pricing ($0.016-0.028/call). It omits things like determinism, failure modes, and auth requirements, and the polar-latitude rejection is left entirely 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?

Front-loaded with the core action, then modes, then cost, with no filler sentences. There is some duplication of the 'type' enum text that also appears in the schema, which is mild redundancy.

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?

No output schema exists, and the description compensates by sketching what each mode returns, which is enough for an agent to call it correctly. It leaves out error behavior and the required-parameter contract, but core needs are covered.

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

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

Schema coverage is 100%, so the schema already documents all six parameters, making 3 the baseline. The description restates the 'type' enum meanings but does add return-content detail (9 planets + Rahu/Ketu with retrograde status) and confirms the Lahiri default for ayanamsa, though it adds nothing for datetime, latitude, longitude, or timezone.

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 ('Generate a Vedic birth chart (Kundli)') and enumerates its outputs (planetary positions, house cusps, ascendant, nakshatras, dignities). It never names an overlapping sibling such as vedika_horoscope or vedika_divisional_charts, so an agent must infer which chart tool to pick.

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 mode breakdown gives clear context for choosing a 'type' value ('kundli' returns the full chart, 'planetary-positions' returns all 9 planets, etc.), and it states the calculation basis (sidereal, Lahiri default). However there are no exclusions or alternatives for the many sibling chart tools, so cross-tool selection guidance is missing.

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

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

With no annotations, the description carries the full burden, and it does add genuinely useful non-schema context: a per-call cost of $0.016–0.020, which lets an agent budget. It does not disclose response shape, error behavior, rate limits, or that results are location/time-dependent in any practical sense, leaving significant behavioral gaps for a 6-parameter computational 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 compact glossary of enum values with the domain stated up front and cost last — no filler sentences. The telegraphic 'X = Y' fragments are terse but efficient for an enum glossary; only the unexplained pairing of Yoga and Period entries slightly blurs it.

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 6-parameter, 5-required tool with no annotations and no output schema, the description covers what each mode returns conceptually but says nothing about output structure, units, or result cardinality. Required coordinate/time inputs and the polar-latitude rejection live only in the schema, so the description is adequate but leaves an agent guessing at 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 coverage is 100%, so baseline is 3. The description adds real meaning for the `type` enum by defining most values (ritu, solstice, anandadi-yoga, gowri nalla neram, disha shool, planet transit, chandrashtama), though 'chandrashtama-periods' is left undefined and 'inauspicious-yoga' is only implied by the paired gloss. `ayanamsa` and the coordinate/time parameters are left entirely to the schema.

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

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

The opening sentence names the domain (Vedic calendar calculations) and the rest of the description enumerates and defines each of the calculation modes the `type` enum selects, so an agent can map a request to a mode. However, it never distinguishes this tool from close siblings like vedika_panchang or vedika_muhurta, which plausibly cover overlapping material.

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 per-type glosses imply when each mode is appropriate (e.g., 'Chandrashtama = ... avoid important work'), which is useful. But there is no explicit routing guidance — nothing says when to use this versus vedika_panchang, vedika_muhurta, or vedika_daily_bundle, and no prerequisites or exclusions are 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?

With no annotations, the description carries the burden and does so substantively: it discloses the exact response contents, an active input-rejection behavior (timezone-bearing datetimes), and a pricing/consultation caveat. It stops short of stating auth requirements, rate limits, or error formats, but the non-obvious rejection rule is the key disclosure and it is present.

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?

Front-loaded with the verb, the resource, and the return shape, then the exclusions and the input constraint. Every sentence is informative, though the trailing pricing notice is commercial boilerplate rather than call-relevant 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?

There is no output schema, so the description usefully enumerates the returned pillars, Day Master, and element balance, and it flags the absent features a caller might otherwise assume. For a single-parameter read-only calculation tool this is close to sufficient; only sibling routing for the excluded Da Yun features is left implicit.

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 already 100% and the pattern documents the accepted format, yet the description adds real meaning: the datetime is a 'birth datetime' that is timezone-free, and offset-bearing values are refused. That clarifies semantics the regex alone does not explain for an agent deciding how to construct the input.

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 ('Calculate the current basic Ba Zi (Four Pillars) chart') and enumerates exactly what the result contains (Year/Month/Day/Hour pillars, Day Master, dominant element, element balance). It also explicitly scopes itself out from related capabilities (Da Yun, annual luck pillars, favorable/unfavorable elements), so an agent can place it among the many vedika astrology siblings without 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?

Gives clear preconditions: input must be a timezone-free birth datetime, and timezone-bearing input is currently rejected, which prevents a likely invocation error. It also lists capabilities this route omits, implying where another route would be needed, though it does not name the specific sibling tool that supplies Da Yun or annual pillars.

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 exist, so the description carries the full burden and does well: it discloses the exact returned fields, the CNY boundary behavior, and the per-call cost ($0.003), which an agent needs for budgeting. It stops short of explicitly stating the operation is read-only and side-effect free.

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 compact sentences: purpose first, return contents second, edge case and cost last. No filler or redundancy.

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 output schema, the description correctly enumerates return values, and the parameters are fully covered by the schema. An agent has everything required to invoke it correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the Jan/Feb caveat. The description reinforces the birth-year framing but adds no format or syntax detail beyond the schema, which is the expected 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?

Specific verb and resource: 'Get Chinese zodiac animal sign and element for a birth year,' followed by an enumerated list of returned fields. It is clear what the tool does, though it never names the closely related sibling vedika_chinese_bazi to distinguish scope.

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 'birth year' framing and the Chinese New Year caveat, but there is no explicit when-to-use, when-not, or pointer to alternatives such as vedika_chinese_bazi or vedika_compatibility. An agent must infer the 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?

With no annotations, the description carries the burden and does well: it discloses the prerequisite (birth details for BOTH parties), the scoring scale and acceptable threshold, the Mangal Dosha cross-check in kundali mode, and the per-call cost ($0.040-0.048). It does not state what the response contains or error behavior for missing/invalid birth data, leaving a 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?

Front-loaded with the core purpose and prerequisite, then structured as a compact enumeration of modes and cost. Dense but every clause is informative; the main mild redundancy is re-explaining type options 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?

For a nested-object, 3-parameter tool with no output schema, the description supplies the prerequisite, mode semantics, scoring scale, and threshold. It could go further on what the return payload looks like (per-factor scores, dosha verdict), but it is sufficient to invoke correctly.

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

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

Schema description coverage is 100%, including per-type and per-field explanations, so the schema already documents all parameters. The description restates the type enum meanings and adds the 36-point interpretation, but adds no syntax or format detail beyond what the schema provides – 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?

States a specific domain and action (Vedic marriage/relationship compatibility matching) and enumerates the four scoring systems it supports. It is clearly distinguishable from siblings like vedika_western_relationship and vedika_matrimony_match, and an agent knows both male and female birth details are mandatory.

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 clear routing among the four modes (guna-milan default, kundali adds Mangal Dosha, nakshatra-porutham is 10-factor South Indian, thirumana-porutham is Tamil) and an interpretive threshold (18+/36 acceptable). It does not explain when to prefer this over the sibling vedika_matrimony_match, which is the one explicit alternative an agent would need to disambiguate.

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 present, the description carries the whole burden and does well: it discloses pagination behavior (pass data.nextCursor unchanged, continue even after an empty page, stop at null, paginationAvailable=false means no continuation), warns that results are not a snapshot, and notes conversations persist for context continuity. It never states whether delete is irreversible, what TTL defaults to, or what auth is required.

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?

Front-loaded with the purpose, then organized action-by-action, with the pagination rule packed into efficient sentences. Nothing is badly padded, though the trailing 'Free.' is a slightly dangling fragment and the pagination caveats take three sentences to state.

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

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

There is no output schema and no annotations, and the description steps in to cover the highest-risk gaps: pagination termination, non-snapshot semantics, lifecycle/creation, and TTL extension. It is still silent on delete irreversibility, TTL defaults for extend, and the shape of the get response beyond 'with stored messages', which a mutation-capable tool with zero annotation coverage should ideally cover.

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

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

Schema coverage is 100%, so the schema already documents limit, cursor, conversationId, and the action enum, giving a baseline of 3. The description adds procedural meaning on top: default 10 / maximum 100, ordered by last activity, and the precise cursor continuation rule (continue after an empty page, stop at null), which is more than the schema's terse 'pass the prior data.nextCursor unchanged'.

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?

Opens with a specific verb+resource ('Manage multi-turn AI conversations') and then enumerates the four concrete operations (list, get with messages, delete, extend TTL). It also distinguishes itself from the sibling vedika_ai_chat by explaining that this tool is where those conversations are managed and that vedika_ai_chat is what creates them.

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 which action to reach for in each situation (list for recent activity, get for a specific conversation with stored messages, delete to remove, extend for TTL) and explains the creation path via vedika_ai_chat. There are no explicit exclusions or 'do not use when' conditions, so it stops short of 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?

With no annotations, the description carries the full burden and does substantial work: it discloses provenance (Garuda Purana, BPHS), describes what the response contains, and — unusually valuable — states the per-call cost of $0.012. It stops short of covering error behavior or what happens when zero parameters are passed on a tool with no required params.

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?

Four sentences, front-loaded with purpose then output then provenance then pricing. No filler; every sentence contributes information an agent would otherwise have to infer.

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?

No output schema exists, and the description compensates by enumerating the returned fields (properties, chakra, cleansing method, usage). The remaining gap is behavioral — no guidance on the zero-required-parameter case or on combining filters.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds marginal meaning by clarifying that signs may be Vedic or Western and that the planet parameter returns BPHS primary and secondary gemstones to strengthen that planet. That goes slightly beyond the schema's per-parameter 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?

States a specific verb-and-resource pair ('Get crystal and gemstone recommendations') with three explicit selection axes: sign, planet, need. It also names the output contents (properties, chakra, cleansing method, usage), so an agent can distinguish it from siblings like vedika_lalkitab_remedies or vedika_spiritual_mantra 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?

The description implies the three ways to invoke the tool ('based on zodiac sign, ruling planet, or specific need') but never states when to prefer one over another, whether they can be combined, or what happens if none is supplied. Usage is inferable but not guided.

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 add one genuinely useful operational caveat — consult current Vedika API pricing before use — and 'Get' implies a read-only operation, but it says nothing about authentication, rate limits, or response shape. Adequate, not rich.

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 payload enumeration before the disambiguation and the pricing note. Every sentence carries information, though the pricing caveat sits at the tail where an agent is most likely to drop it.

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 no-required-param aggregation tool with no output schema, enumerating the seven bundled content types effectively stands in for a return-value description. What remains thin is per-item detail and whether the bundle can be partial, but an agent has enough to call it correctly.

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

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

Schema description coverage is 100%, with 'date' (YYYY-MM-DD, defaults to today) and 'lang' (en, hi, default en) already documented. The description reinforces the daily/date framing via "the day's content" but adds no format or default detail beyond the schema. 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?

States a specific verb and resource ('Get the day's general content in one call') and enumerates exactly what is bundled: tarot card, angel number, crystal, mantra, moon phase, rune and I Ching. It also carves out scope negatively ('not a personal or per-sign reading'), so an agent can distinguish it from vedika_horoscope, vedika_tarot_daily and vedika_iching_cast without opening a schema.

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

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

Gives explicit routing: use this for general daily content, use vedika_horoscope for a sign horoscope, use vedika_panchang for panchang. The exclusion of personal/per-sign readings is stated outright rather than implied, which is exactly what a sibling-routing decision 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 must carry the behavioral burden. It discloses useful context such as cost range, calculation basis (Moon nakshatra at birth), and that exact start/end dates are shown. It does not describe authentication needs, rate limits, error behavior, or the response structure, leaving meaningful gaps for a tool with no annotations or 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 short and front-loaded: it states what the tool calculates, then explains the primary and alternative systems, then notes the basis and cost. Sentences are informative and mostly free of waste. A minor improvement would be to surface the sibling-tool distinction earlier or more explicitly.

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 six parameters, no annotations, and no output schema, the description supplies the essential context: what periods are produced, which systems are supported, the calculation dependency, and the cost. It does not describe the return payload format, but without an output schema the description's explanation of Mahadasha, Antardasha, and Pratyantar with exact dates is reasonably 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 100%, so the input schema already documents every parameter, including the system enum and its options. The description reinforces the Vimshottari/Yogini distinction and notes the calculation basis, but adds little parameter-specific detail beyond the schema. This meets the baseline of 3 when schema coverage is 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 uses a specific verb and resource: calculate planetary period timelines (Dasha). It explains Vimshottari, Mahadasha, Antardasha, and Pratyantar, and mentions Yogini as an alternative cycle, so an agent can understand the tool's function. It does not explicitly distinguish this tool from the sibling vedika_dasha_ashtottari, which limits it to a 4.

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 clarifies that Vimshottari is the primary 120-year cycle and Yogini is an alternative 8-year cycle, which gives context for the system parameter. However, it does not explain when to use this tool versus the closely related sibling vedika_dasha_ashtottari or any when-not conditions. Usage is therefore implied rather than fully guided.

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 exist, so the description carries the full load — and it does disclose the return payload (current Mahadasha, Antardasha, full timeline with start/end dates) and the per-call cost of $0.020. It omits any note on computation latency, idempotency, or failure modes for polar latitudes (the latter only appears 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?

Front-loads the verb and resource, then conditions, then return shape and cost — a sensible ordering. The planet-by-period enumeration (Sun 6y … Venus 21y) is somewhat verbose but substantiates the 108-year total, so it mostly 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 6-parameter calculation tool with no output schema, the description supplies what's missing: the result structure, the dasha system's composition, and the pricing. Nothing an agent needs to invoke it correctly or set expectations is absent.

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

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

Schema description coverage is 100%, including enums for depth and ayanamsa, so the schema already documents every parameter fully. The description doesn't add guidance on parameter choice (e.g. when to pick pratyantardasha depth) beyond what the schema states, so the 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?

States a specific verb and resource ("Calculate the Ashtottari Dasha") and immediately scopes it against the sibling Vimshottari dasha tool by naming the 120-year alternative it replaces. An agent can distinguish this from vedika_dasha without opening either schema.

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

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

Gives concrete astrological conditions for selection (Rahu in Kendra/Trikona from the Lagna lord; night birth in Krishna Paksha or day birth in Shukla Paksha), which implicitly defines when the Vimshottari sibling is the fallback. It stops short of explicitly naming vedika_dasha as the default alternative, leaving a small inference gap.

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 usefully discloses that the Vedika Ephemeris is used and that the cost is $0.005/call, but it does not describe the return format, error behavior, or other operational details an agent might need.

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 core action and then provides a dense but necessary list of chart meanings. Every part earns its place, and there is no redundant restatement of the title or schema fields.

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 schema is rich and the description covers chart selection and cost, but with no output schema and no explanation of what the tool returns, the definition is not fully complete for a complex calculation tool. An agent knows how to invoke it but not what output shape to expect.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds meaningful semantics beyond the schema by explaining the life-area purpose of every chart enum value, which helps an agent choose the right D-chart; the remaining parameters are left to the already-rich schema.

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

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

The description opens with a specific verb and resource: "Calculate Vedic divisional charts (Vargas)." It then enumerates each division and its life area, making the tool's scope unambiguous. It does not explicitly distinguish itself from sibling tools such as vedika_birth_chart, so it falls short of a 5.

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

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

Mapping each division to a life area (e.g., D9 for marriage/dharma, D10 for career) gives clear context for when to select a given chart. However, it names no alternative tools and gives no explicit when-not guidance, so it is clear context without full 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 must carry behavioral context; it does disclose cost ($0.016-0.040/call) and the astrological rules used (BPHS Ch. 80 citations, 3 Sade Sati phases), which is meaningful transparency. It does not state the operation is read-only/computational or describe error behavior, so some burden remains unmet.

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?

Information-dense and front-loaded: the core purpose leads, each dosha type is one clause, and the cost caveat closes. No sentence is filler and nothing needed is buried.

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 and no output schema, the description should say something about what comes back (dosha present/absent, severity, remedies), but it only covers inputs. For a paid calculation tool with no output schema and no annotations, that leaves the result contract 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 coverage is 100%, so the baseline is 3; the description earns above baseline by explaining what 'all' actually composes and by detailing the phase structure of sade-sati, which the enum text only gestures at. The ayanamsa, datetime, and coordinate parameters add nothing beyond the schema.

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

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

States a specific verb and resource ('Detect unfavorable planetary combinations (doshas) in a birth chart') and then enumerates each dosha with the technical rule behind it. An agent can distinguish this from vedika_compatibility or vedika_birth_chart 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?

Explains what each type checks (Mangal houses 1,2,4,7,8,12; Kaal Sarp Rahu-Ketu enclosure; Sade Sati 7.5-year transit) and clarifies that 'all' runs only Mangal+Kaal Sarp+Pitru, which prevents a wrong enum assumption. It does not name when to prefer a sibling tool (e.g. vedika_compatibility for marriage matching), so no 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?

With no annotations, the description carries full burden: it does disclose the returned fields, the classical source texts, and a per-call cost of $0.024, which is genuinely useful. It omits auth requirements, whether the call is purely computed vs stored, failure modes, and whether remedial output changes the response shape.

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?

Purpose is front-loaded, followed by return contents, sourcing, and cost. The planetary-governor parenthetical ('Vata... governed by Saturn and Rahu') is decorative detail that consumes space without helping an agent invoke the tool.

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?

No output schema exists, and the description does enumerate the return payload in enough detail for an agent to know what it gets back. Input requirements are handled by the fully documented schema, so the only residual gap is sibling disambiguation.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters including the ayanamsa enum and the includeRemedies/includeSeasonal flags. The description's mention of 'recommended diet type, lifestyle adjustments, favorable seasons' implicitly maps to those two boolean flags but never says they are gated by them, adding no real semantics beyond the schema.

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

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

States a specific verb and resource: 'Ayurvedic constitution (Prakriti) analysis derived from birth chart', and enumerates the exact outputs (dominant dosha, sub-dosha balance, vulnerable areas, diet type). However, it never distinguishes itself from the closely named sibling 'vedika_doshas', which an agent will likely confuse with this tool.

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?

No statement of when to use this tool versus 'vedika_doshas', 'vedika_birth_chart', or 'vedika_dasha'. The only contextual cue is the price line, and there is no indication of prerequisites (e.g. that a birth chart input is required rather than a chart ID).

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 disclose non-obvious behavior: pre-flight failure for unsupported Western periods, an 'advanced registered route' for precision positions, and a billing/pricing caution. It omits what a response actually contains, but the failure-mode and tier disclosure is substantive rather than boilerplate.

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?

Four sentences, front-loaded with the core verb/resource, then constraints, then the pricing caveat. Each sentence carries information, though the final pricing sentence is vague about when/how much and could be tighter.

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?

No output schema exists, so the description should ideally hint at what a horoscope response contains; it does not. It does, however, cover the sign format, the period/system matrix, the Western limitation, and the pricing prerequisite — enough for an agent to call it correctly even if not to anticipate the payload.

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

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

Schema coverage is 100% with three enums, so the schema already documents sign, period, system, and advanced. The description reinforces the sign language variants and adds cost/routing context for advanced=true, but adds little beyond the enum descriptions. Baseline 3 applies when the schema does the heavy lifting.

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 (Get) plus the exact resource (Vedic horoscope for daily/weekly/monthly, Western daily) and scopes it to a zodiac sign. An agent can distinguish it from siblings like vedika_western_transits or vedika_birth_chart because the description pins the resource to horoscope readings for a sign.

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 real constraints — Western weekly/monthly is rejected before any API call, and advanced=true routes through a registered tier — which tells the agent what not to attempt. But it never names an alternative sibling (e.g. vedika_western_transits or vedika_daily_bundle) or states when to prefer this tool over them, so routing guidance is only 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, the description carries the full burden and adds useful behavioral context: it states the cost ($0.040/call), explains the calculation basis (planetary positions and 88 degrees of the Sun before birth), and notes that exact birth time is critical. It does not explicitly state read-only/no-side-effect behavior, but the generate/calculate framing implies a computation 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 front-loaded with purpose, then output contents, calculation method, and cost. It is reasonably efficient, though the sentence about Human Design synthesizing I Ching, Kabbalah, chakras, and quantum physics is educational rather than invocation-critical.

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?

No output schema exists, so the description must explain return values; it does so by listing Type, Strategy, Authority, Profile, Centers, Channels, and Gates. For a complex chart-generation tool it is fairly complete, though it does not describe response structure or error conditions in detail.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the input schema. The description reinforces the importance of precise birth time but adds little semantic detail beyond what the schema provides, making baseline 3 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 uses a specific verb+resource: "Generate a Human Design BodyGraph chart from birth details." It distinguishes this from sibling astrology tools like vedika_birth_chart by explicitly naming the Human Design BodyGraph domain and listing the resulting chart components.

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 Human Design context and birth-detail requirements, but the description does not explicitly say when to use this versus vedika_birth_chart or other vedika chart tools. No alternatives or exclusions are named.

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 does real work: it discloses the return payload in detail, the conditional behavior around changing lines producing a transformed hexagram, and the per-call cost of $0.012. It stops short of stating that the cast is randomized/simulated per invocation (no determinism or reproducibility note) or that there are no side effects.

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?

Front-loaded with the action and immediate return shape, then progressively adds detail on changing lines, trigrams, and cost. The historical aside is one short parenthetical sentence and the pricing line is operational, so nothing meaningfully wastes space.

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?

No output schema exists, so the description must describe the response — and it does, down to the transformed hexagram and trigram attributes. Both parameters are documented and optional, so an agent can call it with zero arguments. Lacking only a note on randomness across repeated calls.

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

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

Schema description coverage is 100%, so the schema already explains method enum semantics and the question field. The description only echoes that both yarrow and coin simulation exist, adding no format or phrasing guidance beyond the schema's own text. 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?

Names a specific verb and resource — 'Cast an I Ching (Book of Changes) hexagram for divination' — and enumerates what comes back (hexagram, name, judgment, image, line texts, transformed hexagram, trigrams). That clearly separates it from tarot/numerology/BaZi siblings by domain, though it never explicitly routes the agent away from those alternatives.

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 description frames it as divination consultation but gives no criteria for choosing it over vedika_tarot_draw, vedika_numerology_complete, or vedika_chinese_zodiac. The only guidance offered is at the parameter level (yarrow vs. coin), not the tool level.

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 reasonably well: it discloses the per-call cost ($0.020) and describes the return shape (planet-by-planet analysis, Lal Kitab-specific dignity, affliction description, 2-3 remedies per planet). It does not cover auth requirements, error behavior, or whether remedies are conditional on affliction status beyond the planet parameter note.

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 sentences, purpose front-loaded, with the tradition context and return contents following. The middle explanatory sentence is somewhat dense but every clause is relevant; 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?

For a tool with no output schema and no annotations, the description supplies the essential return-value picture and cost, and the schema handles parameter detail. Remaining gap is routing guidance relative to the many other vedika_* analysis tools.

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

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

Schema description coverage is 100%, so all seven parameters including planet, ayanamsa, and includeDebts are already documented. The description adds no parameter-level meaning beyond the schema, which sets the baseline at 3.

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 ('Get Lal Kitab remedies for afflicted planets') and scopes it by house placement. It also distinguishes the system from classical BPHS, which helps separate it from Vedic-analysis siblings, though no sibling is named 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 only implied: an agent infers it should call this when Lal Kitab-style remedies are wanted. There is no explicit when-to-use/when-not, and no pointer to alternatives such as vedika_doshas or vedika_predictions for other remedial or diagnostic 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?

With no annotations provided, the description carries the burden well: it lists what the default report includes (Ashtakoota Guna Milan, Dashakoot summary, dosha cancellation, compatibility verdict), notes the alternative South Indian system, and warns about pricing. It does not cover authentication or rate-limit behavior, but for this domain it adds meaningful behavioral context beyond 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 tight sentences: purpose first, then default report contents, then the South Indian alternative and pricing caveat. Every sentence adds information an agent needs, with no repetition or fluff.

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 no output schema, the description sufficiently explains what the default and alternative reports contain. Parameters are fully documented in the schema, so the remaining gap is minor: it could say more about output shape or when to prefer this over vedika_compatibility, but an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so the nested bride/groom birth fields are already well documented. The description adds useful semantic context for southIndian (Porutham vs unified North Indian report), but this is also present in the schema description, so it only slightly exceeds the baseline for fully documented parameters.

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-like operation (Kundali matching), the exact resource/domain (marriage compatibility), and names the underlying systems (Ashtakoota, Dashakoot, Porutham). An agent can distinguish this from generic vedika_compatibility because the scope is explicitly marriage/Kundali matching.

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?

Explains the default mode, how to switch to South Indian Porutham via southIndian=true, and adds a pricing caveat before use. It does not explicitly compare itself to the sibling vedika_compatibility tool, so the routing guidance is strong but not complete.

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 at all, the description carries the full burden and does meaningful work: it discloses the per-call cost range ($0.012-0.020), the three defaults (today's date, Delhi coordinates, IST timezone), and the composition of the aggregate 'combined' response. It stops short of describing the response shape or noting any latency/rate-limit 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 high-level purpose is front-loaded and the type glossary follows in the order an agent needs it. It is dense but virtually every clause carries information; the grouping of the three inauspicious periods into one sentence is efficient rather than wasteful.

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

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

There is no output schema and no annotations, and the 5-parameter signature is non-trivial, so the description should also convey what a response looks like (e.g. whether periods come back as labeled time ranges per type). It covers inputs thoroughly but leaves the entire return contract to guesswork, which is the main remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3, and the description earns that by actually defining the ten enum values the schema defers to ('See tool description for what each returns'). The geographic parameters are not discussed beyond the fact that they default to Delhi, but the schema already documents their ranges and defaults.

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 opening sentence names a specific verb and resource ('Calculate auspicious and inauspicious time periods for today or a specific date') and the following sentences define each muhurta type, so an agent knows exactly what domain this covers. It does not differentiate itself from the closest siblings (vedika_panchang, vedika_calendar), which likely surface overlapping time-period data, leaving that routing inference to the agent.

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 the actual selection logic for the required 'type' parameter — it enumerates what choghadiya, hora, rahu-kaal, gulika-kaal, yamaghanta, abhijit and brahma each mean, and explicitly states what 'combined' and 'auspicious' return, which is genuine when-to-choose guidance. It also states location defaults. It gives no exclusions, however — nothing says when to prefer vedika_panchang or vedika_calendar instead.

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 exist, so the description carries the full burden; it does disclose per-call cost ($0.003-0.010), which is real added value for a paid calculation endpoint. However, it never states the return shape (raw number vs. number plus interpretation), whether inputs are validated, or latency characteristics — notable omissions given there is no 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?

Front-loads what the tool is, then delivers one dense line per calculation type followed by cost — no filler. The telegraphic 'X = Y' style is efficient but reads as a list dump rather than guiding prose, which slightly limits readability for an agent parsing intent.

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 7 parameters, nested person objects, and no output schema, the description covers input intent well but leaves two material gaps: what actually comes back from a calculation, and how this differs from the sibling vedika_numerology_complete which shares the same 'complete' concept. Adequate to invoke, not complete enough to choose confidently.

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

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

Schema coverage is 100% so the baseline would be 3, but the description goes further by explaining the conceptual basis of each type (full name → destiny, consonants → personality, vowels → soul urge, birth date → life path), which lets an agent infer which inputs a requested type needs before reading the schema. It does not address 'system' or 'year' semantics beyond the enum labels already in the schema.

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

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

Names a specific verb+resource (numerology calculations) and enumerates every calculation type in the enum with a one-line meaning for each, so an agent can map intent to a type value. The one gap is that the sibling vedika_numerology_complete is never mentioned, even though this tool also exposes a 'complete' type — that overlap isn't disambiguated.

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 per-type glosses ('Life Path (birth date) = life purpose', 'Compatibility = two-person comparison') effectively tell the agent which type to select for which question, and the cost line gives a reason to prefer cheaper single types over 'complete'. No explicit when-not guidance or sibling routing (e.g. vs vedika_compatibility) is provided.

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 full burden. It does disclose pricing ($0.010/call), which is genuinely useful and not available elsewhere, but it says nothing about authentication, rate limits, error behavior for invalid dates, or whether results are cached.

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?

Front-loaded with purpose, then a compact enumeration of outputs and cost. The long output list is information-dense rather than padded, though it reads as a run-on sentence and could be structured as a list for scanability.

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 output schema and no annotations, the description does the work of describing return values by enumerating every computed number and noting the two supported systems plus cost. Remaining gaps are response shape/nesting and failure modes, which are minor for a deterministic calculation endpoint.

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

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

Schema description coverage is 100%, so all four parameters including the system enum and currentName are already documented. The description restates that Pythagorean and Chaldean systems are supported but adds no new semantics, making baseline 3 correct.

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

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

The description opens with a specific resource ('Full numerology report') and the enumeration of computed numbers makes the scope unambiguous. It does not explicitly name the sibling vedika_numerology (presumably the lighter variant), so the 'complete' differentiator 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?

'Combining all core numbers in a single call' hints at when to prefer this over a narrower numerology tool, but there is no explicit when/when-not guidance and no named alternative. The agent must infer that this is the comprehensive option versus vedika_numerology.

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 creditably discloses the per-call cost ($0.012), the location fallback to Delhi, and the shape of the return (5 limbs plus sunrise/sunset/moonrise). It says nothing about authentication, error behavior, caching, or precision/accuracy caveats for the computed values.

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 and output contents are front-loaded in the first two sentences, with operational details (defaults, cost) trailing. There is no filler; every sentence carries information an agent can act on.

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 output schema and no annotations, the description does the necessary work by naming what comes back and stating defaults and cost. Minor gaps remain around response structure (e.g., whether values are names or numbers) and whether partial results occur when element is set, but nothing critical for correct invocation is absent.

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

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

Schema description coverage is 100%, so all six parameters are already documented, making a baseline of 3 appropriate. The description does add one piece of meaning beyond the schema, framing the time parameter as useful for eclipse timings and specific muhurta, but it does not explain the element enum's effect on the response.

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 resource ('Hindu calendar (Panchang)') with an explicit scope ('today or a specific date/time') and enumerates the five returned limbs, so an agent knows exactly what the tool produces. It does not explicitly differentiate itself from near siblings such as vedika_calendar or vedika_muhurta, 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?

Usage is implied by 'for today or a specific date/time' and the defaults for date/time/location are spelled out, giving usable calling context. There is no explicit when-to-use guidance, no mention of when to prefer vedika_calendar or vedika_muhurta instead, 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?

With no annotations, the description carries the behavioral burden and does well by disclosing caching and billing: the first call per sign per day is charged and subsequent same sign+day calls are free. It also gives the cost range. It does not describe output format or error 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 core action and then packs period options, input modes, caching, sign-language support, and pricing into a compact set of sentences. Every sentence adds actionable information with no wasted prose.

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 six-parameter prediction tool with no output schema, the description covers invocation, period choices, input modes, caching, and pricing well. It is slightly incomplete because it does not explain the return shape and does not route the agent away from overlapping sibling astrology tools.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds useful conditional semantics beyond the schema: either rashi or datetime is needed, and sign names are accepted in English or Hindi. It does not fully document the datetime companion fields, which the schema handles.

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 clear verb and resource: get Vedic astrology predictions for a zodiac sign or from birth details, across specified periods. It is specific enough for an agent to know what the tool returns, but it does not explicitly distinguish itself from nearby siblings such as vedika_horoscope or vedika_daily_bundle.

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 explains the two input modes: provide rashi for sign-based predictions, or provide birth datetime to derive the Moon sign. However, it gives no explicit when-to-use guidance versus sibling prediction or horoscope tools, and no when-not-to-use conditions.

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 behavioral burden and does well: it discloses the calculation method (Atmakaraka, D9, BPHS Ch.33), the additional Devatas returned, the contents of each deity result, and the per-call cost. It does not cover permissions, rate limits, or error behavior, which keeps it from a 5.

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

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

The purpose is front-loaded in the first sentence, followed by method, secondary Devatas, output contents, and cost. Every sentence adds useful information 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?

Given no output schema and no annotations, the description adequately explains the calculation basis and enumerates return values including mantras, temples, worship day, and offerings. It is complete enough to call correctly, though it does not describe response structure or failure behavior in detail.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the schema. The description adds no parameter-specific meaning beyond the schema; its mention of mantras/temples/offerings relates to output content rather than 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 states a specific verb and resource: 'Determine the Ishta Devata (personal deity) from the birth chart,' and names the core technique (Atmakaraka and D9 placement). It does not explicitly contrast with nearby siblings like vedika_birth_chart or vedika_divisional_charts, so it stops short of a 5.

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

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

The intended use is implied by 'Determine the Ishta Devata ... from the birth chart,' so an agent can infer this is for personal-deity questions. However, there is no explicit when-to-use, when-not-to-use, or named alternative among siblings, and the cost note is not usage 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 and does well: it enumerates the returned fields (Devanagari + IAST, japa sankhya, muhurta, direction, mala material) and discloses per-call cost ($0.016/call). It stops short of noting auth requirements or failure modes for invalid birth data.

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?

Front-loaded with the core capability followed by return contents, an alternate mode, and pricing — all actionable. Slightly dense at four sentences but nothing is padding.

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?

No output schema exists, yet the description explicitly lists every returned field, which compensates well. For a 7-parameter, 4-required chart-based tool the only gap is the absence of any guidance on error handling for polar latitudes or invalid datetime.

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

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

Schema coverage is 100% with three enums, so the schema already documents all seven parameters thoroughly. The description adds only light reinforcement (chart-weakness defaulting, purpose-based overrides) rather than new syntax or format meaning, 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?

Specific verb + resource ('Get personalized mantra recommendations based on birth chart analysis') plus concrete sourcing of the mantras (Mantra Mahodadhi, BPHS remedies). It does not explicitly distinguish itself from nearby siblings such as vedika_lalkitab_remedies or vedika_spiritual_deity, so an agent must 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?

Usage is implied: 'Can also return mantras for specific purposes like career, health, or relationships' signals the purpose-driven mode, and the planet parameter covers the targeted mode. However, there is no explicit when-to-use guidance or exclusion versus the remedy/deity siblings.

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 does disclose a meaningful operational trait — the $0.020/call cost — and notes shadbala output is normalized 0-100. It says nothing about permissions/auth, rate limits, failure modes, or whether calls are cacheable, which for a paid computational endpoint is a real 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?

Front-loaded with the core purpose, then a compact per-mode breakdown; every clause maps to a selectable mode or a cost note. The parenthetical enumerations (seven upagrahas, six balas) are dense but do earn their place by previewing output 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?

There is no output schema, so the description should indicate what comes back; only shadbala's 0-100 normalization is hinted at, while return shapes for chandra-bala, tara-bala, upagraha, and planet-relationship are unstated. The required inputs (datetime/lat/long/timezone) are fully documented in the schema, so the missing piece is primarily the response shape.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's mode explanations largely restate the enum descriptions already in the schema (chandra-bala, tara-bala, upagraha, planet-relationship, shadbala), adding only marginal detail such as naming the individual upagrahas and the six bala components.

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

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

Specific verb + resource ("Calculate planetary strength and relationships") followed by an enumeration of the five calculation modes, so an agent knows exactly what the tool produces. It does not differentiate itself from siblings like vedika_ashtakavarga, vedika_doshas, or vedika_birth_chart, which also compute chart-derived metrics, so the sibling 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?

Usage is only implied through mode descriptions: chandra-bala is tagged "for muhurta timing" and shadbala is flagged "most comprehensive," which nudges selection. There is no explicit when-to-use / when-not-to-use guidance and no named alternative among the many vedika_* siblings that overlap in scope.

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 determinism/caching ("repeated calls return the same card"), the response shape, and an explicit per-call cost of $0.008. It omits error behavior and timezone handling for "today", which is why it isn't a 5.

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

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

Three short sentences, front-loaded with the core action, then return contents, then operational facts (caching, cost). No filler and every sentence carries distinct 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?

There is no output schema, and the description compensates by listing the returned fields, plus caching and cost. Only minor gaps remain: no note on which timezone defines "today" and no error/failure behavior for an invalid date.

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

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

Schema description coverage is 100% — both date (YYYY-MM-DD, defaults to today) and deck (enum with default rider-waite) are fully documented in the schema. The description adds no parameter-level detail beyond implying a date, so the 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?

States a specific verb and resource ("Get the tarot card of the day") and enumerates the returned fields, so the agent knows exactly what comes back. The daily/cached framing implicitly separates it from the sibling vedika_tarot_draw, but the alternative is never named, so the distinction is inferred rather than stated.

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?

"Cached per day — repeated calls return the same card" gives a useful usage hint (don't re-call expecting a new card) and the cost line supports budget decisions. However, there is no explicit when-to-use/when-not guidance and no routing to vedika_tarot_draw for a fresh random draw, leaving the choice between the two siblings 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?

With no annotations, the description carries the full burden and does disclose two things an agent genuinely needs: the cost ('$0.020-0.048/call') and the shape of each returned card ('upright/reversed orientation, suit, and position meaning'). It does not say whether draws are random or deterministic, whether repeated calls on the same question differ, or what rate limits apply.

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?

Front-loaded with the action, then spread-by-spread breakdown, then output content and price — a sensible ordering with no filler sentences. The spread enumeration is somewhat redundant against the schema enum and could be trimmed without losing agent-usable 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 zero-required-parameter, no-output-schema tool, the description covers what the tool does, how to pick a spread, and what comes back, which is enough to call it correctly. The absence of any note on determinism or on deck choice leaves minor gaps for a paid tool with no annotations.

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

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

Schema coverage is 100%, and the spread enum already documents the meaning and card count of every option, so the description's spread summary largely restates the schema. The deck parameter (rider-waite/thoth/marseille) is never mentioned in the description, so no meaning is added beyond structured data. 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?

States a specific verb and resource ('Draw tarot cards in a chosen spread layout') and enumerates each spread with card counts and thematic focus, so the agent knows exactly what the tool produces. It does not differentiate itself from the sibling vedika_tarot_daily, which is the obvious source of ambiguity for a tarot-related tool.

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 clear selection guidance among spread values ('Single = 1 card quick answer', 'Three-card = past/present/future or situation/action/outcome', 'Celtic Cross = 10-card comprehensive reading'), which is effectively when-to-use-which guidance. It stops short of exclusions or routing versus alternative tools such as vedika_tarot_daily or vedika_iching_cast.

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 so well: it discloses the unit convention (USD cents, divide by 100), the source-data ceiling (at most 1000 latest records) that silently bounds both history and aggregates, the absence of cursor/page continuation, and the specific response fields (truncated, scanLimit) that signal when results are incomplete. That last detail is the difference between an agent reporting bounded data as complete and not.

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?

Six tight sentences, each carrying a distinct fact: purpose, unit conversion, history bounds, no-pagination constraint, aggregate ceiling with sentinel fields, models grouping, and cost. Purpose is front-loaded and no sentence is filler, even where it overlaps the schema slightly.

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?

No output schema exists, so the description must cover return values, and it partially does by naming truncated and scanLimit and explaining the cents unit and tier grouping. It doesn't sketch the overall shape of wallet/history/summary responses, leaving some ambiguity about what fields come back, which keeps it just below full completeness.

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

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

Schema coverage is 100%, so both parameters are already documented, including the action enum meanings. The description restates the limit default/maximum and adds context that limit applies to history only, but does not add syntax or behavioral nuance the schema lacks. Baseline 3 applies when the schema does the heavy lifting.

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 resources: checking API usage, wallet balance, and billing history, plus the four action modes the tool serves. Against a sibling list composed entirely of astrology/Vastu domain tools, this is unambiguously the account/billing utility, so an agent can select it 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?

Makes the cost profile explicit ('Free — no cost to check'), which is exactly the kind of guidance that decides whether an agent should hesitate before calling. It also flags the absence of pagination up front so the agent doesn't plan a paging loop. It stops short of naming alternatives or stating when not to use it, though no sibling offers comparable functionality.

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 usefully discloses the Tajaka methodology, Sahams, Muntha, Tajaka yogas, sidereal zodiac, and per-call cost, but it does not state whether the operation is read-only, what permissions or rate limits apply, or what the response contains.

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 four tight sentences, front-loads the tool's identity and purpose, and includes the key differentiator and cost without wasted wording.

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 calculation tool with no output schema, the description explains the underlying system and components but does not describe the return structure or what the resulting annual horoscope includes. It is sufficient to understand the purpose, but not fully complete for an agent needing to interpret results.

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

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

Schema description coverage is 100%, so all six parameters are already well documented in the input schema. The description only indirectly implies year, sidereal correction, and birth data through concepts like 'each year' and 'sidereal zodiac,' adding little beyond the schema.

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

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

The description names a specific resource (Vedic annual horoscope / Varshaphal) and explains its defining calculation: the exact moment the Sun returns to its natal sidereal position. It also distinguishes itself from the Western Solar Return sibling by noting the sidereal zodiac and Tajaka system.

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 clearly differentiates this tool from vedika_western_solar_return by stating that this uses the sidereal zodiac and Tajaka system, so an agent can route sidereal annual-return requests here. However, it does not explicitly state when to prefer this over other Vedic tools such as vedika_horoscope or vedika_panchang.

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 disclosure burden and does well: it names the zodiac convention (tropical), quantifies rates of motion so results can be sanity-checked, and discloses cost ($0.092/call). It omits error behavior and timezone handling, but those are covered by 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?

Front-loaded with the technique name, then moves through motion rates, mode meanings, zodiac, and cost in tight sentences with zero padding. Every clause adds usable 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?

No output schema exists, so the description's explanation of what 'chart', 'positions', and 'aspects' return is essential and present, as is cost. Minor gaps remain around timezone defaults and output size, but the core is complete enough to invoke correctly.

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

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

Schema description coverage is 100%, so the baseline is 3; the description goes beyond it by adding interpretive meaning to the mode outputs and the planetary motion rates that let an agent judge whether a progressed position is plausible. The mode wording largely duplicates the enum 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 technique (secondary progressions, 'a day for a year') and resource, plus what the three output modes yield. It is clearly distinct from transit-style siblings by naming the technique, though it never explicitly contrasts itself with vedika_western_transits.

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?

Explains what each 'type' mode returns, which helps pick within the tool, but gives no guidance on when to use progressions versus transits or solar return, and no prerequisites. Usage is implied 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?

No annotations are provided, so the description carries the behavioral burden. It usefully discloses cost per call, tropical zodiac system, and gender-neutral person slots, but does not state whether the operation is read-only, what the response contains, or any error/rate-limit 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?

Four compact sentences, front-loaded with purpose, then chart-type explanations, then input/zodiac/cost details. No filler or redundant repetition.

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 paid two-person astrology calculation with a fully documented schema, the description covers chart semantics, zodiac system, and cost. It omits selection guidance versus sibling relationship tools and any return-shape guidance, leaving some context 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 100%, so parameter documentation is already strong. The description adds conceptual meaning for the type enum and clarifies that person1/person2 are gender-neutral, going slightly beyond what the schema provides.

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 Western relationship astrology and specifies synastry and composite charts for two people, with a clear distinction between the two chart types. It does not explicitly name sibling tools such as vedika_compatibility, so sibling differentiation is implicit rather than direct.

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?

Explains what synastry vs composite mean and, via the schema enum, which type to choose, but gives no explicit when-to-use or when-not guidance relative to sibling tools like vedika_compatibility or vedika_matrimony_match. Usage is only implied by the relationship-astrology framing.

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

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

With no annotations, the description carries the full burden, and it does disclose two genuinely useful behavioral facts: the tropical zodiac convention and a per-call cost of $0.120. It says nothing about error conditions (e.g. the polar-latitude rejection documented only in the schema), authentication requirements, or response size, so the disclosure is partial rather than complete.

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, followed by the mode breakdown and the cost note, with no filler sentences. Minor redundancy comes from re-explaining the type enum values that the schema already spells out.

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 six-parameter tool with no output schema, the description usefully enumerates what each mode returns, which substitutes for missing return documentation. It is nearly complete, though the absence of any sibling routing and of error-behavior notes leaves small 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 100%, so every parameter including the type enum, year range, and latitude/timezone constraints is already documented in structured form. The description's restatement of the three type modes largely duplicates the enum descriptions, and it adds no meaning about how 'year' interacts with 'datetime' for the return calculation.

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 — casting a Western solar return chart at the moment the transiting Sun returns to its natal position — and clarifies the concept with the parenthetical 'solar birthday'. It does not, however, differentiate itself from the closest sibling, vedika_varshaphal, which is the Vedic annual-return chart, so an agent still has to infer the boundary between 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 explicit guidance on when to choose this over vedika_varshaphal, vedika_western_transits, or vedika_western_progressions, all of which occupy adjacent territory. Usage is only implied by the phrase 'themes for the coming year', leaving routing decisions 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?

With no annotations, the description carries the full burden and does well: it discloses the ephemeris backend, the tropical/no-ayanamsa convention, per-mode output contents, and an explicit cost of $0.064/call. It doesn't state that the call is a pure computation with no side effects, nor anything about error/failure modes, which keeps it below a 5.

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

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

Four short sentences, front-loaded with the purpose and zodiac convention, then the mode breakdown, then cost. No filler; every clause carries either scope, mode semantics, or pricing.

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?

No output schema exists, so the description must imply return values — and it does at a mode level ('full transit overlay', 'aspects ... with orbs'). Combined with the schema's thorough parameter docs and the required datetime/lat/long/timezone set, an agent has enough to call it correctly; only granular return shape is left unspecified.

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

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

Schema coverage is 100% and each field (including the enum for 'type' and the polar-latitude rejection) is already documented in the schema. The description's mode summary adds a little interpretive value but nothing about formats or defaults (e.g. transitDateTime defaulting to now) beyond what the schema states, 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 states a specific verb+resource ('Western astrology current transits against a natal chart') and pins down the zodiac convention ('Tropical zodiac, no ayanamsa'), which implicitly separates it from the Vedic birth_chart/dasha tools and from western_progressions/solar_return. It stops short of naming those siblings 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?

It clearly disambiguates the three internal modes ('chart' = full overlay, 'positions' = current planets, 'aspects' = transit-to-natal with orbs), which is real selection guidance. However, it never says when to reach for this tool versus vedika_western_progressions, vedika_western_solar_return, or vedika_birth_chart, so the cross-tool routing 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.