MCP server for querying Cisco Firewall Management Center (FMC) access and prefilter policies, supporting network and identity indicator searches
The server defines 4 read-only tools with generally clear names and descriptions. All tools have descriptions and documented input schemas with parameter types. However, there are significant gaps: (1) output schemas are undocumented, the rubric requires documenting what fields agents should expect in responses; (2) parameter descriptions lack actionable constraints (ranges, formats, examples of valid values); (3) error handling is generic (returns JSON error objects but doesn't guide recovery or classify errors as retryable/fatal); (4) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only; (5) parameters like 'indicator_type' have enums but lack examples or clarification on when to use 'auto' vs explicit types. The tools are well-named with verb-noun structure (find_, list_, search_), and naming is consistent and clear. Naming alone accounts for the fair score; schema and error guidance pull it down.
Search a specific access policy for rules referencing an IP/CIDR/FQDN indicator.
Resolve an FTD/HA/cluster target to its policies and search them for the indicator.
Describe available FMC profiles from env mode (single) or profile registry (multi).
Run FMC-wide or policy-scoped rule searches with network/identity indicators and filters.
No documented output schemas for any tool. Agents cannot plan downstream calls or extract the right fields without knowing the response structure. The rubric requires 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.'
Parameter descriptions lack actionable constraints. 'query' in find_rules_by_ip_or_fqdn says it accepts 'IP address, CIDR network, or FQDN' but does not specify format, length, or example values. 'max_results' and 'max_policies' are numeric but lack min/max bounds. The rubric specifies: 'Describe the expected format, range, and allowed values directly in the parameter description.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Error handling does not classify errors or guide recovery. The tools catch exceptions and return JSON error objects (e.g., {'error': {'category': 'INVALID_INDICATOR', 'message': ...}}) but do not tell the agent whether the error is retryable, user-fixable, or fatal. The rubric requires: 'Error responses must tell the LLM what to do next. A raw error code or stack trace gives the agent nothing to act on.'
No tool annotations despite all tools being read-only. Tools should include readOnlyHint=true to signal to agents and UIs that these tools have no side effects. This enables safe auto-retry and parallel execution strategies.
Parameter 'indicator_type' in find_rules_for_target and search_access_rules has enum values ('auto', 'ip', 'subnet', 'fqdn', 'sgt', 'realm_user', 'realm_group') but the description does not explain when to use 'auto' vs explicit types, or what SGT and realm types mean in this context. LLMs will guess and pass incorrect values.
search_access_rules has complex parameter relationships (scope='policy' requires policy_name or policy_id; scope='fmc' uses policy_name_contains and max_policies) but these dependencies are not documented in parameter descriptions. The rubric states: 'When one parameter's valid values depend on another, document this in both parameter descriptions.'