Retrieve a document's table of contents, including sections and articles with element IDs, to locate the exact article title when a direct article search fails.
Оглавление документа: разделы и статьи с идентификаторами элементов.
Полезно, когда garant_article не нашёл статью — посмотреть, как она названа в акте.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the return structure (sections, articles, element IDs) and the useful fallback scenario, but it does not mention error behavior, prerequisites, or how the tool behaves when doc_id is invalid.
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 concise sentences, front-loaded with the core purpose and followed by a practical usage note. Every sentence adds value with no 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?
The tool is simple with one required parameter and an output schema already present, so return values do not need elaboration. The description provides purpose and a concrete use case, but the undocumented doc_id parameter and lack of behavioral notes keep it slightly short of fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate: doc_id is never explained in terms of format, origin, or how to obtain it. The word 'document' in the description hints at the parameter's role, but an agent is left to infer the ID source and expected value.
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 returns a document's table of contents: sections and articles with element identifiers. It also distinguishes itself from the sibling garant_article by describing a specific fallback scenario, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this tool is useful when garant_article does not find an article, providing clear when-to-use guidance and naming an alternative. It lacks explicit 'when not to use' exclusions, but the stated context is sufficient for most agent decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.