Critical failure: tool definitions are NOT visible in source code. Tools are loaded from an external JSON file (src/tools.json) that is synced from a remote Hostodo MCP endpoint via scripts/sync-tools.mjs. The actual tool schemas, descriptions, and parameter definitions cannot be inspected here, only tool NAMES are inferred from test/smoke.mjs. This server is a transparent proxy that DOES NOT define its own tools.
Tool definitions not present in source code. All 9 tools are loaded from external src/tools.json, which is auto-generated by syncing from a remote Hostodo MCP endpoint (https://api.hostodo.com/mcp). Tool schemas, descriptions, parameter types, and constraints are completely inaccessible for evaluation.
CRITICAL: Do not delegate tool definitions to a remote endpoint. Define all tool schemas, descriptions, and parameters explicitly in this repository (e.g., in src/tools.json with full schema details, or in a TypeScript definition file). Clients and evaluators need to see the contract statically.
For each tool, add a non-empty description (50-200 chars) explaining WHAT it does, WHEN to use it, and any prerequisites. Example: 'hostodo_list_vms: Retrieves all virtual machines in the account with status and resource usage. Use this to discover available VMs before starting or configuring them.'
Add complete input schemas with JSON Schema types, descriptions, required fields, enums, and constraints. Example: 'hostodo_start_vm_command': { parameters: { type: 'object', properties: { vm_id: { type: 'string', description: 'UUID of the VM to start' } }, required: ['vm_id'] } }
Document output schemas for each tool. Specify the structure (object vs array), field types, and required fields. Example: 'hostodo_list_vms returns an array of VM objects with id (string), name (string), status (enum: running|stopped|suspended), and metrics (object with cpu_percent, memory_gb_used).'
Add error handling to proxyToolCall() in src/index.js. Catch network timeouts, malformed responses, and permission errors separately. Return actionable guidance: 'VM not found. Use hostodo_list_vms to see available VMs.' instead of 'HTTP 404'.
Implement response filtering in src/index.js. Strip irrelevant metadata, pagination internals, and internal IDs. Return only fields agents need (name, status, key identifiers). This reduces token count and improves clarity.
No error handling guidance in code. src/index.js proxies tool calls to remote Hostodo MCP endpoint and returns raw errors. No recovery hints (e.g., 'try search_users first'), no error classification (retryable vs user-fixable), and error messages are often HTTP status codes with no actionable next steps.
No output schema documentation. src/index.js returns whatever the remote Hostodo endpoint returns, with no documentation of return structure, field types, or pagination. Agents cannot plan downstream calls or extract relevant data reliably.
For write tools (hostodo_start_vm_command, hostodo_install_artifact, hostodo_create_ticket, hostodo_add_ssh_key), add a 'dry_run' or 'confirm' parameter to prevent accidental execution. Document that these operations are destructive.
If list tools return more than 50 items, enforce pagination with limit and offset parameters. Document the pagination strategy in the tool description.
Create a mapping document showing which tools can be chained together. Example: 'hostodo_list_vms returns vm_id, which you can pass to hostodo_get_vm_metrics or hostodo_start_vm_command.' This guides agent composition.
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to distinguish safe discovery tools from destructive operations. Agents can use these to plan safer sequences.