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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description goes well beyond them by disclosing the two authentication paths, the exact credential format (Bearer tra_...), the fact that the workspace cannot be passed as a parameter, and the role-based authorization outcome including that refusals explain the remedy. Those are the details an agent needs to predict success or failure before calling.

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?

Dense and front-loaded with no filler sentences, and the permission constraint is placed early where it matters. It loses a point because the opening sentence is a syntactically broken fragment ("With your trooth.co sign-in, or the workspace's agent key with the settings area (Bearer tra_...).") that a reader must parse twice to extract the authentication rules.

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-parameter read tool with a full output schema and rich annotations, the description covers everything left open: how to authenticate, where scope comes from, who is permitted, what data is returned, and that the operation is read only. Nothing an agent needs in order to call it correctly is missing.

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?

There are zero parameters, so the baseline is 4, and the description earns the extra point by explaining the design: scope comes from the sign-in or key rather than from an argument. That preempts an agent from attempting to pass a workspace identifier to a tool whose schema forbids additional properties.

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 verb and resource ("Reads Team on trooth.co") and then enumerates exactly what comes back: every member and invitation with role and status, access requests from the public page, and the workspace's teams with their membership. That detail cleanly separates it from the mutating siblings (trooth_team_invite, trooth_team_member_role, trooth_team_group_create), which an agent can rule out without opening a schema.

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?

Gives clear context for use: authenticated via trooth.co sign-in or an agent key with settings-area access, and explicitly states the workspace is derived from the credential, never an argument. It also states the permission gate ("Only an owner or admin reads it; another role is refused with what to do"). It stops short of naming alternatives for team management, so it is strong but not a full when/when-not/alternative statement.

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