Description
get_cwan_routes fails with an unhandled error (Error calling tool 'get_cwan_routes': 'Destinations') when called against a segment whose route table contains a blackhole route with target: null, while working correctly for segments with only active/propagated routes.
Environment
awslabs.aws-network-mcp-server version: 0.0.13 (via uvx awslabs.aws-network-mcp-server@latest)
- MCP client: Claude Code
- Region: eu-west-1
Steps to reproduce
- Call
get_all_cwan_routes(core_network_id="<core-network-id>", cloudwan_region="eu-west-1", profile_name="<profile>") and find a segment whose routes include an entry shaped like:
{"destination": "0.0.0.0/0", "target": null, "type": "static", "state": "blackhole"}
(confirmed via get_all_cwan_routes in this account — the segment in question has exactly two such routes, 0.0.0.0/0 and ::/0, both blackhole with target: null.)
- Call
get_cwan_routes(core_network_id="<core-network-id>", region="eu-west-1", segment="<that-segment-name>", profile_name="<profile>") on the same segment.
- Compare against a segment with only active/propagated routes (works fine), and a segment with zero routes at all (also works fine, returns
"No network routes found with the given parameters.").
Actual behavior
Error calling tool 'get_cwan_routes': 'Destinations'
Confirmed via two data points: a segment with blackhole/null-target routes fails; a segment with zero routes succeeds with a clean "no routes" message; multiple segments with active/propagated routes all succeed normally. The differentiator appears to be specifically the presence of a blackhole route with a null target, not segment isolation or route count.
Expected behavior
The tool should return blackhole routes the same way get_all_cwan_routes does (with target: null, state: "blackhole") rather than throwing an unhandled error.
Additional context
The error message (bare 'Destinations') suggests the per-segment code path does a route['Destinations'] or similar lookup on the raw AWS API response shape, and something about blackhole/no-target route entries doesn't match the expected shape — while get_all_cwan_routes clearly already handles this shape correctly (it returns target: null cleanly), suggesting the two tools use different parsing logic for the same underlying GetNetworkRoutes API response.
Description
get_cwan_routesfails with an unhandled error (Error calling tool 'get_cwan_routes': 'Destinations') when called against a segment whose route table contains a blackhole route withtarget: null, while working correctly for segments with only active/propagated routes.Environment
awslabs.aws-network-mcp-serverversion: 0.0.13 (viauvx awslabs.aws-network-mcp-server@latest)Steps to reproduce
get_all_cwan_routes(core_network_id="<core-network-id>", cloudwan_region="eu-west-1", profile_name="<profile>")and find a segment whose routes include an entry shaped like:{"destination": "0.0.0.0/0", "target": null, "type": "static", "state": "blackhole"}get_all_cwan_routesin this account — the segment in question has exactly two such routes,0.0.0.0/0and::/0, both blackhole withtarget: null.)get_cwan_routes(core_network_id="<core-network-id>", region="eu-west-1", segment="<that-segment-name>", profile_name="<profile>")on the same segment."No network routes found with the given parameters.").Actual behavior
Confirmed via two data points: a segment with blackhole/null-target routes fails; a segment with zero routes succeeds with a clean "no routes" message; multiple segments with active/propagated routes all succeed normally. The differentiator appears to be specifically the presence of a blackhole route with a null target, not segment isolation or route count.
Expected behavior
The tool should return blackhole routes the same way
get_all_cwan_routesdoes (withtarget: null,state: "blackhole") rather than throwing an unhandled error.Additional context
The error message (bare
'Destinations') suggests the per-segment code path does aroute['Destinations']or similar lookup on the raw AWS API response shape, and something about blackhole/no-target route entries doesn't match the expected shape — whileget_all_cwan_routesclearly already handles this shape correctly (it returnstarget: nullcleanly), suggesting the two tools use different parsing logic for the same underlyingGetNetworkRoutesAPI response.