vastu_reference

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.