Skip to main content
Glama

agy_session_followup

Resume an existing Antigravity conversation to keep previously loaded files in context cache and ask multi-turn follow-up questions, with automatic compaction when context usage exceeds 80%.

Instructions

Resume an existing Antigravity conversation ID (--conversation ) so previously loaded files remain in context cache, automatically compacting the session if context usage exceeds 80%. WHEN TO USE: Multi-turn follow-up questions on an existing Session ID returned by a prior agy_delegate_research or agy_delegate_edit call. DO NOT USE FOR: Starting a brand-new research task without a prior session (use agy_delegate_research instead). RETURNS: Follow-up response, optional compaction notice, and updated session telemetry.

Input Schema

NameRequiredDescriptionDefault
cwdNoOptional working directory path.
modeNoExecution mode for the follow-up turn (defaults to plan).plan
tierNoOptional model tier override (defaults to the session model).
promptYesFollow-up instructions or question for the cached session.
conversation_idYesThe agy conversation_id UUID from a previous tool call telemetry footer (or "latest" to resume the most recent session).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.2.1
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / conversation_id / description
      Previous value: -"The agy conversation_id to resume (or \"latest\" to resume the most recent session)."New value: +"The agy conversation_id UUID from a previous tool call telemetry footer (or \"latest\" to resume the most recent session)."
    • addedInput schema / properties / conversation_id / minLength
      Added value: +1
    • changedInput schema / properties / cwd / description
      Previous value: -"Optional working directory."New value: +"Optional working directory path."
    • addedInput schema / properties / mode / default
      Added value: +"plan"
    • changedInput schema / properties / prompt / description
      Previous value: -"Follow-up instructions or question."New value: +"Follow-up instructions or question for the cached session."
    • addedInput schema / properties / prompt / minLength
      Added value: +1
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the mutation profile is covered. The description adds genuine behavioral context beyond that: files stay in the context cache and the session auto-compacts above 80% usage, which the agent could not infer from structured fields. It stops short of describing permission/auth requirements or what a compaction notice implies operationally.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three front-loaded blocks — purpose, WHEN/DO NOT USE, RETURNS — with no filler sentences. The cache and compaction details are folded into the opening sentence rather than padding a separate section.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although no output schema exists, the RETURNS section enumerates the follow-up response, optional compaction notice, and updated telemetry. Combined with the WHEN/NOT routing and cache behavior, an agent has everything needed to select and invoke this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and every parameter is already documented, including the enum values for mode and tier. The description only echoes the conversation_id syntax ('--conversation <id>') and adds nothing about mode, tier, or cwd semantics, so it sits at the baseline where the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Resume an existing Antigravity conversation ID') and immediately adds the mechanism (--conversation <id>) plus the cache-preservation rationale, so the agent knows exactly what the tool does that a fresh call would not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides an explicit WHEN TO USE clause bound to a prior `agy_delegate_research`/`agy_delegate_edit` session ID, and an explicit DO NOT USE FOR clause routing brand-new tasks to `agy_delegate_research`. Both the trigger condition and the named alternative are stated, leaving nothing to inference.

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