Skip to main content
Glama

Mojeeb

by app.mojeeb.mcp
OverviewDiscussionsAdmin

Update a lead

update_lead
DestructiveIdempotent

Update a lead

Changes the fields you send. status must be the value of one of the agent's statuses, and a move the agent's status flow doesn't allow may be refused (422 invalid_request). A status change is recorded on the contact's timeline when the lead has a contact. Unlike a person's edit in the dashboard, an edit through the API never assigns an unassigned lead to anyone; assignLead does. pinned pins or unpins the lead for everyone on the agent; sending the state the lead is already in changes nothing, so a pinned lead keeps its place.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
phoneNoA valid number in E.164 (`+201001234567`), or an empty string to clear it.
pinnedNo`true` pins the lead for everyone on the agent, `false` unpins it. Sending the state the lead is already in changes nothing: a pinned lead keeps its place.
statusNoThe `value` of one of the agent's lead statuses as `listLeadFields` returns it; matched without regard to case and stored in that form.
lead_idYesA lead of the agent. Another agent's lead is `404 not_found`.
summaryNo
agent_idYesThe agent the resource belongs to. Another company's agent, or the nil UUID, is `404 agent_not_found`; an agent outside the key's agent list is `403 agent_not_authorized`.
custom_fieldsNoFree-form fields keyed by name, stored as sent (see Partial updates in the API description for how date-time strings and decimals are normalized). For a lead, use the keys of the agent's own lead fields (`listLeadFields`, `built_in: false`), and the whole object is limited to about 10,000 characters of JSON (`422 invalid_request` beyond). Mojeeb doesn't check keys or values against the fields' `type`, `options` or `required`. On update the object merges key by key, and a key sent as `null` stays with the value `null`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: invalid status transitions return 422 invalid_request, status changes are written to the contact timeline, API edits skip the dashboard's auto-assignment behavior, and re-sending the current pinned state is a no-op. These are exactly the failure modes and side effects an agent needs before calling.

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 with the verb+resource, then layered constraints in descending importance. The pinned explanation is repeated verbatim in the schema and the opening line duplicates the title, so there is minor redundancy but no wasted bulk.

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 tool with a nested custom_fields object and no output schema, the description covers the risky semantics (status moves, assignment, pinning). It leaves custom_fields key/merge behavior to the schema, which documents it thoroughly, so the agent has enough to call correctly.

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 coverage is 75% and the schema itself documents phone, pinned, status and the custom_fields merge semantics in detail. The description's notes on status values and pinned idempotency largely restate the schema rather than adding format or edge-case detail beyond it, so it lands at the baseline.

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?

States a specific verb and resource (update a lead) and immediately scopes what changes: only the fields you send. It explicitly separates itself from the sibling assign_lead by noting that API edits never assign an unassigned lead, which assignLead does.

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 conditional route to the alternative tool for assignment and explains status-move limits, so an agent knows the boundary. It does not name a read tool (e.g. get_lead) or state when not to use update_lead, so it stops short of explicit when/when-not guidance.

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

All Mojeeb toolsInspect
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