get_object

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

No annotations are provided, so the description carries the full burden. It discloses return content and the impact of the detail parameter (e.g., 'full' can be large), which is helpful. However, it does not explicitly state that the operation is read-only or has no side effects, which would be expected for a getter without annotation cover.

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 paragraph with several useful clauses. It front-loads the core purpose and packs relevant context (like the register periodicity note and query table names) without excessive verbosity. It's slightly long but every sentence adds 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?

Given an output schema exists, return values are covered elsewhere. The description explains when to use the tool, the meaning of detail levels, and provides a crucial behavioral note about field name substitution in queries. This makes it largely complete for an agent to call 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% and each parameter is described, giving a baseline of 3. The description adds value by explaining that 'full_name' comes from search_objects and by clarifying the semantics of the 'detail' parameter (brief/fields/full with usage guidance), going beyond the schema's bare 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?

The description clearly states the tool retrieves the structure of a configuration object, enumerating specific components (attributes with types, tabular sections, movements, predefined). It also positions it as a mandatory step before coding or querying, which makes the purpose unambiguous and distinct from broader search tools like search_objects.

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 is a required step before writing code or queries, and contrasts it with search ('Только здесь видно то, от чего код зависит и чего нет в поиске'), which gives clear when-to-use context. It doesn't name specific sibling tools like get_related or get_procedure, but the usage intent is well defined.

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