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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds critical behavioral details: the token economy (call with no args for lightweight list, then with section id for full content), and the lang parameter for Russian users. No contradictions with annotations.

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 well-structured, starting with the purpose, then specific instructions, and a note on language. It is informative but slightly verbose; every sentence is useful, though some redundancy could be trimmed. Still, it remains clear and scannable.

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

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

Given the absence of an output schema, the description fully explains what the tool returns: a lightweight list of section ids and titles when called with no arguments, or the full content of a specific section when called with a section id. It covers both invocation patterns and the lang parameter, making it complete for an agent to use 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 coverage is 100% with both parameters described. The description adds meaning beyond the schema: it explains the exact usage pattern (omit section for table of contents, provide section id for content) and clarifies when to use the lang parameter. While the schema descriptions are adequate, the description enriches the context.

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

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

The description clearly states the tool is a 'Project reference / help desk about Fractera' for answering any user question about Fractera. It distinguishes from siblings by specifying broad coverage (architecture, components, modes, etc.) while siblings like check_status or get_subdomain are more narrowly focused.

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?

Explicitly says 'use this to answer ANY user question about Fractera' and gives a when-not context: 'especially while a deploy is running and the user wants to learn more'. It provides a clear two-step process (token economy) with specific instructions on how to call the tool effectively.

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