OrgLines

Add or update a lead contact channel

lead_upsert_channel

Destructive

Add or update one contact point of a lead — e.g. record that a phone has a Telegram account. 'lead_id', 'kind', 'value' (a number in any format, @username, a profile URL); optional 'status' (available / not_found / unknown / invalid / opted_out / unverified), 'checked_at' (default now when a status is set), 'check_method' (manual, agent_browser, messenger_check, import), 'label', 'source_url' (where you saw it), 'notes', 'is_primary' (the primary phone / e-mail is also the lead's phone / email), 'agent_name'. The same handle in another format is the SAME point (063… = +38063…) → action 'updated', never a duplicate. Checking must never message anybody. Runs on the call; making a point primary is confirmed first. At most 30 points per lead. CONFIRMATION: this tool runs immediately when the caller asks for it — it writes only their own record, and they can undo it from this same surface, so the request is taken as the instruction. You get an ordinary result, not a plan_token. Everything destructive, outbound or financial still proposes and waits.

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": {
      "lead_id": "<lead_id>",
      "kind": "<kind>",
      "value": "<value>"
    },
    "name": "lead_upsert_channel"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	Yes
`label`	No
`notes`	No
`value`	Yes
`status`	No
`lead_id`	Yes
`agent_name`	No
`checked_at`	No
`is_primary`	No
`source_url`	No
`check_method`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With destructiveHint=true already declared, the description still adds substantial context: normalization means 063… and +38063… resolve to the same point and produce 'updated' instead of a duplicate, the cap is 30 points per lead, checking must never message anybody, and the write is immediate and undoable. That last point clarifies rather than contradicts the destructive annotation, since an upsert can overwrite an existing value.

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-loaded purpose, then parameters, then the dedup/limit rules, then the confirmation model — a sensible order. The parenthetical parameter list is dense but every clause earns its place; only the long semicolon chain and the 'CONFIRMATION:' block push toward verbosity.

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

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An eleven-parameter mutation with no output schema needs confirmation semantics, limits, dedup behavior, and side-effect guarantees — all present. An agent can decide, call, and predict the result without further information.

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

Parameters5/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 full burden and does: it covers all eleven parameters, including accepted value formats for 'value', the default of 'checked_at' to now when a status is set, and the meaning of 'is_primary' (also becomes the lead's phone/email). This is meaning well beyond the bare schema.

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 and resource: "Add or update one contact point of a lead," then gives a concrete example (record that a phone has a Telegram account). The word "one" plus the sibling names lead_list_channels/lead_remove_channel make the scope distinguishable 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?

The example establishes when to reach for this tool (recording a discovered handle), and the confirmation paragraph demarcates it from tools that propose and wait — destructive, outbound, or financial actions. It does not name explicit alternatives such as lead_remove_channel for the inverse operation, so a 4 rather than a 5.

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

All OrgLines 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?