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

Annotations already cover readOnly, idempotent, non-destructive and closed-world behavior, so the bar is low. The description still adds real value by disclosing the permission profile (accessible to every role) and by naming the fields returned, which the annotations do not convey.

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?

Two compact clauses with the resource named first and supporting details second, so it is front-loaded and free of filler. It reads slightly as a field dump rather than a sentence, which keeps it just short of ideal.

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?

For a zero-param read with full annotation coverage and no output schema, the description supplies the returned fields and the access scope an agent would otherwise have to guess. Nothing critical is missing, though it could note how it relates to the overlapping get_plan/get_viewer siblings.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. No syntax, ordering or filtering caveats are needed for a no-arg getter.

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?

States a specific resource (the organization) and enumerates the fields it surfaces (name, slug, plan, creation date, member count), which distinguishes it from sibling getters like get_plan and list_members. It never uses an explicit retrieval verb, so the read nature is only implied, but the scope is clear.

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?

"Every role holds it" gives useful access context and "Mirrors Settings › General" locates it conceptually, but there is no explicit when-to-use guidance or routing versus alternatives such as get_plan or get_viewer, both of which overlap on org-level data.

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