Skip to main content
Glama
Moe03

Convocore MCP Server

by Moe03
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

zoho_crm_records_write

Destructive

Create, update, upsert, or delete up to 100 Zoho CRM records per call and attach notes, returning per-record success or error details for partial failures.

Instructions

Create, update, upsert or delete records in the connected Zoho CRM (leads, contacts, deals, accounts, custom modules), up to 100 per call, and add notes. Records use Zoho field API names, e.g. { "Last_Name": "Smith", "Email": "a@b.com", "Lead_Status": "New" }; picklist values must match exactly (integrations_read zoho_fields). The result has one entry per record (success, id, or the Zoho error code and field), so partial failures are visible. delete moves records to the Zoho recycle bin; confirm with the user before deleting or bulk-updating. Actions: create — create records Needs: records. | update — update records by id (only the fields given change) Needs: records. | upsert — insert or update by duplicateCheckFields; each result says insert or update Needs: records. | delete — delete records (confirm first) Needs: recordIds. | add_note — attach a note to a record Needs: recordId, title, content.

Input Schema

NameRequiredDescriptionDefault
modeNocompact (default) = light mode: long text is cut and bulky blobs are replaced by a size marker. full = complete API response.
orgIdNoOptional organization scope.
titleNoFor add_note.
actionYes
contentNoFor add_note.
recordsNoFor create / update / upsert: up to 100 records. update needs "id" on each record.
recordIdNoFor add_note: the record to attach the note to.
recordIdsNoFor delete: up to 100 record ids.
connectionIdNoZoho connection id. Optional when the workspace has only one Zoho account.
moduleApiNameYesZoho module API name: Leads, Contacts, Accounts, Deals, or a custom module (see integrations_read zoho_modules).
triggerWorkflowNoRun the Zoho workflow rules on this change (default true).
duplicateCheckFieldsNoFor upsert: fields that identify an existing record, e.g. ["Email"]. Default: the module's own duplicate check.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.6.17

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say destructive and non-idempotent; the description adds what actually matters: the 100-record cap, recycle-bin semantics for delete, that update changes only supplied fields, that upsert reports insert vs update per record, and that partial failures surface as per-record errors. That is real operational context an agent cannot get from the annotations.

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 verbs, resource, batch cap and the field-name convention before the per-action breakdown, and every clause carries information. It is fairly long and the trailing 'Needs:' list partly restates what the schema already marks as required, which is the only slack.

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 12-parameter multi-action mutation tool with no output schema, the description covers return shape (one entry per record with success/id/error code), batch limits, and destructive-action caution. Gaps are minor — nothing about the mode parameter's effect on returned text or about what connectionId/orgId scoping means operationally.

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 coverage is 92%, so the baseline is 3; the description earns more by supplying the calling convention the schema lacks — Zoho field API names, an example record shape, exact-match picklist requirement, and the semantics of duplicateCheckFields. It leaves mode, connectionId, triggerWorkflow and orgId entirely to the 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?

Uses a specific set of verbs (create/update/upsert/delete/add note) against a named resource (Zoho CRM records across leads, contacts, deals, accounts, custom modules). The write scope is unmistakable and cleanly contrasts with the sibling zoho_crm_records_read.

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 per-action block states exactly which inputs each action needs (records vs recordIds vs recordId/title/content), and it calls out prerequisites like confirming with the user before delete or bulk update and consulting integrations_read zoho_fields for picklist values. It stops short of naming the read sibling as the alternative for retrieval, so routing is implied rather than spelled out.

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

Deploy Server

Other Tools