Skip to main content
Glama

Motor de Agente de IA basado en Topología (Servidor MCP)

Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona un motor de flujo de trabajo determinista y basado en topología para Agentes de IA. En lugar de depender de prompts de persona abiertos e impredecibles, este servidor se conecta con Cloudflare Workers para ejecutar pipelines de transición de estado de 10 pasos en el borde, devolviendo instantáneas de progreso estructuradas y plantillas de iteración al cliente.

Resumen

Este servidor MCP actúa como un puente entre clientes de IA (como Claude Desktop, Cursor o Glama) y un motor de ejecución de topología computado en el borde que se ejecuta en Cloudflare Workers.

Permite que un agente de IA mapee (analogice) la intención humana en un pipeline de transición de estado fijo de 10 pasos. Entrega 10 instantáneas de salida simultáneamente junto con una plantilla adaptativa de relleno de espacios en blanco en JSON para la siguiente iteración.

Related MCP server: project-planner-mcp

Características y Capacidades Clave

  • Cumplimiento del Protocolo: Implementado usando el Protocolo de Contexto de Modelo oficial (@modelcontextprotocol/sdk).

  • Topología Determinista: Ejecuta pasos fijos de resolución de problemas en el borde de Cloudflare, eliminando bucles alucinatorios y reduciendo el consumo de GPU/tokens.

  • Humano en el Bucle (UX de Instantáneas): Devuelve 10 instantáneas de progreso intermedias a la vez, permitiendo a los usuarios inspeccionar la línea de tiempo y retroceder sin problemas.

  • Plantilla de Prompt Adaptativa: Añade un esquema JSON adaptativo al final de la salida para un refinamiento colaborativo fluido entre humano e IA.


Herramientas MCP Proporcionadas

Este servidor expone las siguientes Herramientas MCP a los clientes de IA conectados:

1. run_topology_pipeline

Ejecuta un pipeline de topología determinista de 10 pasos en Cloudflare Workers y devuelve 10 instantáneas de transición de estado junto con una plantilla de iteración JSON.

  • Esquema de Entrada (inputSchema):

    • task_description (cadena, obligatorio): La tarea o intención del usuario que se procesará a través de la topología.

    • filled_template (objeto, opcional): Un objeto JSON que contiene parámetros o valores de relleno de espacios en blanco proporcionados por el humano o inferidos por el agente.

  • Comportamiento e Instrucciones de Prompt del Agente:

    1. El Agente de IA mapea la solicitud de alto nivel del usuario a los pasos de topología fijos del motor.

    2. El servidor llama a la API de Cloudflare Workers para ejecutar las transiciones de estado.

    3. Devuelve un payload JSON estructurado que contiene 10 instantáneas y un appendix_template.

    4. El Agente de IA traduce el appendix_template a conversación natural para ayudar al humano a refinar las entradas para ejecuciones posteriores.

Arquitectura y Flujo de Comunicación

[Humano / Cliente de IA (Claude, Cursor, Glama)] │ │ Protocolo MCP (Stdio) ▼ [Este Servidor MCP (Contenedor Node.js)] │ │ POST HTTP (API REST de Borde) ▼ [Motor de Cloudflare Workers] └─ Ejecuta Topología de Máquina de Estados de 10 pasos y Devuelve Instantáneas

Variables de Entorno

  • WORKER_URL: La URL de tu endpoint de Cloudflare Worker (por ejemplo, https://my-topology-engine.my-agent-api.workers.dev).

Primeros Pasos

Ejecución Local mediante Docker

# Build the Docker image
docker build -t mcp-topology-server .

# Run the MCP container
docker run -i --rm -e WORKER_URL="[https://my-topology-engine.my-agent-api.workers.dev](https://my-topology-engine.my-agent-api.workers.dev)" mcp-topology-server
Installation in Claude Desktop / MCP Clients
Add the following configuration to your claude_desktop_config.json:
{
  "mcpServers": {
    "topology-engine": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "WORKER_URL=[https://your-worker.workers.dev](https://your-worker.workers.dev)",
        "mcp-topology-server"
      ]
    }
  }
}

Available Tools

1 tool
execute_topology_engineC

Executes a 10-step deterministic problem-solving topology engine to process tasks and generate state-transition snapshots.

ParametersJSON Schema
NameRequiredDescriptionDefault
filled_templateNoOptional key-value parameters to constrain or guide the 10-step execution.
task_descriptionYesThe primary task or problem to be solved.

TDQS

C2.9/5.0
Behavior2/5

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

Annotations are absent, so the description carries the full burden. It mentions 'deterministic' and '10-step' but does not disclose what happens during execution, side effects, required permissions, or what the output 'state-transition snapshots' entail. The behavior is underspecified for a tool with no annotations.

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

Conciseness4/5

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

The description is a single, concise sentence with no redundant information. It is front-loaded with the core action and key characteristics. However, it could benefit from a couple more sentences to clarify usage, but as is, it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a 10-step engine and no output schema, the description is insufficient. It does not explain what 'state-transition snapshots' are, how the filled_template constrains execution, or what the tool returns. The tool's operation remains abstract.

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 description coverage is 100% for the two parameters, but the description adds minimal meaning beyond the schema. It names 'filled_template' and 'task_description' but does not explain how they influence the 10-step execution. Baseline 3 is appropriate as the schema covers parameter definitions.

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 executes a 10-step deterministic problem-solving topology engine to process tasks and generate state-transition snapshots. The purpose is specific and distinct, though it introduces jargon ('topology engine') that could be ambiguous without further context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives, nor exclusions or prerequisites. The description implies it should be used for tasks requiring a structured problem-solving approach, but it does not explicitly define appropriate use cases or situations to avoid.

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.

  1. 1 tool updatev1.0.0
    • First observedexecute_topology_engine

TDQS

B3.2/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion between different tools. The tool's purpose is clearly described as executing a topology engine, leaving no ambiguity.

Naming Consistency5/5

The single tool name follows a clear verb_noun pattern ('execute_topology_engine'), which is consistent and predictable. Even with one tool, the naming is well-structured and aligns with common conventions.

Tool Count3/5

One tool is on the borderline of being insufficient for a typical server, as most servers require at least a few tools to cover related operations. However, if the server's sole purpose is to run this engine, the count could be justified, but it feels thin without additional context.

Completeness2/5

The server exposes only a single operation, lacking any configuration, query, or retrieval tools that would complement the execution workflow. This creates significant gaps for agents that may need to set up inputs or inspect outputs, making the surface incomplete for a broader task lifecycle.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers