List all SD-WAN configurations.
List all SD-WAN configurations.
Args: settings: Application settings
Returns: List of SD-WAN configurations
| Name | Required | Description | Default |
|---|---|---|---|
| controller | No | Controller to run against (see list_controllers). Defaults to the controller chosen with select_controller, then the server default. |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.6.0Input schema / properties / controllerAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Controller to run against (see list_controllers). Defaults to the controller chosen with select_controller, then the server default."
+}v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no note on read-only safety, whether the active controller must be selected first, pagination behavior, or scoping. It only restates the verb from the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short, but the Args/Returns boilerplate is largely wasted: the Returns block duplicates what the output schema already provides, and the Args block lists a non-existent parameter. Front-loading on the purpose line is fine, but the rest does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, output schema present), so the missing return-value documentation is not a gap. However, it omits controller-selection behavior and any sibling routing, which are the two things an agent most needs here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents its single 'controller' parameter at 100% coverage, but the description instead documents a phantom parameter called 'settings: Application settings' that does not exist in the schema. This active mismatch is more harmful than silence, since it could mislead the agent about what arguments are accepted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List all SD-WAN configurations'), so an agent immediately knows it is a read/collection operation. It does not, however, distinguish itself from close siblings like get_sdwan_config or get_sdwan_config_status, which an agent could easily confuse with it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance at all, and the tool sits among three SD-WAN-related siblings (get_sdwan_config, get_sdwan_config_status). Nothing tells the agent whether to call this to enumerate configs versus fetching a single named config.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.