Which integrations are available for this server?

Provides tools for interacting with the Zoho Books API, enabling AI agents to perform general-ledger operations, bank-feed categorization, receipt attachment, and more on Zoho Books accounts.

How do I use zoho-books-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@zoho-books-mcp categorize the latest uncategorized bank feed line" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

zoho-books-mcp

by Operamatix

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

zoho-books-mcp

A local, safety-gated Model Context Protocol server for Zoho Books — it gives an AI agent the general-ledger writes, bank-feed categorization, and receipt attachment that Zoho's native connector doesn't expose, with hard guardrails so it can't run wild on your live books.

⚠️ This lets an AI create, update, and (optionally) delete real records in your live accounting. It ships read-only by default — every write is off until you deliberately turn it on. Read the Safety model before enabling anything, and supervise your agent.

Unofficial — not affiliated with, endorsed by, or sponsored by Zoho Corporation. "Zoho" and "Zoho Books" are trademarks of their respective owner. This is an independent community tool that talks to the public Zoho Books API using your own credentials.

Human-written note

Neither QBO nor Xero expose live bank feeds via their APIs, and by all indications never will. This is directly contradictory to their AI-native marketing posture, and functionally useless to an autonomous bookkeeping agent responsible for monitoring an email inbox for invoices and receipts, booking them against a bank feed, and maintaining the ledger. Zoho does expose this, but their native MCP and Claude connectors are equally impotent, with respect to their tool calls and permission gates; they can't create accounts, post certain transactions, or delete stuff. It seems to me, as of July 2026, that they want their connectors to do data analysis and modeling, where I want my agents to actually do my books.

You could get the same bank feed data straight from Plaid or Yodlee, but that's another subscription to pay for, another MCP to manage, and another set of credentials to care about. Yuck. This MCP expands the capabilities of the agent to basically whatever the Zoho API allows, while keeping write permissions toggled off by default and routing everything through an inference-level approval gate. It's incredibly useful, but powerful enough to be dangerous, if you're irresponsible or lazy. Use this tool intelligently.

On file uploads: Zoho, like most accounting software, lets you attach documents to transactions, like invoices or receipts. When you give your bookkeeping agent that document, it wants to convert it to base64 or binary and pipe it through the API, which blows your context window. The solution is serverside, so your agent can pass POSTs straight from your Google Drive or Dropbox or whatever; this requires OAuth and possibly GCP-esque configuration, and is not included in this repo. In other words: if you want your agent to do the document-attaching for you, you'll need to configure its access to your cloud drive yourself.

Cheers, and happy accounting. Steven

Related MCP server: SmartSuite MCP Server

Why this exists

We built this for our own AI bookkeeper, then cleaned it up to share. The short version:

Autonomous bookkeeping lives or dies on API access to the bank feed — the stream of real bank activity an agent must see in order to categorize and reconcile it. In our experience (as of 2026), Xero and QuickBooks Online don't expose that feed through their public APIs: you can push and pull transactions, but you can't reach the live bank feed itself, which leaves an agent blind to the one thing it most needs to act on.

Zoho Books does expose it — its bank feeds are Plaid-sourced and reachable via the API — which makes it the one mainstream option an agent can drive end-to-end. The catch was the tooling around it: the native connectors we tried couldn't post journals, build the chart of accounts, categorize feed lines, or attach source docs. So we wrote a thin, guarded server that does — straight against Zoho's public v3 API, no third-party SDK, no broker. Your credentials stay on your machine and leave only as ordinary HTTPS calls to Zoho.

What it's for: running behind a hosted AI-employee agent (e.g. Openclaw or Hermes), ideally on a VPS, under strict permission gates and human supervision. It ships read-only by default for exactly that reason.

A word of caution: this is genuinely useful and genuinely powerful — enough to make a real mess of real financial records if you point it at production with the gates open and walk away. Don't. Keep writes off until you trust your setup, scope the Zoho user's role tightly, and watch what your agent does. Treated with that respect it's a capable teammate; treated carelessly it's a footgun.

Shared freely by Operamatix, LLC as a contribution to the broader agentic-bookkeeping community.

Features

Verb-split passthrough — zoho_read / zoho_write / zoho_delete reach any Zoho Books v3 endpoint.
Guarded GL wrappers — manual journals (balance-enforced) and chart-of-accounts creation.
Bank-feed workflow — categorize an uncategorized feed line in place, or match it to existing transactions. (Includes the endpoints and request bodies Zoho's docs don't render — see Bank-feed categorization.)
Attachments — upload receipts / source docs to expenses, bills, and journals (by base64 or local file path).
Safety-first — every mutating action sits behind an env flag that is off by default and enforced in code.

Safety model

The guardrails are hard floors enforced in the server — not suggestions the model can talk its way past:

Control	Default	Effect
`ZOHO_ALLOW_WRITES`	`false`	All create/update refuse until set to `"true"`.
`ZOHO_ALLOW_DELETE`	`false`	All `DELETE` refuse until set to `"true"`.
Balanced journals	always on	`zoho_create_journal` refuses to post unless total debits == total credits.
Verbatim errors	always on	Zoho's error response is surfaced as-is — writes fail loud, never silently.

Recommended posture: keep ZOHO_ALLOW_WRITES=false while you learn the tool; enable writes once you trust your agent and prompts; leave ZOHO_ALLOW_DELETE=false unless you have a specific need. Zoho also enforces the role of the user your credentials belong to, on top of these flags — scope that user to the minimum the agent needs.

Requirements

Node.js ≥ 20
A Zoho Books organization and API credentials (below)

Setup

1. Get Zoho credentials (Self Client / client-credentials)

Go to the Zoho API Console → Self Client.
Generate a grant token with a Zoho Books scope (e.g. ZohoBooks.fullaccess.all, or something narrower).
Exchange the grant token for a refresh token — a standard OAuth authorization_code POST to https://accounts.zoho.com/oauth/v2/token. Keep the refresh_token.
Note your organization_id (Zoho Books → Settings, or GET /organizations).

The credentials operate as the Zoho user who created the Self Client, so create it under the account/role you want the agent to act as. (Non-US data centers: use the matching accounts.zoho.* / zohoapis.* domains — see env vars.)

2. Install

npm install

3. Configure your MCP client

Example Claude Desktop claude_desktop_config.json entry. Use an absolute node path — desktop apps launch MCP servers with a minimal PATH, so a bare node won't resolve:

"zoho-books": {
  "command": "/absolute/path/to/node",
  "args": ["/absolute/path/to/zoho-books-mcp/zoho-books-mcp.mjs"],
  "env": {
    "ZOHO_CLIENT_ID": "...",
    "ZOHO_CLIENT_SECRET": "...",
    "ZOHO_REFRESH_TOKEN": "...",
    "ZOHO_ORGANIZATION_ID": "...",
    "ZOHO_ALLOW_WRITES": "false"
  }
}

See .env.example for every variable.

Tools

Tool	Action	Gate
`zoho_read`	GET any endpoint	always on
`zoho_write`	POST/PUT any endpoint	`ZOHO_ALLOW_WRITES`
`zoho_delete`	DELETE any endpoint	`ZOHO_ALLOW_DELETE`
`zoho_create_journal`	manual journal (balance-enforced)	`ZOHO_ALLOW_WRITES`
`zoho_create_account`	chart-of-accounts account	`ZOHO_ALLOW_WRITES`
`zoho_categorize_bank_txn`	categorize an uncategorized feed line	`ZOHO_ALLOW_WRITES`
`zoho_match_bank_txn`	match a feed line to existing transactions	`ZOHO_ALLOW_WRITES`
`zoho_attach_document`	upload a receipt/doc (base64 or path)	`ZOHO_ALLOW_WRITES`

Bank-feed categorization

Zoho's Banking API docs don't fully render the request bodies for categorizing an uncategorized transaction, so here is what this server confirmed against the live API:

Route (note the singular uncategorized): POST /banktransactions/uncategorized/{transaction_id}/categorize, or .../categorize/{expenses|customerpayments|vendorpayments} for module types.

A deposit / owner contribution is a from/to model, not a flat account field:

{ "transaction_type": "deposit",
  "from_account_id": "<offset, e.g. equity>",   // credited
  "to_account_id":   "<bank account>",          // debited
  "amount": 500, "date": "2026-06-30" }

An expense (money out): use categorize_as: "expenses" with account_id (the expense account), paid_through_account_id (the bank), amount, and date.

The zoho_categorize_bank_txn wrapper handles this for you: pass offset_account_id and it maps to the correct field per type, auto-deriving amount/date/bank from the feed line.

Confirmed vs. inferred

This server was validated against a live US Zoho Books organization. Some behavior is confirmed, some inferred — treat inferred rows as "probably right, not yet verified," and remember every write can be reviewed in Zoho:

Area	Status
Auth, read, write, delete, journals, accounts, contacts, expenses	✅ confirmed
Categorize: deposit / owner_contribution (from/to model)	✅ confirmed
Categorize: expenses, vendorpayments	✅ confirmed
Attach: expense receipt (field `receipt`), journal (field `attachment`)	✅ confirmed (live round-trip)
Attach: bill (field `attachment`)	⚠️ inferred — same pattern, untested
Categorize: money-OUT directions (owner_drawings, transfer_fund, …)	⚠️ inferred — pass explicit `from_account_id` / `to_account_id`
Non-US data centers	⚠️ untested — set `ZOHO_ACCOUNTS_DOMAIN` / `ZOHO_API_DOMAIN`

Environment variables

Variable	Required	Default	Notes
`ZOHO_CLIENT_ID`	✅	—	Self Client id
`ZOHO_CLIENT_SECRET`	✅	—	Self Client secret
`ZOHO_REFRESH_TOKEN`	✅	—	long-lived refresh token
`ZOHO_ORGANIZATION_ID`	recommended	—	auto-added to every call
`ZOHO_ALLOW_WRITES`		`false`	`"true"` permits create/update
`ZOHO_ALLOW_DELETE`		`false`	`"true"` permits DELETE
`ZOHO_ACCOUNTS_DOMAIN`		`https://accounts.zoho.com`	change for non-US DC
`ZOHO_API_DOMAIN`		`https://www.zohoapis.com`	change for non-US DC

Testing

npm install
npm test

The smoke test spawns the server with dummy credentials and asserts the tool surface plus that every guard trips before any network call — so it never touches Zoho.

License

MIT. Provided as-is, without warranty — you are responsible for what your agent does to your books. Test with ZOHO_ALLOW_WRITES=false first.

Available Tools

8 tools

zoho_attach_documentA

Attach a document (receipt / source doc) to a Zoho Books record via multipart upload — e.g. an expense receipt (path '/expenses/{id}/receipt', field 'receipt'), a bill attachment (path '/bills/{id}/attachment', field 'attachment'), or a journal attachment (path '/journals/{id}/attachment', field 'attachment'). Provide the file EITHER as file_content (base64 — for docs you hold in-context / received in chat) plus file_name (filename WITH extension, e.g. 'invoice.pdf'; Zoho detects the type from it), OR as file_path (a file on the server host). Allowed types: gif, png, jpeg, jpg, bmp, pdf, xls, xlsx, doc, docx. Gated by ZOHO_ALLOW_WRITES.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Attach endpoint after /books/v3, e.g. /expenses/12345/receipt or /journals/678/attachment.
`query`	No
`file_name`	No	Filename WITH extension for the upload, e.g. 'receipt.pdf'. Required when using file_content.
`file_path`	No	Alternative to file_content: absolute path to a file on the server host.
`field_name`	No	Multipart form field name. Default 'receipt' (use 'attachment' for journals/bills).
`file_content`	No	Base64-encoded file bytes (a 'data:...;base64,' prefix is tolerated). Use this for docs you hold in-context. Requires file_name.

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses the multipart upload nature, permission gating, and file type restrictions. It does not detail side effects (e.g., success/error responses or idempotency), but for a straightforward attachment tool, this is acceptable.

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?

The description is concise but informative. It front-loads the purpose, then gives examples, then details input options. Every sentence adds value. Could be slightly more structured but overall efficient.

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

Completeness3/5

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

Given six parameters and no output schema, the description covers essential aspects: constructing the path, file input methods, and field name. It does not describe return values or error handling, which would improve completeness, but the core usage is adequately covered.

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 high (83%), so baseline is 3. The description adds meaning beyond schema: explains path construction patterns, differentiates file_content vs file_path, and notes the default field_name. This enriches parameter understanding.

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 clearly states the action: 'Attach a document to a Zoho Books record via multipart upload'. It provides specific examples (expense receipt, bill attachment, journal attachment) and references endpoint patterns, making the purpose unambiguous. It distinguishes itself from sibling tools which are generic CRUD or other operations.

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 description provides explicit guidance on when to use file_content vs file_path, lists allowed file types, and notes it's gated by ZOHO_ALLOW_WRITES (permissions context). It does not explicitly state when not to use it, but sibling tools are sufficiently different that confusion is unlikely.

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

zoho_categorize_bank_txnA

Categorize an uncategorized bank-feed line IN PLACE (clears the feed queue without creating a parallel transaction). Route: POST /banktransactions/uncategorized/{transaction_id}/categorize (generic types) or .../categorize/{categorize_as} (expenses|customerpayments|vendorpayments). CONVENIENCE: pass offset_account_id (the non-bank side) and the wrapper maps it to the right field — for a money-IN deposit type it becomes from_account_id (credited) with to_account_id = the bank (debited); for categorize_as=expenses it becomes account_id with paid_through_account_id = the bank. amount/date and the bank account are AUTO-DERIVED from the feed line when omitted (pass bank_account_id to make that list lookup reliable). VERIFIED: owner contribution -> transaction_type='deposit', offset_account_id=; bank fee -> categorize_as='expenses', offset_account_id=. NOTE: offset auto-mapping assumes money-IN; for money-OUT/other directions pass explicit from_account_id/to_account_id/account_id or a full body. Gated by ZOHO_ALLOW_WRITES; Zoho's response is returned verbatim on error.

ParametersJSON Schema

Name	Required	Description
`body`	No	Additional payload fields, merged last (highest precedence).
`date`	No	YYYY-MM-DD. Optional — auto-derived from the feed line if omitted.
`amount`	No	Optional — auto-derived from the feed line if omitted.
`account_id`	No	Explicit override.
`categorize_as`	No	Module-specific sub-endpoint.
`to_account_id`	No	Explicit override (the bank for deposits).
`transaction_id`	Yes	The uncategorized feed line id.
`bank_account_id`	No	The feed line's bank account. Optional — auto-derived from the line if omitted; passing it makes amount/date lookup reliable.
`from_account_id`	No	Explicit override (offset/source for deposits).
`transaction_type`	No	Generic type, e.g. deposit, owner_contribution, interest_income, other_income.
`offset_account_id`	No	The non-bank account (equity for a contribution, expense account for an expense). Auto-mapped to the correct field.
`paid_through_account_id`	No	Explicit override (the bank for expenses).

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: auto-derivation of amount/date, offset auto-mapping assumptions, the effect on the feed queue, and error handling (verbatim Zoho response). No contradictions exist.

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?

The description is somewhat lengthy but well-structured with clear labels (CONVENIENCE:, VERIFIED:, NOTE:). It is front-loaded with the core purpose. A slight reduction in detail could improve conciseness, but every sentence adds useful information.

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?

Given 12 parameters, no output schema, and nested objects, the description covers essential usage patterns, auto-derivation behavior, and error handling. It could be more complete by describing the success response format, but the provided context is sufficient for effective use.

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 description coverage is 100%, so baseline is 3. The description adds significant value beyond the schema by explaining inter-parameter relationships (offset auto-mapping, auto-derivation reliance on bank_account_id) and providing concrete examples. This elevates the score to 4.

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 clearly states the tool categorizes an uncategorized bank-feed line in place, using a specific verb and resource. It distinguishes from sibling tools by describing the unique operation (clearing the feed queue without creating a parallel transaction) and provides routing details.

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?

The description gives explicit guidance on when to use convenience features (passing offset_account_id) and when to avoid them (money-OUT directions). It provides verified examples for common cases (owner contribution, bank fee) and notes the gating by ZOHO_ALLOW_WRITES.

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

zoho_create_accountC

Create a GL account in the chart of accounts (guarded wrapper). Gated by ZOHO_ALLOW_WRITES.

ParametersJSON Schema

Name	Required	Description
`description`	No
`account_name`	Yes
`account_type`	Yes	e.g. income, expense, other_current_asset, bank, equity, cost_of_goods_sold, accounts_receivable, accounts_payable.
`parent_account_id`	No	Set to make this a sub-account.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. The terms 'guarded wrapper' and 'gated by ZOHO_ALLOW_WRITES' hint at safety mechanisms but do not explain side effects, permissions, or error handling. Important details are missing.

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?

The description is concise with two sentences, each providing relevant information. It is front-loaded with the purpose and includes a key condition. No redundant or extraneous content.

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

Completeness2/5

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

Given the tool has 4 parameters, no output schema, and no annotations, the description is insufficiently complete. It lacks explanation of what a GL account is, return values, error scenarios, and how the guard works. The complexity of a create operation demands more context.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (2 of 4 parameters have descriptions). The tool description does not add any meaning beyond the schema for the parameters. It fails to compensate for the undocumented 'description' and 'account_name' parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Create' and the resource 'GL account in the chart of accounts', with a note about being a guarded wrapper. It distinguishes from sibling tools like zoho_delete and zoho_read, but does not explicitly differentiate from zoho_create_journal.

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?

The description mentions 'Gated by ZOHO_ALLOW_WRITES', which implies a condition for use, but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives like zoho_create_journal. The usage context is implied rather than stated.

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

zoho_create_journalA

Create a manual journal entry (guarded wrapper). Refuses to post unless total debits == total credits. Gated by ZOHO_ALLOW_WRITES.

ParametersJSON Schema

Name	Required	Description
`notes`	No
`line_items`	Yes
`journal_date`	Yes	YYYY-MM-DD
`reference_number`	No

TDQS

A3.5/5.0

Behavior4/5

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

Despite no annotations, the description discloses key behaviors: it refuses to post unless debits equal credits, and it is gated by an environment variable. This adds value beyond the schema, though it could mention what happens on failure (e.g., error message).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences conveying the core purpose and constraint without extraneous information. Each sentence earns its place.

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

Completeness2/5

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

No output schema exists, so the description should address return values or error handling. It omits what happens on success (e.g., object ID) or on failure (e.g., validation errors). The guarded nature warrants more context.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 25% description coverage (only journal_date has a format hint). The description does not elaborate on parameters, except implicitly requiring line_items to satisfy the debit-credit balance. For a 4-parameter tool, this provides insufficient guidance.

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 clearly states the action ('Create'), the resource ('manual journal entry'), and distinguishes from siblings by noting it's a 'guarded wrapper' that requires debits to equal credits. This differentiates it from other Zoho tools.

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

Usage Guidelines2/5

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

The description mentions gating via 'ZOHO_ALLOW_WRITES' but does not provide explicit when-to-use or when-not-to-use guidance compared to sibling tools like 'zoho_create_account'. The use case is implied but not clearly delineated.

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

zoho_deleteB

Delete a Zoho Books resource (DELETE), e.g. /invoices/123. Disabled unless ZOHO_ALLOW_DELETE=true.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`query`	No

TDQS

B3.1/5.0

Behavior3/5

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

Discloses that it performs a DELETE HTTP request and that it is disabled unless an environment variable is set. However, no details about success/failure behavior or idempotency are provided, and there are no annotations to supplement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the purpose. No wasted words.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description omits important context such as the purpose of the query parameter, expected response, and error handling. It is too brief for a delete operation with an object parameter.

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

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no semantic meaning to the parameters. It only gives an example path but does not explain the path format or the query object parameter.

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 clearly states the verb 'Delete' and the resource 'Zoho Books resource', with an example path. It distinguishes from siblings as the only delete tool among the listed siblings.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The condition 'Disabled unless ZOHO_ALLOW_DELETE=true' is a prerequisite but not comparative usage advice.

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

zoho_match_bank_txnA

Match an uncategorized bank-feed line to one or more EXISTING transactions (invoices/bills/payments) rather than creating a new one. Confirmed route: POST /banktransactions/uncategorized/{transaction_id}/match. Provide transactions_to_be_matched as an array of { transaction_id, transaction_type }. Gated by ZOHO_ALLOW_WRITES; Zoho's response is returned verbatim on error.

ParametersJSON Schema

Name	Required	Description
`body`	No	Optional override/extra fields for the match payload.
`transaction_id`	Yes	The uncategorized feed line id.
`transactions_to_be_matched`	Yes	Existing transactions to match against, e.g. [{ transaction_id, transaction_type: 'invoices' }].

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the write operation, error response verbatim, and gating condition. However, it lacks details on success response or side effects, leaving some behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficient: two sentences that state purpose, contrast, route, and parameter format. No fluff, front-loaded with key information.

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

Completeness3/5

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

The tool has three parameters, nested objects, and no output schema. The description covers the core action and required parameters but omits the optional 'body' parameter and success behavior. Given the complexity, it is fairly complete but has notable gaps.

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 100%, so baseline is 3. The description adds context beyond the schema by explaining the array format and the write gating. It also clarifies the purpose of the parameters, adding moderate value.

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 clearly states the tool's purpose: matching an uncategorized bank-feed line to existing transactions, contrasting with creating a new one. It uses specific verbs and resources, and distinguishes from sibling tools like zoho_categorize_bank_txn.

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 description explicitly states when to use (match existing transactions) and provides the API route and required array format. It mentions the gating by ZOHO_ALLOW_WRITES, offering good context, but does not explicitly list when not to use or alternatives.

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

zoho_readA

Read any Zoho Books endpoint (GET). path is everything after /books/v3, e.g. '/invoices', '/journals/123', '/chartofaccounts', '/contacts'. organization_id is added automatically. Read-only and always available.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	e.g. /invoices or /contacts/456
`query`	No	Optional query params, e.g. { page: 1, per_page: 200, filter_by: 'Status.Sent' }

TDQS

A4.3/5.0

Behavior4/5

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

Declares 'Read-only and always available', which is key behavioral info. No annotations exist, so description carries full burden; missing details on errors or rate limits but acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff, front-loaded with action and usage. Every sentence earns its place.

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

Completeness3/5

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

No output schema, but description doesn't mention return format or pagination. For a generic read tool, this is adequate but could be more complete.

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?

Adds meaningful context beyond schema: path is everything after /books/v3, query is optional with example. Schema coverage is 100%, but description enhances understanding.

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?

Description clearly states it reads any Zoho Books endpoint via GET, provides examples of path usage, and distinguishes from sibling tools that are write/delete/match operations.

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?

Explanation of path format and automatic organization_id addition gives clear usage context. Could explicitly state not to use for write operations, but siblings imply that.

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

zoho_writeA

Create or update any Zoho Books resource (POST or PUT). e.g. POST /invoices, PUT /items/123. Gated by ZOHO_ALLOW_WRITES.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	JSON payload for the resource.
`path`	Yes	e.g. /invoices or /expenses/789
`query`	No
`method`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states the HTTP methods and gating, omitting authentication details, rate limits, side effects, or idempotency of operations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, highly concise, with the main action front-loaded. Every word serves a purpose.

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

Completeness2/5

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

For a generic write tool with 4 parameters and no output schema, the description lacks details on return values, error handling, or resource-specific behaviors, leaving significant gaps.

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 50%; description adds examples (e.g., '/invoices', '/items/123') but does not explain the query parameter or body structure beyond what schema provides.

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?

Description clearly states the tool creates or updates any Zoho Books resource via POST or PUT, which distinguishes it from sibling tools that target specific resources.

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?

Indicates gating by ZOHO_ALLOW_WRITES environment variable, providing a prerequisite. Does not explicitly state when not to use or list alternatives, but sibling tools imply specialized use cases.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.0Jul 9, 2026
- First observedzoho_attach_document
- First observedzoho_categorize_bank_txn
- First observedzoho_create_account
- First observedzoho_create_journal
- First observedzoho_delete
- First observedzoho_match_bank_txn
- First observedzoho_read
- First observedzoho_write

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Scored 2026-07-09 09:00 across 8 tools

Disambiguation5/5

Each tool has a unique purpose: document attachment, bank transaction categorization/ matching, account creation, journal entry creation, resource deletion, generic read, and generic write. No two tools overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with lowercase snake_case (e.g., attach_document, create_account). The prefix 'zoho_' unifies them, and verbs like read/write are single-word but fit the pattern.

Tool Count5/5

8 tools is well-scoped for an accounting server: it provides both generic CRUD (read/write/delete) and specialized operations (categorize/match bank transactions, attach documents, create accounts/journals).

Completeness4/5

The generic read/write tools cover most CRUD operations, and specific tools handle key accounting workflows. Missing explicit tools for invoices or contacts, but those can be accessed via the generic endpoints. Minor gap.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Unified.to MCP Server C
to.unified.docs
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
App Automation Agent Orchestration Developer Tools
252
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
IdentArk Gateway
io.identark
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Security Agent Orchestration
29
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24

Related MCP Servers

safedb-mcp
Databases Security
narekmalk
A
license
A
quality
C
maintenance
Secure MCP server for safe, read-only DB access by AI agents, with SQL guardrails, table allowlists, PII masking, and audit logs
Updated 3 months ago (2026-05-27 10:23 UTC)
6
29
7
MIT
SmartSuite MCP Server
CRM Databases Project Management
SmartSuiteFoundry
A
license
A
quality
C
maintenance
A locally-hosted MCP server enabling AI agents to securely interact with SmartSuite data, with configurable access modes and audit logging.
Updated 3 days ago (2026-09-08 13:10 UTC)
85
10
MIT
zoho-bookkeeper-mcp
Finance ERP Systems
bu5hm4nn
A
license
A
quality
D
maintenance
MCP server for Zoho Books integration, enabling AI agents to perform bookkeeping operations like managing journals, expenses, bills, invoices, and file attachments.
Updated 4 months ago (2026-05-05 15:23 UTC)
49
1
MIT
ToolBridge
CRM Customer Support
AlexlaGuardia
F
license
Not graded
quality
D
maintenance
A governed MCP server for integrating AI agents with customer data, featuring role-based access control, field redaction, and human-in-the-loop approval for secure support operations.
Updated 3 months ago (2026-06-12 16:41 UTC)
1
-