11 tools with consistent naming (verb_noun pattern: list_, get_, search_, find_) and clear descriptions (50-150 chars, well above 20-char floor). All tools are READ_ONLY, reducing security risk. Input schemas present for all tools with target/vdom parameters properly typed as strings with descriptions. However, output schemas are NOT documented in the source code, critical gap for LLM planning. Parameter descriptions are adequate but lack format constraints (e.g., no regex for IP/MAC in find_device, no enum for vdom). Error handling and recovery guidance absent from visible code. Tool composition is sound (each does one thing), but no pagination support visible despite tools returning potentially large lists (policies, interfaces, address objects).

• Document output schemas for all tools. Example for list_policies: {type: 'object', properties: {policies: {type: 'array', items: {type: 'object', properties: {policy_id: {type: 'integer'}, name: {type: 'string'}, source: {type: 'string'}, destination: {type: 'string'}, action: {type: 'string', enum: ['accept', 'deny']}, ...}}}, total_count: {type: 'integer'}}}
• Add pagination to list_* tools: limit (1-100, default 20), offset (default 0), and total_count in response. Document in tool description: 'Returns up to 20 policies per call. Use offset to paginate.'
• Constrain find_device query parameter: 'IPv4 address (e.g. 192.168.1.1), IPv6 address, MAC address (colon-separated, e.g. aa:bb:cc:dd:ee:ff), or hostname.'
• Add error recovery guidance to all tool descriptions. Example: 'If target is unreachable, call list_targets to verify connectivity. If vdom is invalid, omit the parameter to use the target's default vdom.'
• Document vdom discovery: 'To list available vdoms on a target, call get_system_status and inspect the vdom field. If vdom is omitted, the target's default vdom is used.'