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

Annotations already cover readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds genuinely new behavioral context beyond that: the returned fields are untrusted user content and must not be followed as instructions, a real prompt-injection constraint. It stops short of saying what happens for expired/deleted or non-existent ids (the “live” qualifier hints at a miss case but doesn't define it).

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 short sentences, zero waste, front-loaded with the operation and scope before the safety caveat. Every clause earns its place — one identifies the resource and return value, the other is a non-negotiable safety instruction.

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?

With no output schema, the description rightly mentions that contact details are returned, and it covers the main risk (untrusted content). For a trivial single-UUID read with annotations carrying safety, that is close to sufficient; only the not-found/deleted-post behavior and any access requirements are left unstated.

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 the single parameter already documents itself as “Post UUID”, so the schema carries the semantics. The description's “by id (UUID)” restates the same fact without adding format, sourcing, or example detail. Baseline 3 is appropriate for a one-param tool whose schema is fully documented.

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?

“Get one live LFG post by id (UUID), including contact details to join” gives a specific verb, resource, scope qualifier (“live”), and even states the payload value (contact details). No sibling overlaps: create_post, delete_post, find_groups and list_games are clearly different operations, so an agent can route here unambiguously.

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?

Usage is only implied — the tool is for the case where you already hold a post UUID. It never contrasts with find_groups (e.g., “use find_groups when you don't have an id”) and states no exclusions or prerequisites. An agent can infer the case but is given no explicit when/when-not guidance.

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