Tools

forti-mcp offers four tools. With --read-only only the first two are listed, and calls to the others are refused with a protocol error (Protocol).

Every input schema is strict (additionalProperties: false): an unknown argument is an error, and the message lists the allowed ones. The schemas mirror the engine's requests, which forti-cli shares.

Results

Every tool returns the engine's envelope as structuredContent, and the same JSON as the first text content block. isError is true exactly when ok is false.

1{"ok": true, "data": "...", "meta": {"profile": "home", "resource": "firewall/address", "start": 0, "returned": 50, "next_start": 50}}2{"ok": false, "error": {"code": "not_found", "message": "...", "details": {}}}

The outputSchema of every tool describes this envelope: ok (boolean, required), data, meta (object) and error (object with code and message, and optional details).

Anything the model can correct is a tool result with isError: true, not a protocol error: invalid arguments (code usage, with the failing JSON pointer, e.g. /operations/0/op: must be one of "create", "update", "delete", "action"), and every engine and device error.

Results are bounded by the byte budget (Large results and paging).

Annotations

forti_plan is read-only for the device: it reads the current objects and writes only a local plan file. Every tool also has a title, repeated in its annotations.

forti_discover

"Start here." Profiles, device identity and mode, resource search and resource details.

Everything except capabilities and live: true is answered from the compiled-in catalog. Monitor paths that are not in the catalog can still be read untyped with forti_read.

forti_read

Read configuration (cmdb tables and singletons) or monitor data over the FortiOS REST API.

Each string in filter and fields is 1 to 256 characters. Filter operators are ==, !=, =@, !@, <, <=, > and >=; a comma inside one clause ORs. Attribute names in filter and fields are checked against the catalog.

data is the device's JSON as FortiOS sent it (an object for key and singletons, an array for listings), with secrets replaced by "<redacted>". meta has resource, profile, device (serial, version, build), vdom, and for listings start, returned, next_start, total and truncated as described in Large results and paging, plus redacted (JSON pointers of redacted values, e.g. ["/*/psksecret"]).

forti_plan

Validate a configuration change and store it as a plan, without touching the device.

Each operation:

data has the plan id (pass it to forti_apply as plan_id), digest, kind, created_at, device (profile, host, port, vdom, serial, version), risk, summary, operations (each with its diff and the exact request, wire, secrets redacted), mode, notes, apply (the equivalent forti apply <id> command) and, in guarded mode, approve (forti plan approve <id>).

forti_apply

Execute a stored plan on the live firewall.

Nothing else is accepted: the operations come from the stored plan. The outcome follows the profile's mode (Workflow):

On success, data has status: "applied", plan_id, digest, operations (per-operation status: verified, applied_unverified, failed, outcome_unknown or not_attempted), the numbers verified and applied_unverified, rollback (the generated rollback plan, with its plan_id), backup for critical plans, and audit_error if the audit record could not be written. partial_failure, outcome_unknown and management_connectivity_lost carry the same record in error.details.