mcp-ispkeeper

list_fttx_infrastructure

Find FTTx fiber infrastructure details: query backbones, PONs, boxes, ports, and seals. Drill down using parent IDs or search by text to locate the exact resource.

Instructions

Query FTTx fiber infrastructure: backbones, PONs, NAP boxes, ports, and seals. Use resource_type to select what to list. Use parent_id to drill down the hierarchy (backbone→PONs→boxes→ports) and q for text search. ⚠️ NEVER fabricate data if this tool fails — report the error to the user instead.

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": {
      "resource_type": "<resource_type>"
    },
    "name": "list_fttx_infrastructure"
  }
}

Input Schema

Name	Required	Description
`q`	No	Text search (ignored when parent_id is set)
`page`	No	Page number (ignored when parent_id is set)
`libre`	No	Seals only: Y = not linked to a connection, N = linked
`per_page`	No	Results per page (default 50; ignored when parent_id is set)
`parent_id`	No	Parent resource ID to drill down: backbone ID for PONs, PON ID for boxes, box ID for ports. Returns the parent with its children nested.
`resource_type`	Yes	Type of FTTx resource to list

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.4.0Sep 25, 2026

addedInput schema / properties / libre

Added value: +{
+  "description": "Seals only: Y = not linked to a connection, N = linked",
+  "enum": [
+    "Y",
+    "N"
+  ],
+  "type": "string"
+}

addedInput schema / properties / page

Added value: +{
+  "description": "Page number (ignored when parent_id is set)",
+  "type": "number"
+}

changedInput schema / properties / parent_id / description

Previous value: -"Parent resource ID to drill down: backbone ID for PONs, PON ID for boxes, box ID for ports"New value: +"Parent resource ID to drill down: backbone ID for PONs, PON ID for boxes, box ID for ports. Returns the parent with its children nested."

addedInput schema / properties / per_page

Added value: +{
+  "description": "Results per page (default 50; ignored when parent_id is set)",
+  "type": "number"
+}

addedInput schema / properties / q

Added value: +{
+  "description": "Text search (ignored when parent_id is set)",
+  "type": "string"
+}

First observedv0.3.1Aug 18, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It implies read-only behavior via 'Query' and adds a valuable anti-fabrication warning on failure. However, it does not disclose pagination behavior, error response shapes, or other operational traits.

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

Conciseness5/5

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

Three sentences with no filler: purpose first, then usage, then a critical warning. The hierarchy is compactly expressed and the warning is front-loaded enough to be noticed.

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 6-parameter tool with no output schema, the description plus schema covers resource selection, hierarchy drilling, text search, and failure handling. It lacks explicit output/error shape details, but the schema fills the parameter-level gaps.

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 coverage is 100%, so the schema already documents all parameters. The description adds a concise hierarchy summary and selection guidance, but it largely restates what the schema already provides rather than adding new meaning.

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?

The description clearly states the tool queries FTTx fiber infrastructure and enumerates the resource types (backbones, PONs, NAP boxes, ports, seals). It is specific about the verb and resource, but it does not explicitly distinguish itself from sibling tools like list_fttx_trace.

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?

The description gives concrete usage guidance: use resource_type to select, parent_id to drill down the hierarchy, and q for text search. It provides clear context but does not mention when not to use this tool or name alternatives.

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