Which integrations are available for this server?

Provides tools for managing Zoho Projects, including listing projects and tasks, creating and updating tasks, adding comments, managing users, starting/stopping timers, and listing custom fields.

How do I use zoho-projects-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-projects-mcp List all projects" 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-projects-mcp

by falegria86

Overview Schema Related Servers Score Discussions

JavaScript

Local

zoho-projects-mcp

Servidor MCP (Model Context Protocol) que conecta Zoho Projects con Claude AI. Permite gestionar proyectos y tareas, registrar tiempo, manejar comentarios y sincronizar horas directamente desde conversaciones con Claude.

Requisitos

Node.js 18+
Cuenta de Zoho Projects con acceso a la API
Claude Desktop (u otro cliente MCP compatible)

Related MCP server: Zoho Projects MCP Server

Instalación

git clone https://github.com/tu-org/zoho-projects-mcp.git
cd zoho-projects-mcp
npm install

Configuración

1. Variables de entorno

Crea un archivo .env en la raíz del proyecto:

ZOHO_CLIENT_ID=tu_client_id
ZOHO_CLIENT_SECRET=tu_client_secret
ZOHO_PORTAL_NAME=nombre_de_tu_portal
ZOHO_MY_USER_ID=tu_id_de_usuario_numerico
ZOHO_MY_NAME=Tu Nombre Completo
ZOHO_TEAM_EMAILS=usuario1@empresa.com,usuario2@empresa.com
ZOHO_TEAM_NAMES=nombre1,apellido1,nombre2,apellido2
ZOHO_AUTO_TIMER_PROJECT_ID=id_numerico_del_proyecto
ZOHO_AUTO_TIMER_TASK_ID=id_numerico_de_la_tarea
ZOHO_REFRESH_TOKEN=tu_refresh_token

ZOHO_PORTAL_NAME — nombre del portal en la URL de Zoho Projects (ej: sigobproyectos)
ZOHO_MY_USER_ID — ID numérico del usuario que se asigna por defecto al crear tareas; obténlo con list_users en cualquier proyecto
ZOHO_MY_NAME — nombre completo del usuario (opcional); amplía la detección de menciones por nombre en my-mentions
ZOHO_TEAM_EMAILS — lista separada por comas de emails del equipo para team-tasks
ZOHO_TEAM_NAMES — fragmentos de nombre separados por comas para detectar miembros del equipo por nombre (ej: "jose ramon,tejeda,kevin")
ZOHO_AUTO_TIMER_PROJECT_ID — ID numérico del proyecto para el timer automático (ver sección Railway)
ZOHO_AUTO_TIMER_TASK_ID — ID numérico de la tarea en la que se inicia/detiene el timer automático
ZOHO_REFRESH_TOKEN — refresh token OAuth; solo necesario en entornos sin tokens.json (Railway, CI)

Para crear las credenciales OAuth, registra una aplicación en la Consola de Desarrolladores de Zoho con URI de redirección http://localhost:8080/callback.

2. Autenticación OAuth2

Ejecuta el flujo de autenticación una sola vez. Abrirá el navegador para autorizar la app y guardará los tokens en tokens.json:

npm run setup

Los tokens se renuevan automáticamente; no es necesario repetir este paso.

3. Integrar con Claude Desktop

Agrega el servidor al archivo de configuración de Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "zoho-projects": {
      "command": "node",
      "args": ["/ruta/absoluta/al/proyecto/src/server.js"]
    }
  }
}

Uso

Iniciar el servidor manualmente

npm start

Scripts de utilidad

Tareas abiertas del equipo

Muestra las tareas abiertas asignadas a los miembros del equipo en todos los proyectos. Requiere ZOHO_TEAM_EMAILS y/o ZOHO_TEAM_NAMES en .env:

npm run team-tasks

Menciones en comentarios

Busca todos los comentarios donde te mencionan ([~ZOHO_MY_USER_ID]) en uno o todos los proyectos. Soporta filtro por rango de fechas:

npm run my-mentions                                        # todos los proyectos
npm run my-mentions -- "nombre-proyecto"                  # un proyecto específico
npm run my-mentions -- --from=2026-05-01 --to=2026-06-09 # con rango de fechas
npm run my-mentions -- "nombre-proyecto" --from=2026-06-01

Herramientas MCP disponibles

Proyectos y tareas

Herramienta	Descripción	Parámetros requeridos
`list_projects`	Lista todos los proyectos del portal	—
`list_tasks`	Lista todas las tareas de un proyecto (paginación automática)	`project_id`
`get_task`	Detalle completo de una tarea	`project_id`, `task_id`
`create_task`	Crea una nueva tarea	`project_id`, `name`
`create_subtask`	Crea una subtarea bajo una tarea padre	`project_id`, `parent_task_id`, `name`
`update_task`	Actualiza estado, prioridad, responsable, fechas, etc.	`project_id`, `task_id`
`delete_task`	Elimina una tarea permanentemente (irreversible)	`project_id`, `task_id`
`list_users`	Lista los usuarios de un proyecto con su zpuid	`project_id`
`list_task_fields`	Lista los campos personalizados disponibles	`project_id`

Comentarios

Herramienta	Descripción	Parámetros requeridos
`list_comments`	Lista todos los comentarios de una tarea	`project_id`, `task_id`
`add_comment`	Agrega un comentario a una tarea	`project_id`, `task_id`, `content`
`update_comment`	Edita un comentario existente	`project_id`, `task_id`, `comment_id`, `content`
`delete_comment`	Elimina un comentario (irreversible)	`project_id`, `task_id`, `comment_id`

Archivos adjuntos

Herramienta	Descripción	Parámetros requeridos
`get_task_attachments`	Lista los archivos adjuntos de una tarea con URLs de descarga	`project_id`, `task_id`
`disassociate_attachment`	Desvincula un adjunto de una tarea (no lo elimina de WorkDrive)	`project_id`, `task_id`, `attachment_id`

Tiempo

Herramienta	Descripción	Parámetros requeridos
`start_timer`	Inicia el timer de tiempo en una tarea	`project_id`, `task_id`
`stop_timer`	Detiene el timer activo	`project_id`, `task_id`
`get_time_logs`	Lista los registros de tiempo de un proyecto por rango de fechas	`project_id`
`add_time_log`	Registra horas manualmente en una tarea	`project_id`, `task_id`, `hours`, `date`
`sync_task_hours`	Para cada tarea cerrada con horas planeadas, crea un time log igual a `total_work × factor`	`project_id`

Notas sobre `create_task`

project_id acepta nombre o ID numérico: "sigob-sir-lite" o "123456789"
Si no se especifica person_responsible, se asigna automáticamente ZOHO_MY_USER_ID
priority debe ir en minúsculas: "high", "medium", "low", "none"
start_date y due_date usan formato MM-DD-YYYY (se convierten a ISO internamente)
Para campos personalizados usa list_task_fields para obtener los api_name y pásalos en custom_fields:
```
{ "cf_area_tecnica": "Backend" }
```

Notas sobre `update_task`

Solo se envían los campos que se pasen; los demás quedan intactos.
Para cambiar el estado necesitas el ID numérico del estado (no el nombre). Patrón: busca con list_tasks una tarea que ya tenga ese estado → llama a get_task → lee el ID en el campo Estado.
Para mover la tarea a otra lista usa el parámetro tasklist_id.

Notas sobre `get_time_logs`

Itera sobre las tareas del proyecto consultando los logs de cada una individualmente (limitación de la API de Zoho).
Si se pasa user_zpuid, solo consulta las tareas asignadas a ese usuario.
Si no se pasan fechas, devuelve el mes actual.

Notas sobre `sync_task_hours`

Opera sobre tareas cerradas con owners_and_work.total_work > 0.
factor (0.0–2.0, por defecto 1.0): multiplica las horas planeadas antes de crear el log. Ej: 0.95 registra el 95% de las horas planeadas.
La fecha del log usa end_date de la tarea; si no tiene, usa la fecha de hoy.
No reemplaza logs existentes — crea un entry adicional.
Procesa en lotes de 3 con pausa entre ellos para respetar el rate limit de Zoho.

Formato HTML de descripciones

El campo description en create_task y update_task se convierte automáticamente a HTML antes de enviarse a Zoho.

Si el texto ya contiene HTML, se envía tal cual.
Si es texto plano, se aplica la siguiente conversión:

Entrada	HTML generado
Línea en MAYÚSCULAS (ej: `SITUACIÓN ACTUAL`)	`<h3>SITUACIÓN ACTUAL</h3><br><br>`
Línea con `-`, `*` o `•` al inicio	Agrupada en `<ul><li>...</li></ul>`
Cualquier otro texto	`<p>texto</p>`

Timer automático (cron)

El script scripts/auto-timer.js inicia o detiene el timer de una tarea de Zoho automáticamente. La tarea objetivo se configura vía variables de entorno — cada usuario apunta a su propia tarea sin tocar el código.

npm run timer:start   # inicia el timer
npm run timer:stop    # detiene el timer

Paso 1 — obtener los IDs de tu tarea

Abre la tarea en Zoho Projects y copia los IDs del URL:

https://projects.zoho.com/portal/miportal#zp/projects/106599000032339072/tasks/.../106599000033129351
                                                                ↑ project_id                ↑ task_id

Paso 2 — obtener el refresh token

Corre el flujo de autenticación local una vez (npm run setup) y luego copia el valor de refresh_token de tu tokens.json:

cat tokens.json | python3 -c "import sys,json; print(json.load(sys.stdin)['refresh_token'])"

Paso 3 — elegir dónde desplegar

Opción A — Railway (recomendado, sin servidor propio)

Railway ejecuta cron services como contenedores que corren el comando y terminan. Se necesitan dos servicios dentro del mismo proyecto Railway.

Variables de entorno (configurar en cada servicio):

ZOHO_CLIENT_ID=tu_client_id
ZOHO_CLIENT_SECRET=tu_client_secret
ZOHO_PORTAL_NAME=tu_portal
ZOHO_REFRESH_TOKEN=tu_refresh_token
ZOHO_AUTO_TIMER_PROJECT_ID=id_numerico_del_proyecto
ZOHO_AUTO_TIMER_TASK_ID=id_numerico_de_la_tarea
TZ=America/Mexico_City

Servicio 1 — iniciar timer

Campo	Valor
Tipo	Cron Job
Comando	`node scripts/auto-timer.js start`
Schedule (UTC)	`0 13 * * 1-5` (8am CDMX, verano UTC-5)

Servicio 2 — detener timer

Campo	Valor
Tipo	Cron Job
Comando	`node scripts/auto-timer.js stop`
Schedule (UTC)	`0 22 * * 1-5` (5pm CDMX, verano UTC-5)

Timezone: Railway siempre interpreta el schedule en UTC. Ajusta la hora según tu zona:
Zona
UTC offset
8am en UTC
5pm en UTC
CDMX verano (CDT)
UTC-5
0 13 * * 1-5
0 22 * * 1-5
CDMX invierno (CST)
UTC-6
0 14 * * 1-5
0 23 * * 1-5
Colombia / Perú
UTC-5
0 13 * * 1-5
0 22 * * 1-5
Argentina
UTC-3
0 11 * * 1-5
0 20 * * 1-5
España (verano)
UTC+2
0 6 * * 1-5
0 15 * * 1-5

Para verificar que funciona, usa el botón "Run Now" en cada servicio y revisa los logs. Deberías ver Timer iniciado o Timer detenido.

Opción B — VPS / servidor Linux (Ubuntu, Debian, etc.)

No necesitas tokens.json si defines ZOHO_REFRESH_TOKEN en el entorno. Clona el repo, instala dependencias y registra los crons:

git clone https://github.com/tu-org/zoho-projects-mcp.git /opt/zoho-mcp
cd /opt/zoho-mcp
npm install
cp .env.example .env   # edita con tus valores, incluyendo ZOHO_AUTO_TIMER_* y ZOHO_REFRESH_TOKEN

Edita el crontab:

crontab -e

Agrega las dos líneas (ajusta la hora a tu zona horaria del servidor):

0 8 * * 1-5 cd /opt/zoho-mcp && node scripts/auto-timer.js start >> /var/log/zoho-timer.log 2>&1
0 17 * * 1-5 cd /opt/zoho-mcp && node scripts/auto-timer.js stop >> /var/log/zoho-timer.log 2>&1

Si el servidor corre en UTC, convierte las horas igual que en Railway. Verifica la zona del servidor con timedatectl y cámbiala si quieres usar hora local: sudo timedatectl set-timezone America/Mexico_City.

Opción C — Mac o Linux local (la máquina debe estar encendida a esas horas)

Requiere tokens.json generado por npm run setup. Registra los crons con crontab -e:

0 8 * * 1-5 cd /ruta/al/proyecto && node scripts/auto-timer.js start >> /tmp/zoho-timer.log 2>&1
0 17 * * 1-5 cd /ruta/al/proyecto && node scripts/auto-timer.js stop >> /tmp/zoho-timer.log 2>&1

En Mac, si la máquina duerme exactamente a esa hora el cron puede no dispararse. Una alternativa más robusta en Mac es usar launchd en lugar de crontab.

Solución de problemas

Síntoma	Posible causa
`ZOHO_AUTO_TIMER_PROJECT_ID y ZOHO_AUTO_TIMER_TASK_ID son requeridos`	Faltan esas variables de entorno
`No hay timer activo` al hacer stop	El timer no se inició antes (revisa logs del servicio start)
`Error 401`	El refresh token expiró — corre `npm run setup` localmente y actualiza `ZOHO_REFRESH_TOKEN`
Timer descartado (< 30 segundos)	Normal si se prueba con "Run Now" dos veces seguidas muy rápido

Arquitectura

src/
├── server.js        # Punto de entrada MCP — registra las 20 herramientas con esquemas Zod
├── zoho-client.js   # Cliente HTTP singleton — refresco automático de tokens en 401
└── setup-auth.js    # Flujo OAuth2 de una sola vez

scripts/
├── auto-timer.js    # Cron — inicia/detiene timer automáticamente (Railway, VPS o local)
├── my-open-tasks.js # Utilidad CLI — tareas abiertas del equipo en todos los proyectos
└── my-mentions.js   # Utilidad CLI — comentarios que te mencionan, con filtro de fechas

El cliente HTTP (zoho-client.js) intercepta respuestas 401, renueva el access token usando el refresh token y reintenta la solicitud original de forma transparente. Para endpoints que requieren application/x-www-form-urlencoded (como addbulktimelogs) expone postForm() en lugar del post() estándar que envía JSON.

Archivos sensibles

Los siguientes archivos contienen credenciales y están excluidos del repositorio (.gitignore):

.env — variables de entorno con credenciales OAuth
tokens.json — tokens de acceso activos generados por npm run setup

Available Tools

11 tools

add_commentC

Agrega un comentario a una tarea

ParametersJSON Schema

Name	Required	Description
`project_id`	Yes	ID del proyecto
`task_id`	Yes	ID de la tarea
`content`	Yes	Texto del comentario

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description is the sole source of behavioral info. It only states the action, omitting side effects, permissions, or idempotency.

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?

Single sentence, no redundancy. However, it is minimally concise and could include more context without losing efficiency.

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?

For a simple tool with all required params and no output schema, the description covers the core action but lacks details on return values or side effects.

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?

The input schema has 100% coverage, but descriptions are minimal (e.g., 'ID del proyecto'). The tool description adds no extra meaning beyond the schema.

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 'Agrega un comentario a una tarea' clearly states the verb (add) and resource (comment to a task), but does not distinguish it from sibling tools like list_comments or create_task.

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 guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions.

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

create_taskB

Crea una nueva tarea. Acepta nombre o ID de proyecto. Si no se especifica responsable, se asigna al usuario configurado en ZOHO_MY_USER_ID.

ParametersJSON Schema

Name	Required	Description
`project_id`	Yes	ID numérico o nombre del proyecto (ej: 'sigob-sir-lite')
`name`	Yes	Nombre de la tarea
`description`	No	Descripción
`priority`	No
`person_responsible`	No	ID del usuario responsable (por defecto: ZOHO_MY_USER_ID del .env)
`start_date`	No	Fecha de inicio MM-DD-YYYY
`due_date`	No	Fecha de vencimiento MM-DD-YYYY
`estimated_hours`	No	Horas de trabajo estimadas (ej: '8' o '1.5')
`tasklist_id`	No	ID de la lista de tareas
`custom_fields`	No	Campos personalizados como objeto {column_name: valor} (ej: {UDF_CHAR1: 'Backend'})

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations provided, the description must fully disclose behavioral traits. It mentions that if no responsible person is specified, it defaults to the configured user, which is useful. However, it does not describe side effects (e.g., creation confirmation, error handling), whether it's idempotent, or any restrictions. The transparency is adequate but not thorough.

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 consists of two short, clear sentences with no unnecessary words. It is front-loaded with the primary action and immediately provides key usage details. Every sentence earns its place, making it highly concise.

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's complexity (10 parameters, no output schema), the description is too brief. It does not explain return values, error conditions, or how to effectively use custom_fields or parameters like tasklist_id. More context is needed for an agent to invoke this tool correctly without additional knowledge.

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 high (90%), so the baseline is 3. The description adds minor value by emphasizing that project_id accepts both name and ID, and that person_responsible defaults to ZOHO_MY_USER_ID. This info is partially present in the schema but rephrased, so it does not significantly augment understanding beyond what the schema already provides.

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 verb ('Crea') and resource ('nueva tarea'), indicating a create operation. It also provides extra context about accepting project name or ID and default responsible user. However, it does not explicitly distinguish itself from sibling tools like 'add_comment' or 'update_task', though the purpose is clear from the action.

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 offers some guidance on parameter usage, such as accepting project name or ID and defaulting to ZOHO_MY_USER_ID. However, it does not provide explicit when-to-use or when-not-to-use instructions, nor does it mention alternatives among siblings. The guidance is helpful but limited.

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

get_taskB

Obtiene el detalle completo de una tarea

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	ID del proyecto
`task_id`	Yes	ID de la tarea

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided. The description does not disclose behavioral traits such as reading vs mutating, response format, or any side effects. The name implies a read operation, but no explicit confirmation.

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?

Extremely concise: a single sentence that clearly communicates the tool's purpose. No verbose or redundant 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?

For a simple tool with two required parameters and no output schema, the description is adequate but lacks details about the response structure or what 'complete details' entails. Could be improved with mention of returned fields.

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?

Input schema has 100% coverage with descriptions for both parameters (project_id and task_id). The description adds no extra meaning beyond the schema, warranting a baseline score of 3.

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 gets the complete details of a task, using a specific verb and resource. It effectively distinguishes from siblings like create_task or list_tasks.

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 guidance on when to use this tool vs alternatives (e.g., list_tasks, update_task). No mention of prerequisites or exclusions.

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

list_commentsB

Lista los comentarios de una tarea

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	ID del proyecto
`task_id`	Yes	ID de la tarea

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states the basic action without disclosing behavioral traits like authentication requirements, pagination, or ordering of results, which are important for an agent.

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 a single concise sentence that front-loads the purpose. It earns its place without wasted words, though it could include more detail without becoming verbose.

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 the low complexity (list comments, two required params, no output schema), the description is minimally adequate. However, it lacks behavioral context that would help an agent handle edge cases or understand return values.

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% (both parameters have descriptions). The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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 'Lista los comentarios de una tarea' clearly states the tool lists comments for a task, using a specific verb and resource. It distinguishes from siblings like add_comment (adding) and get_task (task details).

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 guidance is provided on when to use this tool versus alternatives. The description lacks context for when listing comments is appropriate or when other tools, such as add_comment, should be used instead.

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

list_projectsA

Lista todos los proyectos del portal

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

The description indicates a read-only operation, but without annotations, it does not disclose additional behavioral traits like authentication or side effects. However, for a simple list tool, this is minimally adequate.

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 a single, concise sentence with no extraneous information. Every word earns its place.

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?

Given no parameters, no output schema, and a simple list operation, the description is complete. It clearly conveys the tool's function without needing elaboration.

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?

The tool has zero parameters, and the schema coverage is 100% (vacuous). Per rubric, zero-parameter tools get a baseline of 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 'Lista todos los proyectos del portal' clearly states the action (list) and resource (projects), distinguishing it from sibling tools that deal with tasks, comments, users, and timers.

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 tool name and description, but no explicit guidance is given on when to use this tool versus alternatives or when not to use it.

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

list_task_fieldsA

Lista los campos personalizados disponibles en las tareas de un proyecto, incluyendo su column_name para usar en create_task

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	ID o nombre del proyecto

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided; description does not disclose that operation is read-only or any behavioral traits beyond listing. More transparency needed for a tool with no annotations.

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?

Single sentence front-loaded with action and purpose, no wasted words.

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 simple list tool, description is adequate: states what is returned (custom fields with column_name) and why (create_task). Lacks details on output structure but sufficient given no output schema.

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 100% with description for project_id. Description adds no extra parameter semantics beyond schema, meeting 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?

Description clearly states it lists custom fields of a project and identifies the column_name for use in create_task. Distinguishes from sibling tools like list_tasks or list_projects.

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?

Implies usage before create_task via 'para usar en create_task', but lacks explicit when-not-to-use or alternative tool guidance.

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

list_tasksC

Lista las tareas de un proyecto

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	ID del proyecto
`status`	No	Filtro: "open", "closed", "overdue"

TDQS

C2.6/5.0

Behavior1/5

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

With no annotations provided, the description carries the full burden of disclosure. It gives no information about behavior such as handling invalid project IDs, pagination, ordering, or whether it returns all tasks or defaults to open tasks. This is a significant gap.

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

Conciseness3/5

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

The description is a single sentence and front-loads the purpose. However, it is too minimal to provide adequate context, reducing its effectiveness.

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 simple tool with two parameters and no output schema, the description should at least mention that it lists tasks for a given project and the optional status filter. It does not cover the status filter or default behavior, making it incomplete.

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?

The input schema has 100% coverage, documenting both parameters (project_id and status). The description adds nothing beyond the schema, so it meets the baseline of 3.

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 'Lista las tareas de un proyecto' clearly states the tool's action (list) and resource (tasks of a project). It is specific but doesn't explicitly differentiate from sibling tools like get_task or list_comments, though the purpose is clear from the name.

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 guidance is provided on when to use this tool versus alternatives like get_task or list_comments. The description lacks any context about appropriate usage scenarios.

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

list_usersA

Lista los usuarios de un proyecto

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	ID del proyecto

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning permissions, side effects, or error conditions, which is insufficient.

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 a single, concise sentence that conveys the essential purpose without extraneous 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?

For a simple list tool with one parameter and no output schema, the description is adequate but lacks detail on return format, pagination, or error behavior, making it minimally complete.

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 100% with the parameter 'project_id' described as 'ID del proyecto'. The tool description adds no further meaning, resulting in a baseline score of 3.

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 'Lista' (list) and the resource 'usuarios de un proyecto' (users of a project), distinguishing it from sibling tools like list_projects or list_tasks.

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 indicates when to use the tool (to list users of a project) but does not provide any when-not-to-use guidance or mention alternative tools.

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

start_timerB

Inicia el timer de seguimiento de tiempo en una tarea

ParametersJSON Schema

Name	Required	Description
`project_id`	Yes	ID del proyecto
`task_id`	Yes	ID de la tarea
`notes`	No	Notas del registro

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present; the description does not disclose critical behaviors such as whether multiple timers can run simultaneously, whether overriding occurs, permissions needed, or idempotency. This is a significant gap for a mutation tool.

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 a single short sentence, which is concise. It front-loads the purpose but could be somewhat more structured without adding length.

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 no output schema and no annotations, the description is incomplete. It fails to mention return values, side effects, or what happens on success, leaving the agent with insufficient context.

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 100% with descriptions for all parameters. The description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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: starting a time tracking timer on a task. It uses a specific verb ('inicia' = starts) and resource ('timer de seguimiento de tiempo en una tarea'), distinguishing it from siblings like stop_timer.

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 gives no explicit guidance on when to use this tool vs alternatives. The name and sibling stop_timer imply usage, but no clear context or exclusion criteria are provided.

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

stop_timerB

Detiene el timer de una tarea

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	ID del proyecto
`task_id`	Yes	ID de la tarea

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states that it stops a timer, omitting details like whether it saves elapsed time, whether it is destructive, or what happens if timer is not running. This is insufficient.

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 a single short sentence, which is efficient and front-loaded. However, it is slightly under-specified for the tool's complexity, but no unnecessary words exist.

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 no output schema, no annotations, and a mutating operation, the description lacks crucial context such as prerequisites, error conditions, and side effects. It fails to provide complete guidance for an agent.

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 100% with descriptions for both parameters. The tool description adds no extra meaning beyond the schema, so baseline score of 3 applies.

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 'Detiene el timer de una tarea' clearly states the action (stop) and resource (timer of a task), distinguishing it from sibling tools like start_timer. It is specific and unambiguous.

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 guidance is provided on when or when not to use this tool. It does not mention prerequisites (e.g., timer must be running) or alternatives, leaving the agent without context for appropriate invocation.

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

update_taskB

Actualiza una tarea existente (estado, prioridad, responsable, etc.)

ParametersJSON Schema

Name	Required	Description
`project_id`	Yes	ID del proyecto
`task_id`	Yes	ID de la tarea
`name`	No	Nuevo nombre
`status`	No	Estado: "Open", "Closed" o nombre personalizado
`priority`	No
`person_responsible`	No	ID del usuario responsable
`due_date`	No	Fecha límite MM-DD-YYYY

TDQS

B3.3/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. It describes the mutation effect but omits details like idempotency, permission requirements, side effects on omitted fields, and return value.

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?

Single concise sentence, no wasted words, but lacks structured sections that could improve readability for complex tools.

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 no annotations, no output schema, and 7 parameters, the description is insufficient. Missing behavior details like validation, permission, and return format for a mutation tool.

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 high (86%), so baseline is 3. The description lists updatable fields adding minimal new meaning beyond the schema, but does not fully compensate for the remaining undocumented parameters.

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 'Actualiza una tarea existente' (updates an existing task) and lists specific fields like status, priority, and responsible person, distinguishing it from create_task and get_task.

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 implies use for updating existing tasks but does not explicitly state when to use vs. siblings like create_task, nor provide exclusion criteria or prerequisites.

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

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Cada herramienta tiene un propósito claramente distinto: comentarios, tareas, proyectos, usuarios, temporizadores. No hay superposición ni ambigüedad entre ellas.

Naming Consistency5/5

Todas las herramientas siguen el patrón verbo_substantivo en snake_case (add_comment, create_task, list_projects, etc.) sin excepciones ni mezcla de convenciones.

Tool Count5/5

Con 11 herramientas, la superficie está bien delimitada para la gestión de proyectos de Zoho. Cubre las operaciones esenciales sin ser excesiva ni insuficiente.

Completeness4/5

Faltan operaciones de eliminación (delete_task, delete_comment) y algunas de actualización en comentarios, pero el núcleo de creación, lectura y actualización de tareas está cubierto. Es un conjunto funcional con lagunas menores.

Maintenance

ActivityStale

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

Astravue MCP
com.astravue
Manage projects, tasks, time tracking, and team collaboration through natural language.
Project Management Workplace & Productivity
312
UluP Spaces
com.ulupspaces.www
Connect Claude AI to UluP Spaces via MCP — create projects, nodes, and tasks with OAuth 2.0.
Project Management Workplace & Productivity
1
platform7n
tech.p7n
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Communication Project Management Workplace & Productivity
2
hiveclaw
io.github.omiiyamu
Connect AI assistants to HiveClaw — manage projects, talk to AI agents, and more.
Agent Orchestration Project Management Autonomous Agents
2

Related MCP Servers

Jira MCP Server
Project Management Command Line
SunWooBang
A
license
C
quality
D
maintenance
Connects Jira with Claude, enabling users to search issues, view issue details, update issues, add comments, and retrieve project information through natural language commands.
Updated a year ago (2025-06-27 00:12 UTC)
1
98
1
MIT
Zoho Projects MCP Server
Project Management App Automation
qpiai
A
license
B
quality
D
maintenance
Enables AI assistants to interact with Zoho Projects for managing projects, tasks, issues, milestones, users, and performing searches. Supports comprehensive project management operations through natural language with automatic OAuth token handling.
Updated 10 months ago (2025-10-21 01:43 UTC)
20
9
MIT
Atlassian Jira MCP Server
Project Management Developer Tools
aashari
A
license
Not graded
quality
D
maintenance
Connects AI assistants like Claude to Jira projects, enabling natural language queries and operations for issue management, project tracking, comments, and workflows through the Jira REST API.
Updated 6 months ago (2026-03-06 07:29 UTC)
14,799
73
ISC
Motion MCP Server
Project Management Workplace & Productivity
jonesbanana
F
license
Not graded
quality
D
maintenance
Connects Claude.ai to your Motion workspace, enabling task and project management via natural language.
Updated 3 months ago (2026-06-10 21:46 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/falegria86/zoho-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Zona	UTC offset	8am en UTC	5pm en UTC
CDMX verano (CDT)	UTC-5	`0 13 * * 1-5`	`0 22 * * 1-5`
CDMX invierno (CST)	UTC-6	`0 14 * * 1-5`	`0 23 * * 1-5`
Colombia / Perú	UTC-5	`0 13 * * 1-5`	`0 22 * * 1-5`
Argentina	UTC-3	`0 11 * * 1-5`	`0 20 * * 1-5`
España (verano)	UTC+2	`0 6 * * 1-5`	`0 15 * * 1-5`

zoho-projects-mcp

Requisitos

Instalación

Configuración

1. Variables de entorno

2. Autenticación OAuth2

3. Integrar con Claude Desktop

Uso

Iniciar el servidor manualmente

Scripts de utilidad

Herramientas MCP disponibles

Proyectos y tareas

Comentarios

Archivos adjuntos

Tiempo

Notas sobre create_task

Notas sobre update_task

Notas sobre get_time_logs

Notas sobre sync_task_hours

Formato HTML de descripciones

Timer automático (cron)

Paso 1 — obtener los IDs de tu tarea

Paso 2 — obtener el refresh token

Paso 3 — elegir dónde desplegar

Opción A — Railway (recomendado, sin servidor propio)

Opción B — VPS / servidor Linux (Ubuntu, Debian, etc.)

Opción C — Mac o Linux local (la máquina debe estar encendida a esas horas)

Solución de problemas

Arquitectura

Archivos sensibles

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Notas sobre `create_task`

Notas sobre `update_task`

Notas sobre `get_time_logs`

Notas sobre `sync_task_hours`