Skip to main content
Glama

remove_attribute

Removes a project attribute while recording its last value and removal reason in the case file. The attribute's history remains intact, and a later set can recreate it.

Instructions

Removes a project attribute and files an attribute_removed entry in the project's case with its last value and the reason. The attribute's history stays in the case; a later set_attribute with the same name creates it anew.

A name that matches no attribute of the project is refused with attribute_not_found. A task token removes attributes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesProject key, case-insensitive. An unknown key is refused with `project_not_found`
nameYesAttribute name: Latin letters, digits, `_` and `-`, at most 64 characters (`invalid_attribute_name` otherwise). Matching ignores case
reasonYesWhy the attribute is removed; a blank one is refused with `attribute_reason_required`. Filed in the `attribute_removed` entry together with the last value
idempotency_keyNoRetry key chosen by the caller, e.g. a UUID. A repeat with the same key and the same arguments returns the first result and creates nothing; the same key with other arguments is refused with `idempotency_key_reused`. A key is bound to the caller's token and kept for 24 hours

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noYesNumber of the `attribute_removed` entry in the project's case
nameYesName as it was stored
project_keyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.2

TDQS

A4.3/5.0
Behavior5/5

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

The description discloses important behaviors beyond the annotations: history stays in the case, a later set_attribute recreates the attribute, missing attributes are refused, and a task token is required. This adds genuine context that the false annotation hints alone do not provide.

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?

The description is concise and well-structured: the main behavior and side effect come first, followed by persistence semantics and error/token constraints. Every sentence earns its place with no filler.

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?

The description covers the operation, side effects, persistence, error cases, and authentication context. Since an output schema exists, return-value details need not be described, and nothing essential appears missing.

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?

The input schema already documents all parameters with validation details and error behavior, giving 100% schema description coverage. The tool description adds little parameter-specific meaning beyond referencing the reason and last value, so the baseline of 3 is appropriate.

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 states a specific action and resource: 'Removes a project attribute' and the side effect 'files an attribute_removed entry'. This clearly distinguishes it from siblings such as set_attribute and update_project.

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 use case is implied by 'Removes a project attribute' and the error conditions, but the description never explicitly says when to choose this over set_attribute or other siblings. It does provide useful context about the required task token and the attribute_not_found condition.

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