tomticket_list_organizations

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

With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly states 'Nao altera dados' (does not alter data), which establishes this as a read-only operation, and mentions the 50-per-page behavior. However, it does not disclose return formatting, whether results are ordered by default, or any rate-limit implications. Still, the key safety profile is addressed.

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 single, well-structured sentence that front-loads the core purpose, then supplies the pagination detail and the non-destructive guarantee. Every word earns its place; there is no fluff or 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?

Given five optional parameters, zero schema descriptions, no annotations, and no output schema, this description is too thin to be fully complete. It covers the operation's read-only nature and page size but leaves parameter semantics, filtering/sorting behavior, and expected response structure entirely undocumented. The agent could list organizations, but correct use of the advanced parameters remains speculative.

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 for the blind spots in the input schema. It only mentions the 50-per-page default, which is not one of the five parameters. It provides no guidance on 'page', 'order', 'column', 'show_custom_fields', or 'organization_mother_id'. An agent would have to infer semantics purely from parameter names, which is unreliable especially for 'show_custom_fields' and 'organization_mother_id'.

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 verb ('Lista'), a clear resource ('organizacoes da conta' / organizations of the account), and adds the pagination detail of 50 per page. It also explicitly distinguishes itself from mutating operations by saying it does not alter data. This is sufficiently specific to separate it from sibling list tools like tomticket_list_customers or tomticket_list_departments.

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 makes clear when to use the tool: any time an agent needs to list organizations from the account, with a 50-per-page constraint that hints at pagination. It does not explicitly mention alternatives or exclusions, but among the siblings there is no other organization-listing variance requiring disambiguation, so the context is reasonably clear.

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