HaloPSA MCP server with decision tree architecture for Claude. Provides tools for interacting with the HaloPSA API across multiple domains: tickets, clients, assets, agents, and invoices.
The HaloPSA MCP server provides 19 well-organized tools with consistent naming conventions, comprehensive input schemas, and structured outputs. The tool architecture follows a flat, domain-based pattern with clear domain navigation. Most tools have adequate descriptions (100+ chars) and properly typed parameters with enums where appropriate. However, there are gaps in output documentation, limited error recovery guidance, and some parameter descriptions lack specificity about constraints and formats. The server demonstrates solid mid-tier quality with domain coverage (tickets, clients, assets, agents, invoices) but falls short of A-grade due to incomplete documentation of response schemas and missing actionable error messages.
Get technician details by ID
List technicians
Get asset details by ID
List configuration items with optional filters
List asset types
Search assets by inventory number and key fields
Create company
Output schemas not documented in tool definitions. While input parameters are clearly defined with proper JSON Schema, the response structure for each tool is not visible in the registered tool definitions. LLMs cannot plan downstream operations or extract specific fields without knowing what data will be returned.
Parameter descriptions lack specificity about constraints and formats. For example, 'limit' parameters say 'Maximum number of results (default: 50)' but do not specify minimum values, maximum bounds, or whether negative values are allowed. Date parameters (invoice_date_start, invoice_date_end) only hint at YYYY-MM-DD format without explicitly stating it as a constraint. LLMs may pass invalid values without clear guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
Get company details by ID
List companies
Search companies by name
Get invoice details by ID
List invoices with optional filters by client, status, or date range
Discover available HaloPSA tools by domain. Returns tool names and descriptions for the selected domain. All tools are callable at any time — this is a help/discovery aid, not a prerequisite.
Show credentials status and available domains
List teams
Create a new ticket
Get ticket details by ID
List tickets with filters
Update an existing ticket
No output schema documentation or structured response examples. The code shows tools are registered without 'outputSchema' properties. Without documented return types, LLMs cannot reliably extract chaining IDs or understand the shape of paginated results. This forces agents to call tools blindly and guess field names.
Minimal error recovery guidance. Tool descriptions do not explain what to do when a call fails (e.g., 'If ticket not found, call halopsa_tickets_search first' or 'Retryable errors: rate limit, timeout'). Agents have no direction on alternative paths or self-correction strategies.
halopsa_status description is vague. 'Show credentials status and available domains' does not explain what 'status' means or what information will be returned. Is it checking if credentials are valid? Returning a list of available domains? The description should clarify the output and use case.
No tool annotations for destructiveness. halopsa_tickets_create, halopsa_tickets_update, and halopsa_clients_create are write operations but lack toolAnnotations with 'destructiveHint' or equivalent markers. Agents cannot distinguish safe read-only tools from operations with side effects without explicit metadata.
Pagination not fully specified. List tools accept a 'limit' parameter but do not document offset, cursor, or how to retrieve next pages. No documentation of whether responses include a 'total_count' or 'next_cursor' for chaining. Large result sets may exceed context limits without proper pagination structure.
Parameters accept numeric IDs (client_id, agent_id, ticket_id) but do not accept human-friendly identifiers. Users typically say 'create ticket for Company X' but the tool requires a numeric client_id, forcing an extra lookup call. No guidance on resolving names to IDs within the tool.