Loading ToolBench
MCP server for Forward Networks providing network discovery, NQE queries, path searches, configuration search/diff, snapshots, locations, and knowledge-graph memory capabilities
Forward Networks MCP server demonstrates solid baseline quality with consistent naming conventions, descriptions present across all 31 tools, and reasonable parameter schemas. However, there are significant gaps in schema completeness, output documentation, and error handling guidance. Tool names follow verb_noun patterns well (list_*, create_*, delete_*, search_*, etc.), and descriptions are generally in the 50-150 character range, meeting baseline expectations. Critical issues include: (1) output schemas are undocumented, no tool response structure is specified, making it difficult for LLMs to know what fields to extract; (2) parameter schemas lack comprehensive validation (missing min/max on integers, no enum constraints on categorical fields, minimal format specifications); (3) error handling provides no recovery guidance; (4) several tools accept vague 'options' parameters with only generic descriptions; (5) complex parameter relationships (e.g., pagination 'limit' vs 'all_results' mutual behavior) are not clearly documented. Tools like 'run_nqe_query_by_string' and 'search_paths' accept open-ended 'options' objects without specifying valid fields. The 'all_results' pattern appears in multiple tools but lacks clarity on in-memory aggregation side effects.
Create a new geographic location in a network with coordinates and optional city/region information
Create or update multiple locations in bulk using PATCH operation
Create a new network with the specified name
Delete a location from a network
Delete a network by its ID
Delete a snapshot by ID
Compare configurations between two snapshots
Get the currently set default network ID
Output schemas completely undocumented across all 31 tools. No tool specifies what fields it returns, their types, or structure. LLMs cannot determine what data to extract from responses or plan downstream tool compositions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Get basic device information including names and platforms
Get detailed hardware information for devices
Retrieve geographic locations of devices in a network with optional result aggregation
Get hardware support information and status
Get the most recent snapshot for a network
Get operating system support information and status
Populate and update the SQLite database with network metadata and enhanced query information
Initialize the NQE query index for AI-powered semantic search
List devices in a network with pagination support
List geographic locations defined in a network with pagination and optional result aggregation
List all networks accessible to the authenticated user with pagination support
List available NQE queries from the query library with optional directory filtering
List network snapshots with pagination support and optional result aggregation
Execute an NQE query by ID from the NQE Library with optional pagination and result aggregation
Execute an NQE (Network Query Engine) query using source code
Search network device configurations by pattern
AI-powered semantic search across NQE query library using natural language
Search for network paths between source and destination with various filtering options
Perform multiple path searches in a single request for efficiency
Set the default network for subsequent tool calls
Map devices to geographic locations
Update an existing location with new coordinates and geographic information
Update network properties including name and description
Vague 'options' object parameters with no field documentation. Tools 'run_nqe_query_by_string', 'run_nqe_query_by_id', 'search_paths', 'get_device_basic_info', 'get_device_hardware', 'get_hardware_support', 'get_os_support' accept open-ended 'options' dicts. Description only says 'Query options like limit, offset, sorting, etc.', LLMs cannot know valid field names or expected types.
Undocumented parameter relationships. Multiple tools accept both 'limit'/'offset' pagination AND an 'all_results' boolean flag. When 'all_results=true', pagination is ignored and results are aggregated in-memory. This behavior is never explicitly stated, only implicit in scattered descriptions.
No input validation constraints on numeric parameters. 'limit' and 'offset' appear in many tools but lack min/max bounds, units, or behavior at boundary values. Rubric baseline: A+ tools specify min/max (e.g., 'limit: 1 - 100').
No error handling or recovery guidance. No tool documents what errors might occur (e.g., 'network not found', 'permission denied', 'invalid query syntax') or how LLMs should respond.
Destructive tools lack confirmation/dry-run patterns. 'delete_network', 'delete_snapshot', 'delete_location' offer no confirmation step or dry-run mode.
Non-idempotent state mutation tools lack idempotency keys or idempotentHint annotations. Tools like 'create_network', 'create_location' do not declare whether re-calling with identical params is safe. LLMs may retry on ambiguous failures, risking duplicates.
Missing tool annotations (destructiveHint, readOnlyHint, idempotentHint). Server defines tools with risk categories (READ_ONLY, WRITE, DESTRUCTIVE) in the metadata but does not expose these as MCP tool annotations. LLMs cannot infer operation safety from tool definitions alone.
Pagination results may silently truncate without clear signaling. Tools like 'list_networks' default limit=25, max=100. If a network has 500 devices and the user queries 'list all devices', they get 25 and must know to loop. No 'has_more' flag or 'total_count' documented.
Parameter dependencies undocumented. E.g., 'search_paths' accepts both 'src_ip' (optional) and 'dst_ip' (required?), but the interaction is unclear. Are both needed? What if only 'dst_ip' is provided? Documentation must clarify.