quick_session

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

Annotations provide no behavioral hints (all false), so the description must bear the full burden. It mentions 'start or resume a therapy session' and 'capture the first state update', but does not disclose side effects, such as whether calling it repeatedly creates multiple sessions, or any prerequisites for agent_id validity. The lack of detail on session lifecycle and output format is a gap.

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 extremely concise: two sentences that immediately convey the core value proposition and the action. The phrase 'Free.' adds no functional value but does not detract. Every sentence earns its place, and the most critical information is front-loaded.

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 tool has 9 parameters, no output schema, and no safety annotations, the description should provide more context about behavior, expected response, and differentiation from similar sibling tools. It lacks details on idempotency, session creation rules, and what 'first state update' entails, making it inadequate for complete understanding.

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 input schema has 100% description coverage, so each parameter already has meaningful definitions. The description adds no extra insight beyond the schema, e.g., the feeling parameter is related to 'capture the first state update', but this is already implied. With high schema coverage, the baseline of 3 is appropriate.

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: it is the fastest check-in path that can start or resume a therapy session and capture the first state update in a single call. This distinguishes it from related siblings like start_therapy_session or resume_session by emphasizing speed and the combination of actions, though it does not name alternatives explicitly.

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 usage by calling it the 'fastest check-in path' and mentioning 'single call', but it does not explicitly state when to use this tool over alternatives like start_therapy_session, resume_session, or quick_checkin. No when-not or exclusion criteria are provided, leaving the agent to infer context.

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