This MCP server provides 24 tools covering Tactical RMM agent management, scripts, software, and audit operations. Tool naming is generally clear and verb-based (list_, get_, update_, deploy_, run_, etc.), but several critical gaps exist: (1) parameter descriptions are present but often generic (e.g., 'The agent ID' without specifying format or how to obtain it); (2) output schemas are entirely undocumented, the code shows tool definitions with inputSchema but no mention of return types or response structures; (3) error handling guidance is absent from descriptions, leaving agents without recovery paths; (4) several tools combine multiple operations or have unclear boundaries (e.g., trmm_run_script vs trmm_run_command, both execute code but on different targets, the distinction is not obviously explained); (5) no documentation of which tools are idempotent, retryable, or destructive beyond basic Risk tags (WRITE, DESTRUCTIVE); (6) many parameters like 'agent_id', 'script_path', and 'client_name' lack detail on expected format, length, or validation rules, descriptions assume the LLM knows what a 'script path' looks like relative to the scripts directory. The code shows proper JSON Schema structure for inputs (types, enums, defaults) but the descriptions do not guide LLMs on how to construct complex payloads (e.g., the 'custom_fields' array in trmm_update_agent_custom_fields requires nested objects, the description says 'Array of custom field updates' but does not explain the structure). Output handling is entirely implicit; tools like trmm_list_agents return TextContent but the actual JSON response format is unknown. The server follows basic MCP patterns (tool registration, call routing, async handlers) but lacks production-grade depth in descriptions and error paths.

• Add documented output schemas to every tool. For list_ tools, specify: return type (array or paginated object), field names, field types, and example structure. For get_ tools, specify the object structure. Use JSON Schema definitions or explicit descriptions like 'Returns an array of agent objects with fields: agent_id (string), hostname (string), status (string), last_seen (ISO 8601 datetime).'
• Enhance parameter descriptions with format and constraint details. Instead of 'The agent ID to retrieve', write: 'The agent ID (string, obtained from trmm_list_agents). Example: agent-12345. No wildcard patterns supported.'
• Add error recovery guidance to tool descriptions. For each destructive or complex tool, include: 'If the agent is offline, this call will fail with error "agent_offline". Retry after confirming the agent is online via trmm_list_agents, or consider using trmm_deploy_local_script with a scheduled task.' Example for trmm_run_script: 'Errors: agent_offline (retryable), script_not_found (check trmm_list_library_scripts), timeout (increase timeout param), permission_denied (ask user to grant script execution rights).'
• Document which tools are idempotent. Add to tool descriptions: 'This tool is idempotent, calling it multiple times with the same parameters produces the same result without side effects.' or 'This tool has side effects, calling it multiple times will [duplicate records / execute the script multiple times].'
• Clarify parameter interdependencies. For trmm_update_agent_custom_fields, explain: 'custom_fields array: each object must have field (integer, obtain valid IDs from trmm_list_custom_fields) and string_value (string). Note: all field types accept string_value regardless of their type, the server will validate and convert types based on field definition.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry