Skip to main content
Glama

save_intent_leads_to_list

Idempotent

Save unlocked Intent people to a prospect list (existing list_id or a new list_name). Their personalised lines go with them. Free; locked people are skipped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
list_idNo
lead_idsYes
list_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive, idempotent, closed-world write. The description adds genuinely non-structured facts: the operation is free, locked people are silently skipped, and personalised lines are carried along with the saved leads. It does not explain what happens on a name collision with an existing list.

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?

Three tight sentences with the action and both targeting options front-loaded. 'Their personalised lines go with them' is slightly conversational but conveys a real side effect, so little is wasted.

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?

For a 3-param write tool with no output schema and 0% schema coverage, the description covers the core behaviors an agent needs (unlocked-only, free, carries personalised lines, two list-targeting modes). Missing only edge-case behavior such as duplicate/idempotent handling and name-conflict resolution.

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 description coverage is 0%, so the description carries the burden and does explain the two list parameters (list_id = existing list, list_name = new list). lead_ids is left to the schema, and required/optional status is not stated, but the meaning of the ambiguous params is supplied.

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?

Specific verb+resource: saves unlocked Intent people to a prospect list, with the two targeting modes (existing list_id vs new list_name) named inline. It is distinguishable from write-adjacent siblings like unlock_intent_leads or list_intent_leads, though it never names an alternative tool directly.

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?

Gives a clear precondition (only unlocked people are saved; locked ones are skipped) and implicitly routes the caller between supplying list_id for an existing list or list_name for a new one. No explicit when-not-to-use or named alternative is offered, which keeps it short of a 5.

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.