get_r_report_queries_registry_problems_company

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read-only GET operation via 'Retrieve records' and 'Calls GET', which is useful, but it does not disclose authentication requirements, rate limits, return-format behavior, or pagination semantics. The vague 'any required request headers in headers' hints at needed headers without saying which ones.

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 text is short and front-loaded with the core action and endpoint, and it packs useful parameter-placement information into two sentences. Minor grammatical awkwardness ('Retrieve records Calls...') slightly hurts structure but does not waste space.

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?

While an output schema exists and return-value documentation is not required, the description still lacks essential context: what the retrieved 'registry_problems_company' records actually represent, which path parameters are needed, what filters are supported, and which headers may be required. For an agent choosing among a huge list of similar report-query tools, this is incomplete.

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%, so the description must compensate. It adds some meaning by mapping path_params to route IDs, query to filters and pagination, and headers to required request headers. However, the mapping is generic, omits the body parameter entirely, and gives no concrete parameter names or formats, leaving the agent to guess at actual query/filter keys.

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 states a specific action ('Retrieve records') and names the exact endpoint (`GET /r/report_queries/registry_problems_company`), so an agent knows which resource is being accessed. Though 'records' is generic and the path itself is cryptic, the endpoint and tool name together identify this as the company registry-problems report query, distinguishing it from other report-query endpoints at the route level.

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 mechanical guidance about where to put parameters (path_params, query, headers) but provides no guidance on when to use this tool versus any of the many sibling report-query tools. It does not name alternatives, state conditions for selection, or note exclusions.

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