How do I use mcp-otobo?

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., "@mcp-otobo Search for open high priority tickets in the Support queue." 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-otobo

by domnussbaum

Overview Schema Related Servers Score Discussions

TypeScript

Remote

mcp-otobo

A Model Context Protocol (MCP) server for Otobo — the open-source ITSM and helpdesk system. This server enables AI assistants to search, create, update, and manage tickets in your Otobo instance through the Generic Interface REST API.

Features

Search tickets by queue, state, priority, customer, title, date ranges, and more
Get ticket details including full communication history and dynamic fields
Create tickets with initial articles
Update tickets — change state, queue, priority, owner, add articles
Close tickets with optional closing notes
Add internal notes to tickets
View ticket history — full audit trail of changes
List queues, states, and priorities from your Otobo instance

Related MCP server: tickiti-mcp

Prerequisites

Node.js 18 or later
An Otobo instance with a configured Generic Interface web service (see Otobo Setup)
An agent account with API access permissions

Installation

npm install -g mcp-otobo

Or run directly with npx:

npx mcp-otobo

Or clone and build from source:

git clone https://github.com/domnussbaum/otobo-mcp.git
cd mcp-otobo
npm install
npm run build

Configuration

The server is configured via environment variables:

Variable	Required	Default	Description
`OTOBO_BASE_URL`	Yes	—	Your Otobo instance URL (e.g. `https://otobo.example.com`)
`OTOBO_USERNAME`	Yes	—	Agent username for API access
`OTOBO_PASSWORD`	Yes	—	Agent password
`OTOBO_WEBSERVICE`	No	`GenericTicketConnectorREST`	Web service name configured in Otobo
`OTOBO_UNSAFE_SSL`	No	`false`	Set to `true` to allow self-signed/internal SSL certificates

Copy .env.example to .env and fill in your values:

cp .env.example .env

Available Tools

Core Ticket Operations

Tool	Description
`search_tickets`	Search tickets by queue, state, priority, customer, title, ticket number, date ranges
`get_ticket`	Get full ticket details with articles and dynamic fields
`create_ticket`	Create a new ticket with first article
`update_ticket`	Update ticket fields and optionally add an article

History

Tool	Description
`get_ticket_history`	Get the full change history of a ticket

Metadata

Tool	Description
`list_queues`	List available queues in the system
`list_states`	List available ticket states
`list_priorities`	List available ticket priorities

Convenience

Tool	Description
`close_ticket`	Close a ticket with an optional note
`add_note`	Add an internal note to a ticket

Integration Examples

Claude Desktop

Add to your claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "otobo": {
      "command": "npx",
      "args": ["-y", "mcp-otobo"],
      "env": {
        "OTOBO_BASE_URL": "https://otobo.example.com",
        "OTOBO_USERNAME": "your-agent-user",
        "OTOBO_PASSWORD": "your-agent-password",
        "OTOBO_WEBSERVICE": "GenericTicketConnectorREST"
      }
    }
  }
}

Or if installed from source:

{
  "mcpServers": {
    "otobo": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-otobo/build/index.js"],
      "env": {
        "OTOBO_BASE_URL": "https://otobo.example.com",
        "OTOBO_USERNAME": "your-agent-user",
        "OTOBO_PASSWORD": "your-agent-password"
      }
    }
  }
}

Claude Code

Add to your project's .mcp.json file:

{
  "mcpServers": {
    "otobo": {
      "command": "npx",
      "args": ["-y", "mcp-otobo"],
      "env": {
        "OTOBO_BASE_URL": "https://otobo.example.com",
        "OTOBO_USERNAME": "your-agent-user",
        "OTOBO_PASSWORD": "your-agent-password",
        "OTOBO_WEBSERVICE": "GenericTicketConnectorREST"
      }
    }
  }
}

Or add it via the CLI with environment variables:

claude mcp add otobo \
  -e OTOBO_BASE_URL=https://otobo.example.com \
  -e OTOBO_USERNAME=your-agent-user \
  -e 'OTOBO_PASSWORD=your-agent-password' \
  -e OTOBO_WEBSERVICE=GenericTicketConnectorREST \
  -- npx -y mcp-otobo

Cursor

Add to your Cursor MCP settings (.cursor/mcp.json):

{
  "mcpServers": {
    "otobo": {
      "command": "npx",
      "args": ["-y", "mcp-otobo"],
      "env": {
        "OTOBO_BASE_URL": "https://otobo.example.com",
        "OTOBO_USERNAME": "your-agent-user",
        "OTOBO_PASSWORD": "your-agent-password",
        "OTOBO_WEBSERVICE": "GenericTicketConnectorREST"
      }
    }
  }
}

Windsurf

Add to your Windsurf MCP configuration (~/.windsurf/mcp.json):

{
  "mcpServers": {
    "otobo": {
      "command": "npx",
      "args": ["-y", "mcp-otobo"],
      "env": {
        "OTOBO_BASE_URL": "https://otobo.example.com",
        "OTOBO_USERNAME": "your-agent-user",
        "OTOBO_PASSWORD": "your-agent-password",
        "OTOBO_WEBSERVICE": "GenericTicketConnectorREST"
      }
    }
  }
}

ChatGPT / OpenAI (via MCP Bridge)

ChatGPT does not natively support MCP. However, third-party MCP-to-OpenAI bridge tools exist that can expose any MCP server as an OpenAI-compatible function-calling API. Search for "MCP OpenAI bridge" or "MCP proxy" for current options.

Codex CLI

Set up environment variables and configure MCP in your Codex configuration:

export OTOBO_BASE_URL=https://otobo.example.com
export OTOBO_USERNAME=your-agent-user
export OTOBO_PASSWORD='your-agent-password'

codex --full-auto "Search for open tickets"

Or add to your ~/.codex/config.json:

{
  "mcpServers": {
    "otobo": {
      "command": "npx",
      "args": ["-y", "mcp-otobo"],
      "env": {
        "OTOBO_BASE_URL": "https://otobo.example.com",
        "OTOBO_USERNAME": "your-agent-user",
        "OTOBO_PASSWORD": "your-agent-password",
        "OTOBO_WEBSERVICE": "GenericTicketConnectorREST"
      }
    }
  }
}

Gemini CLI

Add to your Gemini CLI MCP settings file (~/.gemini/settings.json):

{
  "mcpServers": {
    "otobo": {
      "command": "npx",
      "args": ["-y", "mcp-otobo"],
      "env": {
        "OTOBO_BASE_URL": "https://otobo.example.com",
        "OTOBO_USERNAME": "your-agent-user",
        "OTOBO_PASSWORD": "your-agent-password",
        "OTOBO_WEBSERVICE": "GenericTicketConnectorREST"
      }
    }
  }
}

Generic MCP Client

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

const transport = new StdioClientTransport({
  command: "npx",
  args: ["-y", "mcp-otobo"],
  env: {
    OTOBO_BASE_URL: "https://otobo.example.com",
    OTOBO_USERNAME: "your-agent-user",
    OTOBO_PASSWORD: "your-agent-password",
    OTOBO_WEBSERVICE: "GenericTicketConnectorREST",
  },
});

const client = new Client({ name: "my-app", version: "1.0.0" });
await client.connect(transport);

// List available tools
const tools = await client.listTools();
console.log(tools);

// Search for open tickets
const result = await client.callTool("search_tickets", {
  states: ["open", "new"],
  limit: 10,
});
console.log(result);

Otobo Setup

To use this MCP server, your Otobo instance needs a properly configured Generic Interface web service.

Step 1: Create a Web Service

Log in to Otobo as an admin
Navigate to Admin → Generic Interface → Web Services
Click Add Web Service
Set:
- Name: GenericTicketConnectorREST (or your preferred name — must match OTOBO_WEBSERVICE)
- Network Transport: HTTP::REST

Step 2: Add Operations

Add the following four operations to your web service. For each one:

Click Add Operation
Set the Name (e.g. TicketCreate)
Select the Operation-Backend:

Name	Operation-Backend
`TicketCreate`	`Ticket::TicketCreate`
`TicketGet`	`Ticket::TicketGet`
`TicketSearch`	`Ticket::TicketSearch`
`TicketUpdate`	`Ticket::TicketUpdate`

Leave mapping settings at their defaults
Click Save

Step 3: Configure Transport & Route Mapping

Back on the web service overview, go to Network Transport → Configure
Set Maximum message length: 10000000 (or higher for large tickets)
Configure the Route mapping for each operation:

Operation	Route	Request Method
`TicketCreate`	`/TicketCreate`	`POST`
`TicketGet`	`/TicketGet`	`POST`
`TicketSearch`	`/TicketSearch`	`POST`
`TicketUpdate`	`/TicketUpdate`	`POST`

Save

Step 4: Create an API Agent

Security note: Once a REST web service is active, any valid agent account can authenticate against it. There is no way to restrict the web service itself to specific users. Access control is handled entirely through group and queue permissions. It is strongly recommended to create a dedicated API agent with minimal permissions.

Navigate to Admin → Agents
Create a dedicated agent account for API access (e.g. api-user)
Create a dedicated group (e.g. api-access) under Admin → Groups
Under Admin → Agents ↔ Groups, assign only the API agent to this group
Under Admin → Queues ↔ Groups, grant access only to the queues the API should reach
Use this agent's credentials for OTOBO_USERNAME and OTOBO_PASSWORD

Step 5: Verify

Test your setup with curl:

curl -X POST \
  "https://otobo.example.com/otobo/nph-genericinterface.pl/Webservice/GenericTicketConnectorREST/TicketSearch" \
  -H "Content-Type: application/json" \
  -d '{"UserLogin":"your-agent","Password":"your-password"}'

You should get a JSON response with ticket IDs.

Troubleshooting

"Missing required environment variable"

Make sure all required environment variables are set. Check that your MCP client configuration passes the env block correctly.

"Otobo API error (HTTP 403)"

Your agent account may lack the necessary permissions. Check:

The agent exists and is valid in Otobo
The agent has group permissions for the queues you're trying to access
The web service is active (not deactivated)

"Otobo API error (HTTP 404)"

The web service endpoint is not found. Verify:

The web service name matches OTOBO_WEBSERVICE
The operations are configured with correct route mappings
The Otobo URL is correct and accessible

"Otobo API error (HTTP 500)"

An internal server error in Otobo. Check:

Otobo system logs (/opt/otobo/var/log/ or your log directory)
The request payload is valid (required fields like Queue, State, Priority)
Customer user exists in the system when creating tickets

Connection Issues

Ensure your Otobo instance is reachable from the machine running the MCP server
Check for firewalls, VPN requirements, or SSL certificate issues
For self-signed or internal SSL certificates, set OTOBO_UNSAFE_SSL=true in your environment configuration

"No tickets found" for list_queues/list_states/list_priorities

These metadata tools discover values from existing tickets. If your system has no tickets yet, they return default values. Create a test ticket first, or use the known defaults:

Queues: Raw, Junk, Misc, Postmaster (depends on your setup)
States: new, open, pending reminder, closed successful, closed unsuccessful
Priorities: 1 very low, 2 low, 3 normal, 4 high, 5 very high

License

MIT

Available Tools

10 tools

add_noteA

Add an internal note to a ticket without changing its state

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Note body text
`subject`	No	Note subject (default: 'Note')
`ticket_id`	Yes	The Otobo ticket ID
`content_type`	No	Content type (default: 'text/plain; charset=utf-8')

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the key behavioral trait (no state change) but omits other important aspects such as authentication requirements, visibility of the note, or whether it triggers notifications. It 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, well-formed sentence that conveys the essential purpose without filler. Every word adds value.

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 tool's simplicity and lack of output schema, the description is mostly complete but fails to mention what the tool returns (e.g., success indicator, note ID). This is a notable gap.

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% so the schema already documents all parameters. The description adds no additional parameter details beyond the schema, which sets the baseline at 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 action ('add an internal note') and the resource ('ticket'), with the important qualifier 'without changing its state'. This distinguishes it from sibling tools like close_ticket or update_ticket that do change the ticket state.

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 implies when to use this tool (when you want to add a note without altering ticket state), but it does not explicitly mention when not to use it or provide alternatives. It is clear but lacks exclusions.

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

close_ticketC

Close a ticket by setting its state to 'closed successful' and optionally adding a closing note

ParametersJSON Schema

Name	Required	Description
`note`	No	Optional closing note/reason
`state`	No	Close state (default: 'closed successful'). Use 'closed unsuccessful' for unresolved tickets.
`ticket_id`	Yes	The Otobo ticket ID to close

TDQS

C2.9/5.0

Behavior2/5

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

The description discloses only the basic action (state change and note addition) but does not address side effects, permissions, idempotency, or error conditions. Since no annotations exist, this leaves significant behavioral gaps for the 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, focused sentence that efficiently conveys the core function. It is well-structured and front-loaded, though it could be slightly more detailed without sacrificing clarity.

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 absence of annotations and an output schema, the description is insufficient for a mutation tool. It fails to explain return values, error conditions, or the behavior when the note parameter is omitted, leaving important context missing.

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 already provides full parameter descriptions (100% coverage), including the state parameter's default and alternative values. The description adds minimal new information beyond restating schema content, justifying a baseline score 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 clearly states the tool's purpose: closing a ticket by setting its state to 'closed successful' and optionally adding a note. It is specific about the action and outcome, but does not differentiate from the sibling tool 'update_ticket', which could also modify the state.

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 'update_ticket' or 'add_note'. The agent must infer usage from the name and parameters alone, increasing the risk of incorrect tool selection.

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

create_ticketB

Create a new Otobo ticket with a first article (message)

ParametersJSON Schema

Name	Required	Description
`type`	No	Ticket type, if configured
`owner`	No	Agent owner login
`queue`	Yes	Queue name, e.g. 'Raw' or 'Postmaster'
`state`	No	Ticket state (default: 'new')
`title`	Yes	Ticket title/subject
`priority`	No	Priority name (default: '3 normal')
`responsible`	No	Responsible agent login
`sender_type`	No	Sender type: 'agent', 'system', 'customer' (default: 'customer')
`article_body`	Yes	Article body text
`customer_user`	Yes	Customer user login or email
`article_subject`	No	Article subject (defaults to ticket title)
`article_content_type`	No	Content type (default: 'text/plain; charset=utf-8')
`communication_channel`	No	Communication channel: 'Email', 'Phone', 'Internal' (default: 'Email')

TDQS

B3/5.0

Behavior1/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 creation action without disclosing any behavioral traits such as permissions required, side effects (e.g., notifications), or return values.

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 that front-loads the core action. 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.

Completeness2/5

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

Despite having 13 parameters and no output schema or annotations, the description is minimal. It lacks details on return values, error conditions, or any constraints beyond what the schema provides.

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%, so the schema documents all parameters. The description does not add any extra meaning beyond the schema, meeting the baseline 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 'Create a new Otobo ticket with a first article (message)', which is a specific verb-resource pair. It distinguishes from sibling tools like add_note (which adds to existing tickets) and update_ticket.

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 versus alternatives. It implies creation but doesn't exclude scenarios where other tools like search_tickets or get_ticket would be more appropriate.

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

get_ticketB

Get full ticket details by TicketID, including articles (communication history) and dynamic fields

ParametersJSON Schema

Name	Required	Description
`extended`	No	Include extended information (default: false)
`ticket_id`	Yes	The Otobo ticket ID
`include_articles`	No	Include all articles/messages (default: true)
`include_dynamic_fields`	No	Include dynamic fields (default: true)

TDQS

B3.3/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 implies a read operation but does not explicitly state that it is non-destructive, or mention any rate limits, authorization needs, or side effects.

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 clear sentence with no unnecessary words. It is front-loaded with the core action and resource.

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 simplicity of the tool and full schema coverage, the description is adequate but lacks details on return structure or error handling. No output schema exists, so additional context about the response would be beneficial.

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 mentions articles and dynamic fields, which aligns with parameters, but does not add additional meaning beyond the schema.

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

Purpose5/5

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

The description clearly states the tool retrieves full ticket details by TicketID, including articles and dynamic fields. It distinguishes from sibling tools like search_tickets and get_ticket_history by specifying the scope.

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 versus alternatives like get_ticket_history or search_tickets. The description does not provide usage context or prerequisites.

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

get_ticket_historyA

Get the full change history of a ticket (who changed what, when)

ParametersJSON Schema

Name	Required	Description	Default
`ticket_id`	Yes	The Otobo ticket ID

TDQS

A3.7/5.0

Behavior3/5

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

The description discloses the tool returns 'full change history' with 'who changed what, when', but lacks details on pagination, ordering, error behavior, or whether it requires ticket existence. With no annotations, the description partially covers behavioral traits.

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 the verb and resource, no redundant words. Highly concise and efficient for an agent.

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 tool has only one parameter, no output schema, and no annotations, the description is adequate but could provide more context (e.g., return format, pagination, or data sensitivity). It meets minimum viability but lacks completeness for a history tool.

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% for the single required parameter 'ticket_id'. The description adds value by specifying 'The Otobo ticket ID', clarifying the ID system beyond the schema's minimal description.

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 'Get the full change history of a ticket (who changed what, when)' clearly states the tool's function with a specific verb and resource, and distinguishes it from siblings like get_ticket or search_tickets.

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 versus alternatives (e.g., get_ticket for current state, search_tickets for searching). No exclusions or prerequisites are mentioned.

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

list_prioritiesA

List available Otobo ticket priorities by examining existing tickets. Returns priority names found in the system.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

The description explains that it 'examines existing tickets' to derive priorities and 'returns priority names found in the system', providing clear behavioral context beyond the lack of 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?

The description is two concise sentences with no extraneous information, each providing essential value: the action and the output.

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 the tool's simplicity (no parameters, no output schema, no annotations), the description fully specifies its purpose and what it returns, making it complete for an AI agent to use correctly.

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?

There are no parameters in the input schema (schema coverage 100%), and the description implicitly covers the parameter semantics by stating the tool's behavior; baseline score of 4 for zero-parameter tools.

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 'List' and the resource 'available Otobo ticket priorities', uniquely identifying its function among sibling tools like list_queues and list_states.

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 versus alternatives, such as if specific priority names are needed or if a broader search is required. It lacks explicit usage context.

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

list_queuesA

List available Otobo queues by searching for tickets across all queues. Returns queue names found in the system.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/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 discloses the tool lists queues by searching tickets but lacks details on authentication, error handling, side effects, or return format beyond 'returns queue names'. Limited behavioral context.

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 with no wasted words. Front-loaded with the action and resource. Every sentence provides valuable 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?

For a simple zero-parameter tool, the description adequately states what it returns (queue names) and the method (searching tickets). It does not mention sorting or pagination, but these are not expected given no parameters. Sufficient for the tool's complexity.

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?

No parameters exist, so schema description coverage is 100%, and baseline is 4. The description explains the tool's purpose but adds no param-specific info since there are none. Adequate for zero-param tool.

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?

Clearly states the action 'list' and the resource 'Otobo queues', and specifies it finds queues by searching tickets across all queues. Distinguishes from sibling tools like list_priorities or list_states, which are for different resources.

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 description only states what it does, without indicating prerequisites, exclusions, or comparisons to other tools.

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

list_statesA

List available Otobo ticket states by examining existing tickets. Returns state names found in the system.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

Without annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool examines existing tickets to determine available states, implying it is read-only and dynamic. This is fairly transparent, though it could be more explicit about side effects or limitations.

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 two sentences with no wasted words. The first sentence immediately states the action and scope, and the second clarifies the return value. It is efficiently front-loaded.

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 the tool's simplicity (no parameters, no output schema), the description sufficiently covers its purpose and output. it mentions returning state names, which is adequate for an agent to understand what to expect.

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 100% schema coverage, so the description does not need to add parameter information. By the guidelines, 0 parameters yields 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 clearly states the tool's purpose: listing available Otobo ticket states. The verb 'List' and resource 'ticket states' are specific. It distinguishes from sibling tools like list_priorities and list_queues which focus on different entities.

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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or conditions. It simply states what it does without contextualizing its usage relative to other tools.

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

search_ticketsA

Search Otobo tickets by various criteria (Queue, State, Priority, CustomerUser, Title, TicketNumber, date ranges, etc.)

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of results (default: 100)
`locks`	No	Filter by lock state: 'lock' or 'unlock'
`title`	No	Search by ticket title (substring match)
`types`	No	Filter by ticket types
`queues`	No	Filter by queue names, e.g. ['Raw', 'Junk']
`states`	No	Filter by state names, e.g. ['new', 'open']
`sort_by`	No	Sort field, e.g. 'Age', 'Ticket', 'Created', 'Changed', 'Priority', 'Queue', 'State', 'Owner'
`order_by`	No	Sort order: 'Up' (ascending) or 'Down' (descending)
`priorities`	No	Filter by priority names, e.g. ['3 normal', '4 high']
`changed_after`	No	Only tickets changed after this date (YYYY-MM-DD HH:MM:SS)
`created_after`	No	Only tickets created after this date (YYYY-MM-DD HH:MM:SS)
`customer_user`	No	Filter by customer user login
`ticket_number`	No	Search by exact ticket number
`changed_before`	No	Only tickets changed before this date (YYYY-MM-DD HH:MM:SS)
`created_before`	No	Only tickets created before this date (YYYY-MM-DD HH:MM:SS)

TDQS

A3.5/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 lists filter criteria but does not mention pagination, sorting behavior, error handling, or what happens with no results. The agent lacks critical context about execution.

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 sentence under 20 words, listing key filters compactly. No redundancy or fluff.

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?

With 15 parameters and no output schema or annotations, the description is minimal. It covers the high-level purpose but omits details like return format, pagination (limit is not explained), and sort order. 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.

Parameters3/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 lists filter criteria but adds no new meaning beyond the schema descriptions, which already detail substring match, date format, etc. It does not improve semantic 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 it searches Otobo tickets by various criteria, listing specific filters like Queue, State, Priority, etc. This distinguishes it from sibling tools like get_ticket (single ticket) or create_ticket (creation).

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 usage for searching/filtering tickets, but does not explicitly state when to use vs alternatives (e.g., use get_ticket for a single ticket). No exclusions or prerequisites mentioned.

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

update_ticketB

Update an existing Otobo ticket (change state, queue, priority, owner, etc.) and optionally add a new article

ParametersJSON Schema

Name	Required	Description
`lock`	No	Lock state: 'lock' or 'unlock'
`type`	No	New ticket type
`owner`	No	New owner agent login
`queue`	No	Move to queue
`state`	No	New state, e.g. 'open', 'pending reminder', 'closed successful'
`title`	No	New ticket title
`priority`	No	New priority
`ticket_id`	Yes	The Otobo ticket ID to update
`responsible`	No	New responsible agent login
`sender_type`	No	Sender type: 'agent', 'system', 'customer' (default: 'agent')
`article_body`	No	Body for a new article to add
`pending_time`	No	Pending time for pending states (YYYY-MM-DD HH:MM:SS)
`customer_user`	No	Change customer user
`article_subject`	No	Subject for a new article to add
`article_content_type`	No	Article content type (default: 'text/plain; charset=utf-8')
`communication_channel`	No	Communication channel: 'Email', 'Phone', 'Internal' (default: 'Internal')

TDQS

B3.1/5.0

Behavior2/5

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

Without annotations, the description must disclose behavioral traits. It indicates mutation ('update') and optional article addition but does not clarify whether updates are partial or full replacements, nor mention permissions or side effects. The behavior around pending_time and state interactions is not explained.

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 main action and resource. It is not overly long, but it could be restructured to include guidelines more efficiently.

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 complexity (16 parameters, no annotations, no output schema), the description is incomplete. It lacks details on default values, partial update behavior, and differentiation from siblings. The tool would benefit from a more complete description.

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%, so the descriptions of parameters are already provided. The tool description lists some parameter categories ('state, queue, priority, owner, etc.') but does not add meaningful constraints or relationships beyond the schema. Baseline 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 verb 'Update' and the resource 'existing Otobo ticket', listing specific fields (state, queue, priority, owner, etc.) and adding that it optionally adds a new article. This distinguishes it from siblings like create_ticket and close_ticket.

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 is provided on when to use this tool versus alternatives like add_note or close_ticket. The description only states what it does, without context about when to choose it over siblings.

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. Dates show when Glama detected each change.

10 tool updatesv1.0.0Jul 12, 2026
- First observedadd_note
- First observedclose_ticket
- First observedcreate_ticket
- First observedget_ticket
- First observedget_ticket_history
- First observedlist_priorities
- First observedlist_queues
- First observedlist_states
- First observedsearch_tickets
- First observedupdate_ticket

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct operation on OTOBO tickets or metadata (priorities, queues, states), with no overlapping functionality. For example, add_note is clearly for internal notes vs. closing, while get_ticket_history is separate from get_ticket.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_ticket, list_priorities, close_ticket). No mixing of styles or ambiguous verbs.

Tool Count5/5

10 tools is a well-scoped number for a ticket system, covering creation, retrieval, update, closing, history, and listing of metadata. Each tool earns its place without redundancy.

Completeness4/5

The set covers the main ticket lifecycle (create, read, update, close) and essential lookups (queues, states, priorities). Missing delete or archive operations, but those are often omitted in ticket systems for safety.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
Bitrix24 BOAuth
io.github.bitrix24
MCP server enabling AI agents to manage Bitrix24 features via standardized protocol
ERP Systems Project Management Communication
2
inbrix
ai.inbrix
AI-native helpdesk hosted in Germany: tickets, replies, KPIs and knowledge base over MCP.
1

Related MCP Servers

GLPI MCP
Customer Support Knowledge & Memory
svtica
A
license
B
quality
C
maintenance
MCP server allowing an AI assistant to interact directly with your GLPI instance via its REST API, enabling ticket management, knowledge base operations, and statistics.
Updated 4 days ago (2026-09-02 18:03 UTC)
40
4
-
tickiti-mcpofficial
Customer Support Communication
tickiti
A
license
B
quality
B
maintenance
An MCP server that exposes the Tickiti helpdesk API to AI assistants, enabling ticket management and helpdesk operations via natural language.
Updated a month ago (2026-07-27 12:10 UTC)
11
MIT
freshservice-mcp
Customer Support CRM
mchluba
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI assistants to interact with Freshservice service desk, supporting ticket search, retrieval, and creation via a configurable, Docker-first deployment.
Updated 2 months ago (2026-07-14 15:00 UTC)
MIT
soporte-ti-mcp
Customer Support Search
raulperez0798
F
license
Not graded
quality
B
maintenance
MCP server that provides IT support tools to search known incidents, check ticket status, and create ticket drafts, enabling an AI assistant to help users with IT support queries.
Updated a month ago (2026-08-08 17:16 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/domnussbaum/otobo-mcp'

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

mcp-otobo

Features

Prerequisites

Installation

Configuration

Available Tools

Core Ticket Operations

History

Metadata

Convenience

Integration Examples

Claude Desktop

Claude Code

Cursor

Windsurf

ChatGPT / OpenAI (via MCP Bridge)

Codex CLI

Gemini CLI

Generic MCP Client

Otobo Setup

Step 1: Create a Web Service

Step 2: Add Operations

Step 3: Configure Transport & Route Mapping

Step 4: Create an API Agent

Step 5: Verify

Troubleshooting

"Missing required environment variable"

"Otobo API error (HTTP 403)"

"Otobo API error (HTTP 404)"

"Otobo API error (HTTP 500)"

Connection Issues

"No tickets found" for list_queues/list_states/list_priorities

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

tickiti-mcpofficial

Latest Blog Posts

MCP directory API