SuzieQ MCP Server
Servidor MCP para SuzieQ
Este proyecto proporciona un servidor de Protocolo de Contexto de Modelo (MCP) que permite que los modelos de lenguaje y otros clientes MCP interactúen con una instancia de observabilidad de red SuzieQ a través de su API REST.
Descripción general
El servidor expone los comandos de SuzieQ como herramientas MCP:
run_suzieq_show: Acceda al comando 'show' para consultar tablas detalladas del estado de la redrun_suzieq_summarize: Acceda al comando 'summarize' para obtener estadísticas agregadas y resúmenes
Estas herramientas permiten a los clientes (como Claude Desktop) consultar varias tablas de estado de red (por ejemplo, interfaces, BGP, rutas) y aplicar filtros, recuperando los resultados directamente de su instancia de SuzieQ.
Related MCP server: OpsLevel MCP
Prerrequisitos
Python: se recomienda la versión 3.8 o superior.
uv: Un instalador y solucionador rápido de paquetes de Python. ( Guía de instalación )
Instancia de SuzieQ: una instancia de SuzieQ en ejecución con su API REST habilitada y accesible.
Punto final y clave de API de SuzieQ: necesita la URL para la API de SuzieQ (por ejemplo,
http://your-suzieq-host:8000/api/v2) y una clave de API válida (access_token).
Instalación y configuración
Instalación mediante herrería
Para instalar suzieq-mcp para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli install @PovedaAqui/suzieq-mcp --client claudeInstalación manual
Obtenga el código: Clone este repositorio o descargue los archivos
main.pyyserver.pyen un directorio de proyecto dedicado.Crear entorno virtual: navegue al directorio de su proyecto en la terminal y cree un entorno virtual usando
uv:uv venvActivar entorno:
En macOS/Linux:
source .venv/bin/activateEn Windows:
GXP4 (debería ver
(.venv)antes de su mensaje)
Instalar dependencias: Instale los paquetes de Python necesarios usando
uv:uv pip install mcp httpx python-dotenvmcp: El SDK del protocolo de contexto de modelo.httpx: un cliente HTTP asincrónico utilizado para comunicarse con la API de SuzieQ.python-dotenv: se utiliza para cargar variables de entorno desde un archivo.envpara la configuración.
Configuración
El servidor necesita el punto final de la API de SuzieQ y su clave API. Use un archivo .env para una configuración segura y sencilla:
Cree un archivo
.env: en la raíz del directorio de su proyecto (el mismo lugar quemain.py), cree un archivo llamado.env.Agregar credenciales: Agregue su punto final y clave de SuzieQ al archivo
.env. Asegúrese de que los valores no estén entre comillas, a menos que formen parte de la clave o el punto final.# .env SUZIEQ_API_ENDPOINT=http://your-suzieq-host:8000/api/v2 SUZIEQ_API_KEY=your_actual_api_keyReemplace los valores de marcador de posición con su punto final y clave reales.
Archivo
.envseguro: agregue.enva su archivo.gitignorepara evitar confirmar secretos accidentalmente.echo ".env" >> .gitignoreIntegración de código: el
server.pyproporcionado.py utiliza automáticamentepython-dotenvpara cargar estas variables cuando se inicia el servidor.
Ejecución del servidor
Asegúrese de que su entorno virtual esté activado. El servidor cargará la configuración desde el archivo .env en el directorio actual.
1. Directamente
Ejecute el servidor directamente desde su terminal:
uv run python main.pyEl servidor se iniciará, mostrará el mensaje " Starting SuzieQ MCP Server... y escuchará las conexiones MCP en la entrada/salida estándar (stdio). Debería ver los registros [INFO] si consulta correctamente la API a través de la herramienta. Presione Ctrl+C para detenerlo.
2. Con MCP Inspector (para depuración)
El Inspector MCP es útil para probar la herramienta directamente. Si tiene instaladas las herramientas CLI de mcp (mediante uv pip install "mcp[cli]" ), ejecute:
uv run mcp dev main.pyEsto inicia un depurador interactivo. Vaya a la pestaña "Herramientas", seleccione run_suzieq_show , introduzca los parámetros (p. ej., tabla: "dispositivo") y haga clic en "Llamar a la herramienta" para realizar la prueba.
Uso con Claude Desktop
Integre el servidor con Claude Desktop para un uso perfecto:
Busque Claude Desktop Config: localice el archivo
claude_desktop_config.json.macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonVentanas:
%APPDATA%\Claude\claude_desktop_config.jsonCrea el archivo y el directorio Claude si no existen.
Editar archivo de configuración: Agregar una entrada para este servidor. Usar la ruta absoluta a
main.pyEl servidor carga los secretos desde.env, por lo que no es necesario que estén en esta configuración.
{
"mcpServers": {
"suzieq-server": {
// Use 'uv' if it's in the system PATH Claude uses,
// otherwise provide the full path to the uv executable.
"command": "uv",
"args": [
"run",
"python",
// --- VERY IMPORTANT: Use the ABSOLUTE path below ---
"/full/path/to/your/project/mcp-suzieq-server/main.py"
],
// 'env' block is not needed here if .env is in the project directory above
"workingDirectory": "/full/path/to/your/project/mcp-suzieq-server/" // Optional, but recommended
}
// Add other servers here if needed
}
}Reemplace
/full/path/to/your/project/mcp-suzieq-server/main.pycon la ruta absoluta correcta en su sistema.Reemplace
/full/path/to/your/project/mcp-suzieq-server/con la ruta absoluta al directorio que contienemain.pyy.env. ConfigurarworkingDirectoryayuda a garantizar que se encuentre el archivo.env.Si Claude no encuentra
uv, reemplace"uv"con su ruta absoluta (buscar mediantewhich uvowhere uv).En Windows, es posible que necesite
"env": { "PYTHONUTF8": "1" }si encuentra problemas de codificación de texto.
Reiniciar Claude Desktop: cierre completamente y vuelva a abrir Claude Desktop.
Verificar: Busca el indicador de la herramienta MCP (icono del martillo 🔨) en Claude Desktop. Al hacer clic en él, deberían aparecer las herramientas
run_suzieq_showyrun_suzieq_summarize.
Uso de herramientas (run_suzieq_show)
run_suzieq_show(table: str, filters: Optional[Dict[str, Any]] = None) -> strtabla : (cadena, obligatoria) El nombre de la tabla SuzieQ (por ejemplo, "dispositivo", "interfaz", "bgp").
Filtros : (Diccionario, Opcional) Pares clave-valor para filtrar (p. ej.,
"hostname": "leaf01"). Omitir o usar{}para no aplicar filtros.Devuelve : una cadena JSON con los resultados o un error.
Ejemplos de invocaciones (conceptuales):
Mostrar todos los dispositivos:
{ "table": "device" }Mostrar vecinos BGP para el nombre de host 'spine01':
{ "table": "bgp", "filters": { "hostname": "spine01" } }Mostrar interfaces 'activas' en VRF 'predeterminado':
{ "table": "interface", "filters": { "vrf": "default", "state": "up" } }Uso de la herramienta (run_suzieq_summarize)
run_suzieq_summarize(table: str, filters: Optional[Dict[str, Any]] = None) -> strtabla : (cadena, obligatoria) El nombre de la tabla SuzieQ para resumir (por ejemplo, "dispositivo", "interfaz", "bgp").
Filtros : (Diccionario, Opcional) Pares clave-valor para filtrar (p. ej.,
"hostname": "leaf01"). Omitir o usar{}para no aplicar filtros.Devuelve : una cadena JSON con los resultados resumidos o un error.
Ejemplos de invocaciones (conceptuales):
Resumir todos los dispositivos:
{ "table": "device" }Resumir las sesiones BGP por nombre de host 'spine01':
{ "table": "bgp", "filters": { "hostname": "spine01" } }Resumir los estados de la interfaz en VRF 'predeterminado':
{ "table": "interface", "filters": { "vrf": "default" } }Solución de problemas
Error: "Punto final o clave de la API de SuzieQ no configurado..."
Asegúrese de que el archivo
.envesté en el mismo directorio quemain.pyVerifique
SUZIEQ_API_ENDPOINTySUZIEQ_API_KEYestén escritos correctamente y tengan valores válidos en.env.Si usa Claude Desktop, asegúrese de que el
workingDirectoryenclaude_desktop_config.jsonapunte al directorio que contiene.env.
Errores HTTP (4xx, 5xx):
Compruebe que la clave API de SuzieQ (
SUZIEQ_API_KEY) sea correcta (errores 401/403).Verifique que
SUZIEQ_API_ENDPOINTsea correcto y que el servidor API esté ejecutándose.
Available Tools
2 toolsrun_suzieq_showA
Runs a SuzieQ 'show' query via its REST API.
Args:
table: The name of the SuzieQ table to query (e.g., 'device', 'bgp', 'interface', 'route').
filters: An optional dictionary of filter parameters for the SuzieQ query
(e.g., {"hostname": "leaf01", "vrf": "default", "state": "Established"}).
Keys should match SuzieQ filter names. Values can be strings or lists of strings.
If no filters are needed, this can be None, null, or an empty dictionary.
Returns:
A JSON string representing the result from the SuzieQ API, or a JSON string with an error message.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | ||
| table | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the REST API mechanism and error handling in returns, but doesn't cover important aspects like rate limits, authentication needs, timeout behavior, or what constitutes valid table names beyond examples. For a tool with no annotation coverage, this leaves significant gaps in understanding operational constraints.
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?
The description is well-structured with clear sections (Args, Returns) and uses bullet-like formatting for parameter details. While somewhat verbose, each sentence adds value by explaining parameter usage. The front-loaded purpose statement is clear, though some details could be more concise.
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?
Given the tool has no annotations, no output schema, and 2 parameters, the description does a good job with parameter semantics but lacks completeness in other areas. It doesn't explain the return structure beyond 'JSON string', doesn't cover error scenarios comprehensively, and omits behavioral constraints. For a query tool with REST API dependencies, more operational context would be helpful.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. It clearly explains both parameters: 'table' with specific examples and 'filters' with detailed syntax, format examples, and handling of optional/null values. The description adds substantial meaning beyond what the bare schema provides.
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?
The description clearly states the action ('Runs a SuzieQ show query') and mechanism ('via its REST API'), providing a specific verb+resource combination. It distinguishes from the sibling tool 'run_suzieq_summarize' by specifying this is for 'show' queries rather than 'summarize' operations, though it doesn't explicitly contrast them in the text.
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?
The description implies usage context through the examples of tables and filters, suggesting when to use this tool for querying network data. However, it lacks explicit guidance on when to choose this over 'run_suzieq_summarize' or other alternatives, and doesn't mention prerequisites like API connectivity or authentication requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_suzieq_summarizeB
Runs a SuzieQ 'summarize' query via its REST API.
Args:
table: The name of the SuzieQ table to summarize (e.g., 'device', 'bgp', 'interface', 'route').
filters: An optional dictionary of filter parameters for the SuzieQ query
(e.g., {"hostname": "leaf01", "vrf": "default"}).
Keys should match SuzieQ filter names. Values can be strings or lists of strings.
If no filters are needed, this can be None, null, or an empty dictionary.
Returns:
A JSON string representing the summarized result from the SuzieQ API,
or a JSON string with an error message.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | ||
| table | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool runs via REST API and returns JSON or error messages, but lacks details on authentication needs, rate limits, side effects, or what 'summarize' entails behaviorally (e.g., aggregation, statistics). This is a significant gap for a tool with no annotation coverage.
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?
The description is appropriately sized and front-loaded with the core purpose. The Args and Returns sections are structured clearly, though the 'filters' explanation is slightly verbose. Most sentences earn their place by adding value, with minimal redundancy.
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?
Given 2 parameters, no annotations, no output schema, and moderate complexity, the description covers purpose and parameters well but lacks behavioral context and explicit usage guidelines. It is adequate as a minimum viable description but has clear gaps in transparency and guidance.
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 description coverage is 0%, so the description must compensate. It effectively adds meaning by explaining 'table' as the SuzieQ table name with examples and 'filters' as an optional dictionary with examples and usage notes. This goes beyond the schema's minimal titles, providing practical context for both parameters.
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?
The description clearly states the tool 'runs a SuzieQ summarize query via its REST API', specifying the verb (runs), resource (SuzieQ summarize query), and mechanism (REST API). It distinguishes from the sibling tool 'run_suzieq_show' by focusing on 'summarize' queries rather than 'show' queries, though the distinction could be more explicit.
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?
The description implies usage for SuzieQ summarize queries but does not explicitly state when to use this tool versus the sibling 'run_suzieq_show' or other alternatives. It provides context about the REST API mechanism but lacks explicit guidance on scenarios or prerequisites for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v1.0.0- First observed
run_suzieq_show - First observed
run_suzieq_summarize
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: run_suzieq_show performs a 'show' query to retrieve data, while run_suzieq_summarize performs a 'summarize' query to aggregate data. Their descriptions explicitly differentiate between querying and summarizing operations, leaving no ambiguity about which tool to use for each task.
Both tools follow a consistent verb_noun pattern with 'run_suzieq_' as a prefix, followed by the specific operation ('show' or 'summarize'). This naming convention is predictable and helps users understand the tools' functions at a glance, with no deviations or mixed styles.
With only two tools, the server feels thin for its apparent scope of network monitoring and analysis via SuzieQ. While the tools cover basic query and summarize operations, the domain suggests a need for more comprehensive functionality, such as additional query types or data manipulation tools, making the count insufficient for robust agent workflows.
The tool surface is severely incomplete for network monitoring and analysis. It lacks essential operations like data filtering beyond basic queries, configuration management, or integration with other network tools. The two tools provide only a minimal subset of what a full SuzieQ interface would offer, leaving significant gaps that will hinder agent effectiveness.
Maintenance
Related MCP Connectors
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
Related MCP Servers
- AlicenseAqualityDmaintenanceA Model Context Protocol (MCP) server designed to easily dump your codebase context into Large Language Models (LLMs).16 npm3Apache 2.0

OpsLevel MCPofficial
AlicenseNot gradedqualityFmaintenanceModel Context Protocol (MCP) server for OpsLevel12MIT- AlicenseBqualityCmaintenanceA Model Context Protocol server that integrates with Nautobot to provide network automation and infrastructure data to AI assistants like Claude, allowing them to query and interact with network Source of Truth systems.51MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server for interacting with Nautobot APIs using semantic search and dynamic API requests.17MIT