MCP Server

The FireMon MCP server exposes your FireMon environment to your own AI system. Connect any client that speaks MCP over Streamable HTTP, and your model can query firewall rules, devices, network paths, compliance data, and Policy Planner workflows directly.

Your model does the reasoning and writes the queries. FireMon serves the data and enforces your existing permissions.

There are two levels of access:

• Without credentials you get one tool, search_documentation, which searches FireMon product documentation. Nothing to set up.
• With credentials you get the full tool set against your own environment: firewall rules, devices, device groups, network paths, compliance controls, Policy Planner workflows, metrics, and arbitrary SIQL queries.

Endpoint

https://4c5y9c4cyg.execute-api.us-west-2.amazonaws.com/mcp

Documentation search, no credentials

Any MCP client can reach search_documentation without authenticating. It searches FireMon product documentation and returns the closest matching passages with their source URLs:

curl -s -X POST 'https://4c5y9c4cyg.execute-api.us-west-2.amazonaws.com/mcp' \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search_documentation","arguments":{"question":"How do I add a device group?"}}}'

The accept header must list both content types. Leave one out and the request is rejected before it reaches any tool.

Connecting to your own data

You need two credentials.

Your API key. The Insights API key your on-premise FireMon installation already holds, sent in the x-api-key header on every request. Insights never stores the key itself, so get it from whoever administers your FireMon installation. Treat it as an administrator credential: it reaches all of your data. Ask for a long-lived one. The key your installation receives when it re-registers expires after 24 hours, so MCP access can work today and return 401 tomorrow. API Keys covers where keys come from, what one authorizes, and how to review and revoke them.

Your SIP user ID. This is the numeric ID Security Manager assigns your user account — not your email address and not your Insights login. Your FireMon administrator can look it up. It has to be a user SIP has already synced to Insights; an ID that hasn't been synced is rejected.

Configure your client

Point your MCP client at the endpoint over Streamable HTTP and set these headers on every request:

Header	Value
x-api-key	Your Insights API key
x-sip-user-id	Your SIP user ID
x-device-group-id	Optional. Sets the default device group for calls that need one.
accept	application/json, text/event-stream — both types, or the request is rejected

The server is stateless: no sessions, no resumability, and responses are always JSON rather than an event stream. Every request stands on its own.

Confirm it works

List the tools you have access to:

curl -s -X POST 'https://4c5y9c4cyg.execute-api.us-west-2.amazonaws.com/mcp' \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'x-sip-user-id: YOUR_SIP_USER_ID' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

A long list means you're authenticated. A single tool means your x-api-key header isn't reaching the server at all. A key that arrives but isn't recognized returns 401 instead, rather than falling back to documentation-only access.

tools/list is also the authoritative reference. It returns the current description and full JSON Schema for every tool, which will always be more current than this page.

Start with your device groups

Most tools are scoped to a device group, and the IDs aren't guessable, so list them first:

curl -s -X POST 'https://4c5y9c4cyg.execute-api.us-west-2.amazonaws.com/mcp' \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'x-sip-user-id: YOUR_SIP_USER_ID' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"list_all_device_groups","arguments":{}}}'

You'll get back each group's id, name, and device counts. Device group 1 is "all devices".

From there you have two ways to set the scope:

• Pass deviceGroupId in the arguments of tools that accept it.
• Send an x-device-group-id header to set the default for every call. If you don't, the default is the first group your user is authorized for.

Either way the group has to be one your SIP user is authorized for, or the call is refused.

The tools

Firewall rules

Tool	What it does	Arguments
count_firewall_rules	Counts rules matching your criteria. Use it for counting and existence checks.	sourceIp, destinationIp, portNumberOrServiceName, actionType (ALLOW/DENY), includeWildcardRules, deviceId, deviceName, deviceGroupId, deviceGroupName — all nullable
search_firewall_rules_by_source	Finds rules by source address only.	sourceIp (required), portNumberOrServiceName, actionType
search_firewall_rules_by_destination	Finds rules by destination address only.	destinationIp (required), portNumberOrServiceName, actionType
list_all_security_rules_by_device	Returns every rule on a device.	deviceId — null for all devices

For source and destination, the literal string PUBLIC_INTERNET matches traffic from or to the internet.

Devices and device groups

Tool	What it does	Arguments
list_all_device_groups	Lists every device group with IDs, names, and counts.	none
list_all_devices	Lists devices in a group.	deviceGroupId
get_device_group_kpi	KPIs for a group: control failures, recently changed devices, rule usage.	kpi (required), id (required)
get_device_kpi	KPIs for one device: control failures, security concern index, config changes, complexity.	kpi (required), deviceId (required)

get_device_group_kpi accepts CONTROL_FAILURES_WITH_HIGHEST_SEVERITY, DEVICES_MOST_RECENTLY_CHANGED, or TOTAL_RULE_USAGE_CHART.

get_device_kpi accepts CONTROL_FAILURES_WITH_HIGHEST_SEVERITY, KPI_AVERAGE_SCI, KPI_TOTAL_CONFIG_CHANGES, or KPI_DEVICE_COMPLEXITY.

Network paths

Tool	What it does	Arguments
get_network_nodeId_for_ip_address	Finds the network node an address sits behind. Always call this first for reachability questions.	ipAddress (required)
test_network_path	Simulates whether a packet gets from A to B.	startNodeId, sourceIpAddress, destinationIpAddress, tcpPort — all required

Answering "can A reach B on port 443?" is a two-step job: get_network_nodeId_for_ip_address for the source, then test_network_path with the node ID it returns. More than one node coming back means the network map couldn't be read cleanly.

Metrics and compliance

Tool	What it does	Arguments
query_metric_data	Current metrics for a group, or a time series for one metric.	queryType (required, deviceGroupMetrics or historicalMetrics), deviceGroupId, metricName, startDate, endDate, interval
get_metrics_summary	Aggregated metrics across a date range.	startDate, endDate, interval (all required), deviceGroupId
get_assessment_stats	Per-control pass/fail counts over a range, with current, start, and prior-period values.	startDate, endDate (both required), deviceGroupId

Dates are epoch milliseconds. interval is day, week, month, or year. Metrics data can be up to 24 hours old; everything else on this page is real-time.

Policy Planner

Tool	What it does	Arguments
list_policy_planner_workflows	Lists workflows and their IDs.	none
get_policy_planner_workflow_tasks	Returns a workflow's stages and configuration, including auto-design settings.	workflowId (required)

To query tickets themselves, use execute_siql_query against /policyplanner/api/siql/ticket/paged-search.

SIQL

SIQL is FireMon's query language. Between them, these two tools reach security rules, devices, device groups, network and service objects, policies, NAT rules, controls, assessments, assets, and Policy Planner tickets.

It's a two-step job: pull the reference for the section you need, then write and run the query. Your own model writes the query on your side. FireMon never sees the request, only the finished query.

SIQL queries aren't limited by the device group header. Neither are list_all_device_groups, list_all_security_rules_by_device, get_device_kpi, or the Policy Planner tools — these run as your SIP user, and Security Manager applies that user's own permissions instead.

Tool	What it does	Arguments
get_siql_reference	Returns SIQL reference documentation by section.	sections (required, array)
execute_siql_query	Runs a SIQL query against a Security Manager or Policy Planner endpoint.	query, endpoint (both required), countType, page, pageSize

Sections available to get_siql_reference: overview, operators, functions, pipes, rule, natrule, device, devicegroup, domain, policy, networkobj, serviceobj, userobj, appobj, profileobj, control, assessment, connection, application, addressbook, scope, scheduleobj, interface, route, asset, ticket, examples. Start with overview if you're new to it.

endpoint must be one of:

/securitymanager/api/siql/addressbook/paged-search
/securitymanager/api/siql/application/paged-search
/securitymanager/api/siql/applicationgroup/paged-search
/securitymanager/api/siql/appobj/paged-search
/securitymanager/api/siql/assessment/paged-search
/securitymanager/api/siql/asset/paged-search
/securitymanager/api/siql/control/paged-search
/securitymanager/api/siql/device/paged-search
/securitymanager/api/siql/devicegroup/paged-search
/securitymanager/api/siql/interface/paged-search
/securitymanager/api/siql/natrule/paged-search
/securitymanager/api/siql/networkobj/paged-search
/securitymanager/api/siql/policy/paged-search
/securitymanager/api/siql/profileobj/paged-search
/securitymanager/api/siql/route/paged-search
/securitymanager/api/siql/scheduleobj/paged-search
/securitymanager/api/siql/scope/paged-search
/securitymanager/api/siql/secrule/paged-search
/securitymanager/api/siql/serviceobj/paged-search
/securitymanager/api/siql/urlmatcher/paged-search
/securitymanager/api/siql/userobj/paged-search
/securitymanager/api/siql/vendortag/paged-search
/securitymanager/api/siql/count
/policyplanner/api/siql/ticket/paged-search

countType is required when using /siql/count — it names the entity being counted, e.g. SECURITYRULE, NATRULE, DEVICE, DEVICEGROUP, NETWORKOBJECT, SERVICEOBJECT, CONTROL, ASSESSMENT, POLICY.

Running a query:

curl -s -X POST 'https://4c5y9c4cyg.execute-api.us-west-2.amazonaws.com/mcp' \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'x-sip-user-id: YOUR_SIP_USER_ID' \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"execute_siql_query","arguments":{"query":"device{active=true}","endpoint":"/securitymanager/api/siql/device/paged-search"}}}'

Product help

Tool	What it does	Arguments
search_documentation	Searches FireMon product documentation.	question (required)
get_sip_ui_navigation	Returns the SIP site map with navigation paths, for answering "where do I find X in the UI?"	none

Limits

Requests time out after 20 seconds. Tools that page through large result sets — list_all_devices, list_all_device_groups, list_all_security_rules_by_device, list_policy_planner_workflows, get_assessment_stats — can hit this on a large environment. If they do, narrow the request: a specific device group, a tighter SIQL query, a smaller pageSize. Retrying the same call unchanged will time out again.

Rate limit is 50 requests per second, bursting to 100, shared across everyone using the server.

Troubleshooting

What you see	What it means	What to do
Only search_documentation in tools/list	Your x-api-key header isn't reaching the server	Check the header name and that your client is actually sending it
401	The key isn't recognized, or it expired	Confirm the key is current. If it worked yesterday and fails today, it was a 24-hour key — get a long-lived one
403 Missing x-sip-user-id header	Key accepted, but no user named	Add the x-sip-user-id header
403 Unknown SIP user	That ID hasn't been synced to Insights	Confirm the ID with your FireMon administrator, and that SIP has synced it
403 SIP user is disabled	The account is disabled in SIP	Re-enable it in Administration > Access
403 SIP user has no authorized device groups	The account has no device group access	Grant device group access in Administration > Access
403 Device group N is not authorized for this user	You asked for a group the user can't see	Use list_all_device_groups to see what's available
406	The accept header is missing a type	Send accept: application/json, text/event-stream
429	Rate limited	Back off and retry
<tool> timed out.	The call exceeded 20 seconds	Narrow the request
Access denied: device group N is not authorized for this user	The deviceGroupId in your arguments isn't one of yours	Check the ID against list_all_device_groups