fios-mcp

Overview Schema Source Related Servers Discussions Admin

apply_desired_state

Idempotent

Applies a desired-state TOML file item by item to a Fios router, previewing changes by default and validating each confirmed entry with read-back, stopping at the first failure.

Instructions

Apply a desired-state TOML file item by item (never removes extra entries).

Without confirm, returns the plan. With confirm, applies each item through the same validation and read-back as the individual tools, stopping at the first failure.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "apply_desired_state"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes
`confirm`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 5, 2026

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds real behavior beyond the annotations: additive-only semantics ('never removes extra entries'), dry-run default, per-item validation and read-back, and fail-fast on the first error. However, with annotations already declaring readOnlyHint=false, idempotentHint=true and destructiveHint=false, the key remaining gap is whether items applied before a failure persist (partial state), which the description implies but never states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core behavior and the non-destructive constraint, then the confirm-mode mechanics. Almost no waste; the parenthetical could be a clause, but the structure is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a bulk mutation tool, the description covers dry-run, validation, fail-fast, and additive-only semantics, and an output schema exists so return values need not be described. The one unresolved point for correct invocation is the state left behind after a mid-run failure, and no guidance is given on file format expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the load. It fully explains confirm (plan vs apply) and hints that path points to a TOML file, but adds no detail on path resolution, expected file layout, or how items are keyed. One of two parameters is well covered, the other only vaguely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: applies a desired-state TOML file item by item, with an explicit scope note that it never removes extra entries. It is clearly distinguished from single-object setters in the sibling list, but it never names check_desired_state, which is the closest sibling and also produces a plan, so the boundary between the two is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear use-mode split: omit confirm to get a plan, include confirm to actually apply. That is direct guidance for the main decision an agent faces. It stops short of naming alternatives such as check_desired_state for validation-only flows or the individual set_* tools for single changes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.