Skip to main content
Glama
Moe03

Convocore MCP Server

by Moe03
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

zoho_crm_records_read

Read-onlyIdempotent

Browse, search, query, and fetch Zoho CRM records—leads, contacts, deals, accounts, or custom modules—to retrieve the exact data you need.

Instructions

Browse and search records in the connected Zoho CRM: leads, contacts, deals, accounts or any custom module. list pages through a module (perPage up to 200; pass info.nextPageToken as pageToken past 2000 records). search uses Zoho criteria, e.g. "(Lead_Status:equals:New)" or "((Lead_Source:equals:Chat)and(Created_Time:greater_than:2026-10-01T00:00:00+00:00))"; operators: equals, not_equal, starts_with, in, greater_than, less_than, between. query runs COQL for anything else, e.g. "select Last_Name, Email, Lead_Status from Leads where Lead_Status = 'New' order by Created_Time desc limit 200" (a where clause is required; limit max 2000, use "limit 200, 200" to page). Use integrations_read zoho_fields for the field API names and picklist values. Actions: list — one page of records of a module, newest first if sortBy=Created_Time sortOrder=desc Needs: moduleApiName. | search — records matching criteria / word / email / phone Needs: moduleApiName. | query — COQL SELECT for filters, sorting and counts search cannot do Needs: query. | get — one full record Needs: moduleApiName, recordId.

Input Schema

NameRequiredDescriptionDefault
cvidNoFor list: id of a Zoho custom view to list from.
modeNocompact (default) = light mode: long text is cut and bulky blobs are replaced by a size marker. full = complete API response.
pageNoFor list / search: page number (default 1).
wordNoFor search: free-text search.
emailNoFor search: exact email.
orgIdNoOptional organization scope.
phoneNoFor search: phone number.
queryNoFor query: a COQL SELECT statement.
actionYes
fieldsNoField API names to return (max 50). Default for list: up to 50 standard then custom fields.
sortByNoFor list.
perPageNoFor list / search: records per page, max 200 (default 50).
criteriaNoFor search: Zoho criteria expression.
recordIdNoFor get: the Zoho record id.
pageTokenNoFor list: info.nextPageToken from the previous page (needed past 2000 records).
sortOrderNoFor list.
connectionIdNoZoho connection id. Optional when the workspace has only one Zoho account.
moduleApiNameNoZoho module API name: Leads, Contacts, Accounts, Deals, or a custom module (see integrations_read zoho_modules).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.6.17

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds operational behavior beyond that: perPage cap of 200, the 2000-record pageToken boundary, COQL limit max 2000 with 'limit 200, 200' paging, and the requirement that a where clause is mandatory. Return-shape behavior is only partly covered (the mode parameter carries that), which keeps it just below a 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?

Front-loaded with purpose and paging rules, and the pipe-separated action summary is skimmable. The criteria/COQL examples are dense and make the sentence long, but every clause (operators, limit cap, field lookup pointer) carries actionable information, so nothing is truly wasted.

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?

Against 18 parameters, no output schema, and a multi-action surface, the description covers action selection, required params per action, pagination, query syntax, and field discovery. An agent can invoke any of the four actions without further documentation.

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 coverage is already 94%, yet the description still adds syntax and defaults the schema does not: Zoho criteria grammar with two concrete examples, the full operator list, a COQL example, and the default/limit semantics for perPage and fields. This meaningfully exceeds the baseline-3 expectation for high-coverage schemas.

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 (browse/search/read) and resource (Zoho CRM records across leads, contacts, deals, accounts, custom modules), then enumerates all four actions with their required parameters. Sibling zoho_crm_records_write is implicitly distinguished by the read-only scope and the annotations confirm it.

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

Usage Guidelines5/5

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

Explicitly routes between actions: list for paging, search for criteria/word/email/phone, query for 'anything else search cannot do' such as sorting and counts, get for a single full record. It also redirects field-name lookup to integrations_read zoho_fields, which is exactly the cross-tool guidance an agent needs.

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