Skip to main content
Glama
Sign In

Mojeeb

by app.mojeeb.mcp
OverviewDiscussionsAdmin

Add a lead field

create_lead_field

Add a lead field

Adds a custom field to the agent's lead form, after its other custom fields, shown in the dashboard's table and form. The built-in status, assigned_to, notes and created_at come last on an agent whose fields were never reordered, so the new field goes before them. The AI's lead capture starts collecting it in the background, usually within a minute: the label tells the AI what to ask for, and required makes it treat the field as needed before it saves a lead. A reserved key is 422 invalid_request (see key); any other key the agent already has, built-in fields included, is 409 field_key_taken; an agent that already has 50 custom fields is 422 lead_field_limit_reached.

Input Schema

NameRequiredDescriptionDefault
keyYesThe field's key in a lead's `custom_fields`: lowercase letters, digits and underscores, starting with a letter. It can't change later. A reserved key is `422 invalid_request`: the lead properties `id`, `agent_id`, `status`, `created_at`, `updated_at`, `conversation_id`, `name`, `email`, `phone` and `summary`, and the keys Mojeeb fills itself, `source`, `captured_at` and `user_message`; any other key the agent already has, built-in fields included, is `409 field_key_taken`.
typeYesThe input type, written in lowercase. An `enum` field takes its choices in `options`.
labelYesWhat your team sees, and what tells the AI what to ask for. Can't contain angle brackets.
optionsNoThe choices of an `enum` field, in the order they are shown, each `value` distinct. Required for `enum` and refused with any other type.
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`.
requiredNoWhether the AI treats the field as needed before it saves a lead. False when left out.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly=false, destructive=false, and idempotent=false, so the safety profile is covered. The description adds genuinely new behavioral context: that the field is inserted before built-in fields, that AI lead capture begins within roughly a minute, and that 50 custom fields triggers 422 lead_field_limit_reached. Some error content duplicates the `key` schema description, which caps this below 5.

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?

Purpose and ordering are front-loaded, and each sentence carries information. There is mild redundancy where the reserved-key and 409 error codes are restated already present in the `key` parameter description, which keeps it short of a 5.

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 create tool with no output schema and fully covered input schema, the description covers placement, background collection, and failure modes. The main omission is what the call returns, though with no output schema this is a minor gap.

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%, so the baseline is 3. The description restates semantics for `label` and `required` (what tells the AI to ask, treating the field as needed) but adds little that the schema does not already document.

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?

The description states a specific verb+resource ('Adds a custom field to the agent's lead form') and specifies where the field lands relative to existing fields. It is clearly distinguishable from create_lead, update_lead_field, and delete_lead_field siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the ordering and side-effect explanation, but the description never names alternatives or states when to use this versus update_lead_field or list_lead_fields. No explicit when/when-not guidance is given.

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