An MCP server for interacting with the Movidesk public API via natural language, enabling ticket and person/organization management through MCP-compatible hosts (Claude Desktop, VS Code, Cursor, n8n, etc.).
Ticket Operations
List tickets (list_tickets): Retrieve tickets updated in the last 90 days with optional OData filters
List past tickets (list_tickets_past): Retrieve tickets with last update older than 90 days
Get a ticket (get_ticket): Fetch a single ticket by id or protocol
Create a ticket (create_ticket): Create a new ticket with fields like type, subject, category, urgency, status, clients, and initial actions
Update a ticket (update_ticket): Patch an existing ticket, including adding internal notes (type=1) or public replies (type=2) via the actions field
Upload ticket attachment (upload_ticket_attachment): Send a local file as an attachment to a specific ticket action
Person/Organization Operations
List persons (list_persons): Retrieve people/organizations with optional OData filters
Get a person (get_person): Fetch a specific person or organization by id
Create a person (create_person): Create a new person or organization, supporting contacts, emails, CPF/CNPJ, and agent profiles
Update a person (update_person): Patch an existing person/organization (note: sending emails or contacts arrays replaces the entire previous list)
Advanced Filtering: OData parameters ($filter, $select, $expand, $orderby, $top, $skip) are supported on all listing endpoints.
Transport & Deployment
stdio transport for local use (npx, Claude Desktop, VS Code)
Streamable HTTP transport for remote/Docker deployments (e.g., n8n), accessible at /mcp
Error Handling: Relays error bodies returned by the Movidesk API.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-movidesk list my open tickets from the last week"
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.
MCP server for interacting with the Movidesk public API via natural language, exposing ticket and person/organization operations to MCP hosts (Claude Desktop, VS Code, Cursor, and compatible clients).
List, search, create, and update tickets (/tickets and /tickets/past)
Upload attachments to ticket actions (/ticketFileUpload)
List, search, create, and update persons/organizations (/persons)
OData filter support ($filter, $select, $expand, $orderby, $top, $skip) on listing tools
Error handling that forwards the error body returned by the Movidesk API
Related MCP server: Gorgias MCP Server
Tool | Description |
| Lists tickets updated in the last 90 days, with optional OData filters |
| Lists tickets last updated more than 90 days ago ( |
| Fetches a ticket by |
| Creates a new ticket |
| Updates an existing ticket, including notes/replies via |
| Uploads a local file as an attachment to a ticket action |
| Lists persons/organizations, with optional OData filters |
| Fetches a person/organization by |
| Creates a new person/organization |
| Updates an existing person/organization |
Node.js 18+
Movidesk API token (generated in the Movidesk admin panel: Settings → Workspace → API Token)
The authentication token can be provided via environment variable or command-line argument. When both are provided, the argument takes precedence.
Variable / Argument | Required | Description |
| Yes* | Movidesk API token |
| Yes* | Alternative to |
* One of the two is required.
The API base URL (https://api.movidesk.com/public/v1) is fixed and not configurable.
Security: prefer MOVIDESK_TOKEN via env for continuous use. --token is visible in process listings (ps, task manager) and is recommended only for one-off manual testing.
Variable | Required | Default | Description |
| No |
| Transport mode: |
| No |
| Port for the HTTP server (only used when |
| No |
| Bind address for the HTTP server (only used when |
npx github:ferronicardoso/mcp-movideskclaude mcp add movidesk --scope user -- npx -y github:ferronicardoso/mcp-movidesk--scope controls where the server registration is stored:
Scope | Stored in | Visible to |
| project-local, untracked | only you, only in this project |
|
| anyone who clones the repo (commit it to share) |
| your global Claude Code config | you, across every project |
Environment variables can be passed with repeated --env KEY=VALUE flags before the --, e.g.:
Bash (Linux/macOS/WSL):
claude mcp add movidesk --scope user \
--env MOVIDESK_TOKEN=your-token-here \
-- npx -y github:ferronicardoso/mcp-movideskPowerShell:
claude mcp add movidesk --scope user `
--env MOVIDESK_TOKEN=your-token-here `
-- npx -y github:ferronicardoso/mcp-movideskBash (Linux/macOS/WSL):
codex mcp add movidesk \
--env MOVIDESK_TOKEN=your-token-here \
npx -- -y github:ferronicardoso/mcp-movideskPowerShell:
codex mcp add movidesk `
--env MOVIDESK_TOKEN=your-token-here `
npx -- -y github:ferronicardoso/mcp-movideskThis registers the server in ~/.codex/config.toml. To remove it, run codex mcp remove movidesk.
%APPDATA%\\Claude\\claude_desktop_config.json:
{
"mcpServers": {
"movidesk": {
"command": "npx",
"args": ["github:ferronicardoso/mcp-movidesk"],
"env": {
"MOVIDESK_TOKEN": "your-token-here"
}
}
}
}.vscode/mcp.json:
{
"servers": {
"movidesk": {
"command": "npx",
"args": ["github:ferronicardoso/mcp-movidesk"],
"env": {
"MOVIDESK_TOKEN": "your-token-here"
}
}
}
}The published image runs in Streamable HTTP mode by default, for use as a remote MCP endpoint (e.g. from n8n's MCP Client Tool node or any Streamable HTTP-compatible client):
Bash (Linux/macOS/WSL):
docker run -d --name mcp-movidesk \
-p 3003:3003 \
-e MOVIDESK_TOKEN=your-token-here \
ghcr.io/ferronicardoso/mcp-movidesk:latestPowerShell:
docker run -d --name mcp-movidesk `
-p 3003:3003 `
-e MOVIDESK_TOKEN=your-token-here `
ghcr.io/ferronicardoso/mcp-movidesk:latestThe MCP endpoint is then available at http://localhost:3003/mcp.
git clone https://github.com/ferronicardoso/mcp-movidesk
cd mcp-movidesk
npm install
npm run buildStart the compiled server:
MOVIDESK_TOKEN=your-token-here npm startThis repository intentionally tracks dist/ to support npx github:user/repo usage.
The project uses a Husky pre-commit hook to:
build TypeScript (npm run build)
stage generated artifacts (git add dist)
Manual fallback:
npm run build
git add distNever commit the real token or .env files.
Use MOVIDESK_TOKEN via environment for continuous use; avoid --token outside of one-off testing.
The API's 10 requests/minute limit applies from 7:01 AM to 6:59 PM; outside that window access is unrestricted.
MIT © Raphael Augusto Ferroni Cardoso
Cria uma nova pessoa/organização (POST /persons). Contatos são informados nos arrays emails[] ({emailType, email, isDefault}) e contacts[] ({contactType, contact, isDefault}). Documento (CPF ou CNPJ) vai no campo cpfCnpj. Agentes (profileType=1) exigem accessProfile e teams.
| Name | Required | Description | Default |
|---|---|---|---|
| isActive | Yes | Se a pessoa/organização está ativa | |
| personType | Yes | 1=Pessoa física, 2=Empresa, 4=Departamento | |
| profileType | Yes | 1=Agente, 2=Cliente, 3=Agente e Cliente | |
| businessName | Yes | Nome ou razão social |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It identifies the operation as a POST request and highlights a specific requirement for agents. However, it does not mention idempotency, error handling, or rate limits, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by specific details. It is efficient and well-organized, though could benefit from slight structural formatting (e.g., bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema, the description covers input parameters thoroughly, including special cases for agents. Missing is information about the response structure or error scenarios, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for required properties, but the description adds value by explaining the structure of optional contacts arrays and the document field, which are not in the schema. This provides meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new person/organization via POST /persons. It distinguishes from sibling tools like update_person and get_person by focusing on creation, and provides specific details about contacts, document field, and agent requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit instructions on how to specify contacts and document, and notes that agents require additional fields. It implicitly differentiates from update/create ticket by resource type, but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cria um novo ticket no Movidesk (POST /tickets). Aceita os campos do ticket conforme o layout da API (type, subject, category, urgency, status, clients, actions, etc.). O campo actions permite registrar a descrição inicial (type=1 nota interna, type=2 resposta pública).
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Tipo do ticket | |
| subject | Yes | Assunto do ticket |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions the HTTP method and field types but omits success/failure behavior, return value, or required permissions. This is insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no extraneous text. The action and endpoint are front-loaded, and the field examples are relevant. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify what is returned upon creation. It does not. However, the context of sibling tools and the REST endpoint partially compensate. The description is adequate for a simple creation tool but lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the two required parameters. The description adds value by mentioning the optional 'actions' field and its subtypes, but does not enhance meaning for the parameters already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new ticket in Movidesk using POST /tickets. It lists accepted fields, distinguishing it from sibling tools like create_person or get_ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like update_ticket. The description does not specify prerequisites or exclusions, leaving the agent to infer usage from the verb 'create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca uma pessoa/organização específica por id (GET /persons).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id da pessoa/organização |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavior beyond 'fetch by id', e.g., what happens if ID not found, or side effects. Minimal transparency for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Includes the endpoint in parentheses for extra clarity. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-by-id tool with one parameter and no output schema, the description is nearly complete. Could mention return format or error handling, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a well-described 'id' parameter. The description adds no additional meaning beyond 'by id', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Busca uma pessoa/organização específica por id' (search for a specific person/organization by id) and includes the HTTP method and endpoint. It distinguishes from siblings like list_persons and create_person by specifying retrieval by id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives (e.g., list_persons). It implies use when an ID is known, but lacks conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca um único ticket por id ou por protocolo. Ao menos um dos dois é obrigatório.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Id do ticket | |
| protocol | No | Número de protocolo do ticket | |
| includeDeletedItems | No | Inclui ações, clientes e tickets pai/filho deletados |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds that at least one parameter is required but does not explain error behavior, prioritization if both provided, or details about includeDeletedItems effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence in Portuguese that conveys the core purpose and a key usage condition. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple lookup tool with 3 parameters, but lacks details on return structure, error cases, and behavior when both id and protocol are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 a critical constraint (at least one of id/protocol required) not enforced in the schema, enhancing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for a single ticket by id or protocol. It distinguishes itself from sibling tools like list_tickets (multiple) and list_tickets_past (past tickets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes that at least one of id or protocol is required, providing clear context for usage. However, it does not mention when to use alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista pessoas/organizações do Movidesk (GET /persons), com suporte a filtros OData.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Quantidade máxima de itens a retornar ($top, paginação) | |
| skip | No | Quantidade de itens a pular ($skip, paginação) | |
| filter | No | Expressão de filtro OData ($filter), ex.: "status eq 'Novo'" ou "clients/any(c: c/id eq '1')" | |
| select | No | Lista de campos a retornar ($select), separados por vírgula | |
| orderby | No | Campo de ordenação OData ($orderby), ex.: "id desc" |
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 mentions it is a GET list operation with OData support, which is transparent, but does not disclose rate limits, authentication needs, or pagination behavior beyond the parameter descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the purpose and key feature (OData filters) without waste. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description is complete enough for a list tool. It covers the core action and filter capability. However, it could briefly mention that it returns paginated results, though top/skip parameters imply that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter with details. The description adds no new meaning beyond restating OData filter support, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list persons/organizations from Movidesk) and the resource (GET /persons), with OData filter support. It distinguishes from sibling tools like create_person, get_person, and update_person, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing persons with OData filters but does not explicitly state when to use this tool versus alternatives like list_tickets or get_person. No when-not or exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista tickets atualizados nos últimos 90 dias (rota /tickets). Para tickets mais antigos, use list_tickets_past.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Quantidade máxima de itens a retornar ($top, paginação) | |
| skip | No | Quantidade de itens a pular ($skip, paginação) | |
| expand | No | Entidades relacionadas a expandir ($expand), ex.: "clients" | |
| filter | No | Expressão de filtro OData ($filter), ex.: "status eq 'Novo'" ou "clients/any(c: c/id eq '1')" | |
| select | No | Lista de campos a retornar ($select), separados por vírgula, ex.: "id,subject,status" | |
| orderby | No | Campo de ordenação OData ($orderby), ex.: "id desc" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description reveals a key behavioral trait: automatic filtering to the last 90 days. This adds value beyond the schema, though it omits other details like pagination or read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, and no unnecessary words. The alternative is efficiently presented in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 OData parameters and no output schema, the description is minimal. It covers the time scope but lacks details about return format or that it uses OData, though parameter descriptions fill some gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter having its own description. The tool description does not add parameter-specific meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lista' and resource 'tickets', and specifies the scope 'atualizados nos últimos 90 dias', which distinguishes it from the sibling tool list_tickets_past.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use this tool ('Para tickets mais antigos') and directs to the appropriate alternative (list_tickets_past), providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista tickets com última atualização (lastupdate) anterior a 90 dias (rota /tickets/past).
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Quantidade máxima de itens a retornar ($top, paginação) | |
| skip | No | Quantidade de itens a pular ($skip, paginação) | |
| expand | No | Entidades relacionadas a expandir ($expand), ex.: "clients" | |
| filter | No | Expressão de filtro OData ($filter), ex.: "status eq 'Novo'" ou "clients/any(c: c/id eq '1')" | |
| select | No | Lista de campos a retornar ($select), separados por vírgula, ex.: "id,subject,status" | |
| orderby | No | Campo de ordenação OData ($orderby), ex.: "id desc" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions the 90-day filter but does not state that it is a read-only operation, describe pagination behavior, or note any rate limits or side effects. The description adds minimal behavioral context beyond the filter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core purpose. It is front-loaded with the key information. However, it could include more detail without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters and no output schema, the description provides minimal context. It does not explain the return value format, pagination behavior, or how the 90-day filter interacts with the $filter parameter. The tool is relatively complex, and the description falls short of being complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions for all 6 parameters. The description does not add any additional parameter-level information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists tickets with last update older than 90 days, using the route /tickets/past. It distinguishes from sibling tools like list_tickets (which presumably lists all tickets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving old tickets but does not explicitly state when to use it versus alternatives like list_tickets. No guidance on exclusions or specific scenarios is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Atualiza uma pessoa/organização existente (PATCH /persons?id=). Envie somente os campos a alterar. ATENÇÃO: enviar os arrays emails ou contacts sobrescreve a lista inteira anterior — inclua todos os itens desejados, não apenas o novo.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id da pessoa/organização a atualizar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses PATCH method and array replacement behavior, critical for correct use. No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose followed by warnings. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a partial update tool with array semantics, description covers all key points needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers id well, but description adds essential meaning for additional properties: partial updates and array replacement. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing person/organization via PATCH, distinguishing it from siblings like create_person or get_person.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to send only changed fields and warns that arrays overwrite the entire list. Lacks explicit alternatives or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Atualiza um ticket existente (PATCH /tickets?id=). Envie somente os campos a alterar. O campo actions permite adicionar notas internas (type=1) ou respostas públicas (type=2) ao ticket.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id do ticket a atualizar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some behavioral context: it reveals that the 'actions' field supports internal notes (type=1) and public replies (type=2). However, it does not disclose other behaviors such as return value, side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the core purpose, HTTP method, usage tip, and special field behavior. No redundant words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 reasonably complete for a PATCH operation but lacks details on response format and full structure of actions field (e.g., required subfields). Adequate for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'id' with a minimal description, but the tool description adds substantial meaning to the implicit 'actions' parameter (allowed types). Since additionalProperties allows many parameters, the description compensates for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing ticket using PATCH, specifying the verb and resource. It implicitly distinguishes from sibling tools like create_ticket (create vs update) and list_tickets (list vs update) via the verb, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to send only changed fields, which is correct PATCH behavior. However, it does not provide when-not-to-use guidance or mention alternatives (e.g., use create_ticket for new tickets, list_tickets for reading).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Envia um arquivo local como anexo de uma ação de ticket (POST /ticketFileUpload). Requer um caminho de arquivo existente no filesystem local.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id do ticket | |
| actionId | Yes | Id da ação do ticket à qual o anexo será associado | |
| filePath | Yes | Caminho absoluto do arquivo local a ser enviado |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions the requirement for an existing file path but omits critical details such as file size limits, error handling, authentication needs, or whether the upload is idempotent. For a mutation tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that are front-loaded with the action verb and resource. Every word is necessary and contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool, the description covers the core purpose and a key requirement. However, lacking annotations and an output schema, it could be more complete by mentioning return values or common error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 no additional meaning beyond what the schema already provides for the parameters; it only reiterates the file path requirement implicitly. No extra context for 'id' or 'actionId' is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a local file as an attachment to a ticket action, including the HTTP method and endpoint. This distinguishes it from sibling tools that focus on CRUD operations for persons and tickets, none of which involve file upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies a key usage condition: the file path must exist on the local filesystem. However, it does not provide guidance on when to use this tool versus alternatives, though no direct alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_personcreate_ticketget_personget_ticketlist_personslist_ticketslist_tickets_pastupdate_personupdate_ticketupload_ticket_attachmentScored across 10 tools
Each tool targets a distinct resource (person vs ticket) and action (create, get, list, update, upload). The split between list_tickets and list_tickets_past clearly differentiates recent and historical data. No overlap or ambiguity.
All tools follow a consistent verb_noun pattern in snake_case: create_person, get_person, list_persons, update_person, create_ticket, etc. Even upload_ticket_attachment adheres to verb_noun_noun. No mixing of styles.
10 tools is well-scoped for a CRM/helpdesk server. It covers CRUD for persons and tickets plus file upload, without unnecessary complexity. Each tool serves a clear purpose.
The tool surface covers create, read, update, and list for both persons and tickets, but lacks delete operations. This is a notable gap that may require workarounds like status changes. Additionally, no search or advanced filtering beyond OData parameters is provided.
Read tickets, contacts, companies, agents and groups; create, update and reply to tickets.
Read tickets, users, orgs, macros and satisfaction ratings; create, update and comment on tickets.
Provides access to Civic Plus - See Click Fix, allowing you to interact with your data via an LLM.…
Give AI agents access to form submissions — read, search, update, and process file attachments.
