Skip to main content
Glama
enesjakoruzh
AGICoffe

my-topology-engine

by AGICoffe
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

基于拓扑的 AI 智能体引擎（MCP 服务器）

一个模型上下文协议（MCP）服务器，为 AI 智能体提供确定性的、基于拓扑的工作流引擎。该服务器不依赖开放式、不可预测的角色提示，而是与 Cloudflare Workers 交互，在边缘执行 10 步状态转换流水线，向客户端返回结构化的进度快照和迭代模板。

概述

该 MCP 服务器充当 AI 客户端（如 Claude Desktop、Cursor 或 Glama）与运行在 Cloudflare Workers 上的边缘计算拓扑执行引擎之间的桥梁。

它允许 AI 智能体将人类意图映射（类比）到固定的 10 步状态转换流水线中。它同时交付 10 个输出快照，以及一个用于下一次迭代的自适应 JSON 填空模板。

Related MCP server: project-planner-mcp

主要特性与能力

  • 协议合规：使用官方模型上下文协议（@modelcontextprotocol/sdk）实现。

  • 确定性拓扑：在 Cloudflare 边缘执行固定的问题解决步骤，消除幻觉循环并减少 GPU/令牌消耗。

  • 人在回路（快照用户体验）：一次性返回 10 个中间进度快照，允许用户检查时间线并无缝回滚。

  • 自适应提示模板：在输出末尾附加自适应 JSON 模式，实现顺畅的人机协作提示优化。

提供的 MCP 工具

该服务器向连接的 AI 客户端暴露以下 MCP 工具：

1. run_topology_pipeline

在 Cloudflare Workers 上执行 10 步确定性拓扑流水线，并返回 10 个状态转换快照以及一个 JSON 迭代模板。

  • 输入模式（inputSchema）：

    • task_description（字符串，必填）：要通过拓扑处理的任务或用户意图。

    • filled_template（对象，可选）：包含由人类提供或由智能体推断的参数或填空值的 JSON 对象。

  • 行为与智能体提示指令：

    1. AI 智能体将用户的高层请求映射到引擎的固定拓扑步骤。

    2. 服务器调用 Cloudflare Workers API 执行状态转换。

    3. 返回包含 10 个快照和 appendix_template 的结构化 JSON 负载。

    4. AI 智能体将 appendix_template 转换为自然对话，帮助人类为后续运行优化输入。

架构与通信流程

[人类 / AI 客户端（Claude、Cursor、Glama）] │ │ MCP 协议（Stdio） ▼ [该 MCP 服务器（Node.js 容器）] │ │ HTTP POST（边缘 REST API） ▼ [Cloudflare Workers 引擎] └─ 运行 10 步状态机拓扑并返回快照

环境变量

  • WORKER_URL：您的 Cloudflare Worker 端点的 URL（例如，https://my-topology-engine.my-agent-api.workers.dev）。

快速开始

通过 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
Deploy Server
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

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

Resources

Related MCP Connectors

Related MCP Servers