Skip to main content
Glama

SalesBlink Cold Email

Move Lead

move_lead
Destructive

Move Lead to Another List - Move a lead from one list to another

Input Schema

NameRequiredDescriptionDefault
idYesThe lead ID to move
list_idYesDestination list ID
workspace_idNoWorkspace ID this action applies to. When omitted, the current or default workspace is used.

Output Schema

NameRequiredDescriptionDefault
resultNoThe raw result returned by the SalesBlink tool.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.8/5.0
Behavior2/5

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

The annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description repeats the mutation ('move') without adding anything the annotations lack — no note on whether the lead is removed from the source list, whether membership data/suppression state is preserved, or whether cross-workspace moves behave differently.

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

Conciseness3/5

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

It is short and front-loaded, but the two halves are the same statement restated ('Move Lead to Another List' / 'Move a lead from one list to another'). Minimal, but the second clause earns nothing.

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

Completeness2/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 needn't be explained, but this is a destructive list-membership operation with no annotation-supplementing context: no error behavior, no side effects on sequences or suppression status, no cross-workspace caveat. The description is not complete enough for an agent to predict outcomes.

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?

Schema description coverage is 100% and all three parameters (id, list_id, workspace_id) are documented in-schema with default-workspace semantics. The description adds nothing beyond the schema, so baseline 3 applies.

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 (move) and resource (lead) plus the scope change (from one list to another), which distinguishes it from update_lead. It does not explicitly name that sibling as an alternative, but the action is unambiguous.

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?

No guidance on when to use this versus update_lead, what preconditions apply (e.g., whether the lead must already exist in a source list), or what happens if the lead is already in the destination. The agent must infer everything from the name.

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.