ddb_get_party_snapshot

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 implies a read-only operation via 'snapshot' and lists return data, but it does not explicitly state that the tool makes no modifications, nor does it disclose any failure modes, rate limits, or authentication needs. It does add context about being the 'authoritative' source, but for a read tool this is a marginal improvement. A 3 is appropriate given the clear but implicit safety profile.

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 three tightly packed sentences with zero filler. It front-loads the core purpose, explains the key differentiator, and then details parameter behavior. Every sentence earns its place and avoids redundancy with the schema.

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 read-only snapshot tool with 3 parameters, no output schema, and no nested objects, the description fully covers the return values, the two call modes, defaults, and the optional full expansion. An agent has everything needed to invoke it correctly without additional inference. No gaps that would cause mis-calls.

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 100%, with each parameter already described (full, campaignId, characterIds) including defaults and override behavior. The description reiterates these points but does not add meaning beyond what the schema provides; it does weave the params into a usage narrative, but that is overlap, not augmentation. Baseline 3 is correct.

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 clearly states the tool's function: 'Precomputed combat snapshot for a whole party in one call' and enumerates the exact computed fields returned (AC, max/current/temp HP, conditions, death saves, etc.). It explicitly differentiates from the sibling ddb_get_character by declaring itself 'the authoritative AC/maxHP source' and directing the agent to prefer it for live party status. This is a specific verb+resource with strong sibling differentiation.

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 explicit guidance on when to use this tool over an alternative: 'prefer it over ddb_get_character for live party status.' It also explains the two invocation modes (characterIds or campaignId with default to DDB_CAMPAIGN_ID) and the effect of the full parameter. No explicit 'when not to use' is given, but the directive plus the mode explanations are sufficient for an agent to choose correctly.

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