Skip to main content
Glama
enesjakoruzh
AGICoffe

my-topology-engine

by AGICoffe
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

토폴로지 기반 AI 에이전트 엔진 (MCP 서버)

AI 에이전트를 위한 결정론적(deterministic) 토폴로지 기반 워크플로우 엔진을 제공하는 Model Context Protocol (MCP) 서버입니다. 개방형이고 예측 불가능한 페르소나 프롬프트에 의존하는 대신, 이 서버는 Cloudflare Workers와 인터페이스하여 엣지에서 10단계 상태 전이 파이프라인을 실행하고, 구조화된 진행 스냅샷과 반복 템플릿을 클라이언트에 반환합니다.

개요

이 MCP 서버는 AI 클라이언트(예: Claude Desktop, Cursor 또는 Glama)와 Cloudflare Workers에서 실행되는 엣지 컴퓨팅 토폴로지 실행 엔진 사이의 브리지 역할을 합니다.

AI 에이전트가 인간의 의도를 고정된 10단계 상태 전이 파이프라인으로 매핑(유추)할 수 있게 해줍니다. 동시에 10개의 출력 스냅샷과 다음 반복을 위한 적응형 JSON 빈칸 채우기 템플릿을 함께 전달합니다.

Related MCP server: project-planner-mcp

주요 기능 및 역량

  • 프로토콜 준수: 공식 Model Context Protocol(@modelcontextprotocol/sdk)을 사용하여 구현됨.

  • 결정론적 토폴로지: Cloudflare Edge에서 고정된 문제 해결 단계를 실행하여 환각 루프를 제거하고 GPU/토큰 소비를 줄입니다.

  • Human-in-the-Loop (스냅샷 UX): 한 번에 10개의 중간 진행 스냅샷을 반환하여 사용자가 타임라인을 검토하고 원활하게 롤백할 수 있습니다.

  • 적응형 프롬프트 템플릿: 원활한 인간-AI 협업 프롬프트 개선을 위해 출력 끝에 적응형 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