Skip to main content
Glama

Remove an arrow

unlink_goals
DestructiveIdempotent

Remove the arrow from one goal to another. The goals stay.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
to_goal_idYes
from_goal_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description usefully adds that only the link is removed and 'the goals stay', which counters assumptions that a destructive arrow removal might delete entities. It says nothing about behavior when the link doesn't exist or about error cases.

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?

Two short sentences, operation stated first, and the clarifying constraint front-loaded immediately after. No filler and nothing redundant with the title.

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?

For a two-UUID mutation with no output schema, the definition is minimally viable: the idempotent and destructive annotations cover safety, and 'the goals stay' clarifies scope. However, it omits what happens on a missing link, whether direction matters, and any reference to the inverse tool.

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% and neither parameter has a description, so the description must carry the burden. 'From one goal to another' weakly implies directionality (from_goal_id → to_goal_id), but it never states that the two required UUIDs are source and target, nor that the arrow is directional.

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

Purpose4/5

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

States a specific verb ('Remove') and resource ('the arrow from one goal to another'), making the operation unambiguous. It does not name the sibling `link_goals` as its inverse, but the operation is still clear enough to be distinguished from add/delete/list tools.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance, no prerequisites, and no reference to the obvious alternative (`link_goals`) or to `delete_goal` as the contrasting destructive-removal tool. Usage must be inferred purely from the name and the short purpose sentence.

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