Skip to main content
Glama

Pipeline Item Write Tool

pipeline-item-write
Destructive

Add, remove or move pipeline cards. add requires pipeline_id, stage_id, itemable_type and itemable_ref; remove requires pipeline_item_id; move requires pipeline_item_id and stage_id. Sales pipelines accept users, companies and deals; production pipelines accept orders. Changes can trigger configured automations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform.
stage_idNoPipeline stage id. Required for "add" and "move".
sort_orderNoOptional 0-based position within the destination stage for "move". Defaults to top.
pipeline_idNoPipeline id. Required for "add".
itemable_refNoEntity reference. Required for "add". Orders use order number; users, companies and deals use id.
itemable_typeNoType of entity to add. Required for "add". Sales pipelines accept user, company or deal; production pipelines accept order. For "list" filters, user/company/order/deal aliases are accepted.
pipeline_item_idNoPipeline item id. Required for "show", "remove", and "move".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / itemable_ref / description
      Previous value: -"Entity reference. Required for \"add\". Orders use order number; users and companies use id."New value: +"Entity reference. Required for \"add\". Orders use order number; users, companies and deals use id."
    • changedInput schema / properties / itemable_type / description
      Previous value: -"Type of entity to add. Required for \"add\". Sales pipelines accept user or company; production pipelines accept order. For \"list\" filters, user/company/order aliases are accepted."New value: +"Type of entity to add. Required for \"add\". Sales pipelines accept user, company or deal; production pipelines accept order. For \"list\" filters, user/company/order/deal aliases are accepted."
    • changedInput schema / properties / itemable_type / enum
      Previous value: -[
      -  "user",
      -  "company",
      -  "order"
      -]New value: +[
      +  "user",
      +  "company",
      +  "order",
      +  "deal"
      +]
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

The description adds valuable side-effect context with 'Changes can trigger configured automations,' going beyond the destructiveHint annotation. It could further disclose irreversibility or external consequences, but this is already meaningful behavioral transparency.

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 dense sentences cover the main operation, per-action requirements, domain constraints, and side effects without redundancy. The key verb phrase is front-loaded, and every sentence earns its place.

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?

The description fully covers all three actions, their parameter dependencies, and entity-type restrictions, which is sufficient for a structured mutation tool with complete schema descriptions. Minor gaps like response behavior or sort_order effects are already handled by the schema or are not critical for invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description enhances this by mapping required parameters to each action and clarifying itemable_ref semantics: orders use order numbers while users, companies, and deals use IDs.

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 the tool's action: add, remove, or move pipeline cards, with distinct verbs and a specific resource. It is immediately distinguishable from the sibling pipeline-item-read tool and does not rely on the title alone.

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?

It provides action-specific required parameters and pipeline type compatibility, making usage conditions clear. It does not explicitly contrast with pipeline-item-read, but the mutation actions themselves make the intended use obvious.

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