Loading ToolBench
MCP server for interacting with Check Point Firewall Management API
This server has significant gaps in definition quality. While it has 3 tools with basic descriptions, the input schemas are severely incomplete, parameter descriptions are missing or generic, and there is no output schema documentation. Tool naming is reasonable (verb_noun pattern), but the lack of detailed schema information and parameter guidance makes it difficult for LLMs to use these tools correctly. The server handles secrets (credentials) at the config level rather than as parameters, which is good, but the overall definition quality falls well below production standards.
Adds a given IP address as a Host object and adds it to predefined groups on the Check Point Firewall Management Server.
Logs in to the Check Point Management API using either: - An API Key, or - Username and Password
Retrieves details of a specific Check Point Firewall Management Server object by name or UID.
checkpoint_login has NO input schema visible in the source code. The @server.tool() decorator shows no Input parameter, and the docstring does not document any input parameters. Per HARD SCORING RULES, schema score must be 0.
block_ip and get_object_details have partial input schemas (some fields present) but lack critical metadata. block_ip is missing type declarations for the reason parameter beyond 'string'. get_object_details has three parameters (object_name, object_uid, object_type) but no enum constraints or validation guidance for object_type values (e.g., 'host', 'group', 'network').
Parameter descriptions are generic and lack actionable constraints. block_ip's reason parameter says 'A description of why the IP is being blocked. Defaults to "Blocked by AI agent".' but does not explain max length, format, or any constraints. get_object_details' object_type parameter has no enum constraint or list of valid values, LLMs must guess whether 'Host' or 'host', 'Group' or 'group', etc. are correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
No output schema documentation for any tool. LLMs cannot predict what fields the response will contain or what type each field has. block_ip returns a dict with 'success', 'message', 'host_object_name', 'groups_updated', none of this is documented. checkpoint_login returns success/message/session_id, not documented.
Error responses lack recovery guidance. checkpoint_login returns raw API error messages like 'Authentication failed. Status Code: 401. Response: ...' without telling the LLM what to do next (retry? ask user for credentials? use API key instead?). block_ip silently handles 'host already exists' errors, which may confuse the agent about what was actually done. Per pattern:recovery-guide, error responses must tell the LLM what to do next.
checkpoint_login uses a global session_id variable, creating statefulness. The function checks 'if session_id is None' and updates a module-level variable. This violates stateless request handling and could cause issues in multi-request or concurrent scenarios. Per MCP spec 2026-07-28, protocol should be stateless, session state should not rely on mutable globals.
No confirmation or dry-run for destructive operations. block_ip adds hosts to firewall groups (DESTRUCTIVE risk) with no confirmation step. Per pattern:confirmation-request, irreversible operations should support a dry-run or confirmation. An agent could accidentally block critical infrastructure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server declares 'Risk: READ_ONLY', 'Risk: WRITE', 'Risk: DESTRUCTIVE' in the feature comment but does not encode these in the tool schema itself. Per current MCP spec (2026-07-28), tools should use tool annotations to signal operation type to clients.