Convocore

lead_groups_write

Destructive

Create, fill, rename or delete a lead group. Group names are stored lowercase. Actions: create (groupName + leads: new lead objects, e.g. [{ userName, userPhone, userEmail }] — a group exists only while it has leads), assign_leads (groupName + leadIds: move EXISTING leads into the group; groupName "all" removes them from any group), rename (groupName + newGroupName: moves every lead to the new name), delete (groupName: by default the leads are kept and just ungrouped; deleteLeads=true permanently deletes every lead in the group).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>",
      "agentId": "<agentId>",
      "groupName": "<groupName>"
    },
    "name": "lead_groups_write"
  }
}

Input Schema

Name	Required	Description
`mode`	No	compact (default) = light mode: long text is cut and bulky blobs are replaced by a size marker. full = complete API response.
`leads`	No	For create: new leads to add to the group.
`action`	Yes
`agentId`	Yes
`leadIds`	No	For assign_leads: ids of existing leads.
`groupName`	Yes
`deleteLeads`	No	For delete. Default false (leads are kept).
`newGroupName`	No	For rename.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the destructiveHint=true annotation by stating exactly what is destroyed: deleteLeads=true permanently deletes every lead in the group, otherwise leads are merely ungrouped. It also discloses non-obvious system behavior — names are stored lowercase, a group exists only while it has leads, and groupName "all" removes leads from any group.

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 one-line purpose then organizes the rest as a compact action-to-parameters list — nearly zero waste. The semicolon-chained single block makes it slightly dense to scan, but no sentence is redundant.

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 an 8-parameter destructive mutation tool with no output schema, the description covers action semantics and destruction consequences thoroughly. It leaves the meaning of the required agentId and what a call returns undescribed, which is the only material gap.

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?

Adds real meaning over the 63%-covered schema: teaches the magic value "all", maps each parameter to its action (leads/new objects with an example shape, leadIds for existing leads, newGroupName for rename, deleteLeads for delete), and explains that delete defaults to keeping leads. agentId and mode are left to the schema, which is a minor gap.

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?

Opens with a specific verb set and resource ("Create, fill, rename or delete a lead group") and then enumerates the four actions with their required inputs. An agent can immediately distinguish this mutation tool from lead_groups_read 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?

Each action is documented with its own semantics (create needs new lead objects, assign_leads moves EXISTING leads, rename moves every lead, delete keeps leads by default), which effectively routes the agent to the right action. It does not mention sibling tools like leads_write or contact_leads, so cross-tool alternatives are left implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Convocore tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?