OSPF knowledge base + live device tools MCP server for network operations
YANA defines 8 tools with consistent naming (verb_noun pattern) and complete input schemas. All tools have descriptions and parameters are typed with enums where appropriate. However, descriptions are terse (avg ~40 chars, well below the 194-char baseline), lack context on WHEN to use each tool, and omit recovery guidance. Output schemas are not documented, LLMs cannot predict response structure for chaining. Error handling is absent from visible code. Tools are well-scoped (single responsibility) and read-only, but descriptions need expansion to meet LLM-optimization standards.
Query interface status and configuration from a device
Query OSPF state and configuration from a device
Query routing table and routing policies from a device
Query device operational status and health metrics
Return the device inventory, optionally filtered by CLI style
Retrieve network design intent for a device or the full topology
Search question for the network knowledge base
Output schemas not documented. LLMs cannot predict response structure, breaking tool chaining and forcing exploratory calls.
Descriptions are terse (avg 40 chars vs 194-char baseline). Missing WHEN to use each tool, prerequisites, and what data is returned. Insufficient for LLM tool selection.
No error handling or recovery guidance visible. Tools fail silently or return raw errors without actionable next steps for LLMs.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | <=2025-11-25 | v2 |
Execute traceroute from a device to a destination
Parameter descriptions lack format/constraint details. E.g., 'destination' in traceroute says 'IP address' but does not specify IPv4 vs IPv6, CIDR notation, or validation rules.
No pagination or result-limiting documented. search_knowledge_base accepts top_k (1-10) but other list/query tools may return unbounded results, risking context window exhaustion.