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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by explaining that results are 'source-attributed passages' and instructing the agent to 'synthesize your answer from them and cite the sources.' This goes beyond annotations by clarifying the expected output format and usage protocol, though it does not cover edge cases like empty results or pagination.

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

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

The description is two sentences long, front-loaded with the core action, and every clause earns its place. It states the tool's purpose, outlines the corpus, notes output characteristics, and gives usage guidance without redundancy. This is exemplary conciseness and structure.

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

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

Given no output schema, the description sufficiently conveys what the tool returns (source-attributed passages) and how to use them. It also positions the tool within the static-syllabus niche relative to siblings. It lacks explicit statements about result counts, error conditions, or the relationship between top_k and response size, but these are not critical for basic usage. The description is complete enough for an agent to invoke and interpret results 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 67%, and the description does not elaborate on parameter details beyond what the schema provides. The query parameter already has a clear description ('What to look up, phrased as a topic or question'), and subject references list_study_topics. top_k has no prose description but is constrained by defaults and min/max in the schema. The description adds no new parameter-level meaning, so it does not exceed the mid-range baseline.

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

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

The description opens with a specific verb+resource: 'Semantic search over Sambodh's indexed UPSC corpus (NCERTs + standard references).' It clearly states what it does, what corpus it searches, and that it returns source-attributed passages. This distinguishes it from sibling tools like get_current_affairs and get_pyq_sample by scoping it to static-syllabus content with a retrieval-and-synthesis workflow.

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

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

The description gives clear context: 'Use for static-syllabus questions (history, polity, geography, economy...).' This implies it is not for current affairs or dynamic topics, but it does not explicitly name an alternative tool or state a 'when-not-to-use' exclusion. Since it provides a clear usage domain without explicit exclusions, it earns a 4 rather than a 5.

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