Skip to main content
Glama

iyke_session_move

Move a chat thread between projects without restarting the subprocess. Transfers only metadata; fails if target project is unknown or archived.

Instructions

Move a chat thread between projects. Metadata-only — does not restart the claude subprocess. The cwd captured at spawn time stays whatever it was. Fails if the target project is unknown or archived.

Input Schema

NameRequiredDescriptionDefault
thread_idYes
project_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations provided, the description discloses key behavioral traits: metadata-only, no restart of claude subprocess, cwd unchanged, and failure on unknown/archived project. It adds value beyond the schema but could mention side effects or return type.

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 sentences, each earning its place: purpose, behavioral limitation, failure condition. No redundancy or excess. Front-loaded with the core action.

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

Completeness3/5

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

Given no output schema and 2 required params, the description covers purpose and key behavior but omits how to obtain thread_id or project_id, and the return value. With sibling tools like session_list and project_list available, referencing them would improve completeness.

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 0%, so the burden is on the description. It explains project_id implicitly via constraints (unknown/archived), but thread_id is only implied as 'chat thread'. Neither parameter gets explicit format or source guidance.

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 clearly states 'Move a chat thread between projects' with a specific verb and resource. It also distinguishes from sibling tools by noting 'Metadata-only — does not restart the claude subprocess', making its scope explicit.

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

Usage Guidelines3/5

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

The description implies when to use the tool (moving a thread) but does not provide explicit alternatives or when-not-to-use guidance. It only states a failure condition, lacking comparison to sibling tools like session_list or project_set_active.

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