Skip to main content
Glama

Archive a sphere

archive_sphere
Destructive

Archive a sphere: it leaves every section, past tasks and goals keep it. Only when the user clearly asks to remove it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sphereYesSphere name (case-insensitive) or id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=false, so the safety profile is partly covered. The description adds real value beyond that: it discloses that historical tasks and goals still reference the archived sphere, softening what 'destructive' means in practice, and imposes a user-intent gate. It stops short of saying whether archiving is reversible or how to restore.

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

Conciseness4/5

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

A single compact sentence with the action front-loaded and the consequence and gating condition following. The clause 'past tasks and goals keep it' is slightly compressed/elliptical but still parseable; nothing is wasted.

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

Completeness4/5

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

For a one-parameter mutation with full schema coverage and annotations carrying the safety profile, the description supplies the key behavioral nuance (history preserved) and the intent condition. Missing only reversibility/restore guidance, which is a minor gap for this simple tool.

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?

Only one parameter, and schema coverage is 100% — the schema already documents that 'sphere' accepts a case-insensitive name or id. The description adds no format, matching, or ambiguity-resolution detail, so the baseline 3 applies.

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?

States a specific verb+resource ('Archive a sphere') and immediately clarifies the semantic scope: the sphere leaves every section but past tasks and goals retain it. This implicitly differentiates archiving from the deletion siblings (delete_goal, delete_task, delete_focus_point) by contrasting it with 'remove'.

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

Usage Guidelines4/5

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

Gives an explicit gating condition — only archive when the user clearly asks to remove it — which is genuine when-to-use guidance rather than implied. It does not, however, name an alternative (e.g., update_sphere for renaming, or any restore path), so the guidance is clear but incomplete.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources