Skip to main content
Glama
Sign In
Inserve-MCP

Inserve-MCP

Official
by inserveit
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Tickets zoeken

search_tickets
Read-onlyIdempotent

Find support tickets by free text, status, priority, company, or operator, with newest results first and paginated output.

Instructions

Search tickets, newest first. Filter on free text (reference, subject), status, priority, company or operator. Use list_lookups to find status, priority and operator ids. The priority filter cannot be combined with a free text query.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_tickets"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPaginanummer.
queryNoFree text search on reference and subject.
per_pageNoAantal resultaten per pagina (max 100).
company_idNoOnly tickets of this company.
status_idsNoOnly tickets with one of these statuses.
operator_idNoOnly tickets assigned to this operator.
priority_idsNoOnly tickets with one of these priorities. Not combinable with query.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.4

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the description's added value is the disclosure that results are returned newest-first and that one filter combination is invalid. That constraint is a genuine behavioral gotcha an agent would otherwise discover only by failing. It does not say anything about result counts, total hits, or pagination exhaustion.

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?

Three short sentences, front-loaded with purpose, then filters, then the id-resolution hint and the combination caveat. No filler and nothing buried at the end.

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?

Seven optional parameters, full schema coverage, and no output schema, so the description only needs to cover selection and invocation — which it largely does, including ordering and the filter conflict. The one remaining gap is that nothing is said about what a result contains or how total/page boundaries behave, though the absence of an output schema makes this a minor omission.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: how to obtain the raw integer ids via list_lookups, and that query searches reference and subject specifically. The combination restriction is repeated from the priority_ids schema text, so part of the sentence is redundant.

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?

Opens with a specific verb+resource and adds the sort order ('Search tickets, newest first') plus the full list of filterable dimensions, which separates it from get_ticket (single ticket) and search_companies/search_contacts. It stops short of explicitly naming those siblings as alternatives, so differentiation is inferred from the resource noun rather than stated.

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?

Gives concrete usage context: filter by free text, status, priority, company or operator, and directs the agent to list_lookups to resolve status/priority/operator ids. It also states a real exclusion — priority filter cannot be combined with a free text query. No explicit 'when not to use / use X instead' for the retrieval siblings, hence 4 rather than 5.

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

Deploy Server

Other Tools