Skip to main content
Glama

UntagGraphArtifact

Destructive

Delete a graph artifact tag from a graph, the same write that rover graph-artifact untag performs. The tag and its full history are removed, and any router that fetches by that tag can no longer resolve it. The artifact itself stays. Tags that Apollo manages, such as a variant's latest tag, cannot be deleted. Returns the deleted tag name, or an error with a message. Provide the graph ID and the tag name.

Input Schema

NameRequiredDescriptionDefault
tagYes
graphIdYes

Output Schema

NameRequiredDescriptionDefault
dataNo
errorsNo
extensionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Goes well past the annotations by disclosing exactly what is destroyed: the tag and its full history are removed, routers fetching by that tag can no longer resolve it, but the artifact itself survives. It also names the protected-tag restriction and the return/error behavior, which is substantial added value over destructiveHint=true alone.

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?

Front-loads the action and destruction consequences, with the parameter instruction last. Minor redundancy in 'Delete a graph artifact tag from a graph' restating the name, but the remaining sentences each add information.

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?

An output schema exists, so return values need little explanation, yet the description still states it returns the deleted tag name or an error. Coverage of destruction, restrictions, and required inputs is solid; the gap is only in richer parameter guidance (format of graphId/tag).

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry parameter meaning, but it only says 'Provide the graph ID and the tag name' — repeating the property names without format, scope, or examples. An agent gains no more than the schema's key names tell it.

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 and resource ('Delete a graph artifact tag from a graph') and anchors it to the concrete CLI equivalent 'rover graph-artifact untag'. Combined with the sibling TagGraphArtifact, the inverse relationship is unambiguous, so an agent can pick it out of the list without opening the schema.

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?

Provides clear applicability context: it is for removing an artifact tag (not the artifact), and it explicitly excludes Apollo-managed tags such as a variant's latest tag. It does not spell out when to prefer alternatives (e.g. re-tagging instead of untagging), so it falls short of full when/when-not guidance.

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