inspect_project_game_campaign

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

Beyond the readOnly/idempotent annotations, the description adds significant behavioral context: it always fetches and validates the authenticated server-owned snapshot, rejects caller-supplied project/plan/cockpit JSON, and never falls back to the SDK's offline orientation helper. This meaningfully clarifies edge behavior an agent could not infer from annotations alone.

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 compact and well-structured: the alias relationship is front-loaded, followed by two precise behavioral restrictions. Every sentence earns its place, with no redundant or filler content.

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 the single required parameter, rich annotations, and output schema, the description covers the essential behavioral context: what it fetches, what inputs it rejects, and what it does not fall back to. Nothing critical is missing for an agent to call this tool correctly.

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 schema has 0% description coverage, but the description references project_id in the alias signature and ties it to fetching the authenticated server-owned snapshot. This gives some semantic context, though it does not explain the parameter's broader meaning, constraints, or how it maps to the game campaign concept.

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 it is a compatibility alias for get_project_game_snapshot(project_id), with explicit verbs: it 'fetches and validates the authenticated server-owned snapshot.' This is specific about what the tool does, and the alias framing distinguishes it as a backward-compatibility entry point rather than a general inspection utility.

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 implies when to use the tool via 'Compatibility alias' and the constraint that it no longer accepts caller-supplied JSON or falls back to offline orientation helpers. However, it never explicitly states when to prefer this over get_project_game_snapshot or names alternative tools for other use cases, so guidance is mostly implied.

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