一个以 MCP 服务器形式提供的通用提示词创建引擎。它在 12 个哲学维度上衡量意图，并返回一个构建基础，客户端可据此构建提示词。
该引擎本身不生成提示词。它提供维度基础——主动构建、光谱对立、张力、核心要素 (gems)、分支 (spokes)、协调对和构建问题——使提示词构建变得有据可依，而非仅仅依赖启发式方法。
# Install
pip install advanced-prompting-engine
# Or run directly via uvx
uvx advanced-prompting-engine添加到你的 .mcp.json 中：
{
"mcpServers": {
"advanced-prompting-engine": {
"command": "uvx",
"args": ["advanced-prompting-engine"]
}
}
}Related MCP server: MCP Prompt Optimizer
该引擎将你的意图定位在一个 12 维的哲学流形中：
面 | 子维度 | 阶段 |
本体论 | 特殊 ↔ 普遍，静态 ↔ 动态 | 理解 |
认识论 | 经验 ↔ 理性，确定 ↔ 临时 | 理解 |
价值论 | 绝对 ↔ 相对，定量 ↔ 定性 | 理解 |
目的论 | 即时 ↔ 终极，意图 ↔ 涌现 | 理解 |
现象学 | 客观 ↔ 主观，表面 ↔ 深度 | 理解 |
伦理学 | 义务论 ↔ 后果论，主体 ↔ 行为 | 评估 |
美学 | 自主 ↔ 情境，感官 ↔ 概念 | 评估 |
实践论 | 个人 ↔ 协调，反应 ↔ 主动 | 应用 |
方法论 | 分析 ↔ 综合，演绎 ↔ 归纳 | 应用 |
符号学 | 显性 ↔ 隐性，句法 ↔ 语义 | 应用 |
诠释学 | 字面 ↔ 比喻，作者意图 ↔ 读者反应 | 应用 |
启发法 | 系统 ↔ 直觉，保守 ↔ 探索 | 应用 |
每个面都是一个 12x12 的网格，包含 144 个认知观察点。位置决定了分类（角/中点/边/中心）、效能和光谱归属。这 12 个面被组织为 6 个互补对（立方体模型），并通过共享表面进行协调。引擎通过位置对应关系计算张力、通过立方体层级调制计算核心要素（跨面整合）、通过分支（每面的行为特征）以及中心核心要素的一致性得分。
工具 | 用途 |
| 主要工具 — 输入意图或坐标，输出构建基础 |
| 解释 — 以通俗语言解读构建基础 |
| 专家工具 — 图遍历、压力测试、三角测量 |
| 创作 — 添加带有矛盾检测的构建和关系 |
create_prompt_basis(intent="Design an ethical framework for autonomous vehicle decision-making")引擎在所有 12 个哲学维度上定位此意图并返回：
{
"coordinate": {
"epistemology": {"x": 4, "y": 4, "weight": 0.76},
"ontology": {"x": 6, "y": 5, "weight": 0.73},
"praxeology": {"x": 7, "y": 4, "weight": 0.72},
"heuristics": {"x": 5, "y": 3, "weight": 0.66},
"phenomenology": {"x": 7, "y": 4, "weight": 0.61},
"ethics": {"x": 6, "y": 4, "weight": 0.53},
"...": "...all 12 faces with (x,y) position and relevance weight"
},
"harmonization": [
{"pair": ["ontology", "praxeology"], "resonance": 0.15},
{"pair": ["axiology", "ethics"], "resonance": 0.05},
"...6 complementary pairs with resonance scores"
],
"spokes": {
"ontology": {"classification": "weakly_integrated", "strength": 0.042},
"epistemology": {"classification": "weakly_integrated", "strength": 0.039},
"...": "...per-face behavioral signatures"
},
"central_gem": {"coherence": 0.69, "classification": "highly_coherent"},
"construction_questions": {
"ethics": {
"template": "What moral obligations does this prompt impose or assume?",
"position_summary": "balanced Deontological/Consequential + moderately Agent-focused",
"meaning_mechanism": "composition",
"phase": "evaluation"
},
"...": "...12 position-specific philosophical questions to guide prompt construction"
}
}输出告诉你：此意图主要关于知识验证（认识论 0.76）、实体存在（本体论 0.73）和行动结构（实践论 0.72）。伦理学得分为 0.53 — 存在但非主导。协调性显示本体论和实践论产生了强烈的共鸣（0.15）——理论上的“存在什么”与实践上的“如何行动”相一致。
为了精确控制，可以直接传递坐标：
coordinate = {
"ontology": {"x": 0, "y": 0, "weight": 1.0}, # corner: particular + static
"ethics": {"x": 0, "y": 11, "weight": 0.9}, # corner: deontological + act
"methodology": {"x": 0, "y": 0, "weight": 0.8}, # corner: analytic + deductive
# ...all 12 faces with x (0-11), y (0-11), weight (0-1)
}
result = create_prompt_basis(coordinate=coordinate)技术栈： Python + NetworkX (拓扑) + numpy (计算) + SQLite (持久化) + MCP SDK
图结构： 1873 个节点，2279 条边（12 个面 × 144 个构建 + 132 个连接点 + 1 个中心核心要素）
流水线： 8 个阶段（意图解析器 → 坐标解析器 → 位置计算器 → 构建解析器 → 张力分析器 → 连接点/核心要素分析器 → 分支分析器 → 构建桥接器）
几何： 以向量平衡（立方八面体）作为潜在的跨面拓扑，以立方体模型作为 6 个互补对的结构
部署： 单进程，stdio 传输，无守护进程，无外部依赖
docs/DESIGN.md — 完整设计规范
docs/CONSTRUCT-v2.md — 构建规范（面、点、光谱、连接点、核心要素、分支的定义）
docs/CONSTRUCT-v2-questions.md — 按区域划分的 144 个构建问题模板
docs/adr/ — 13 份架构决策记录
pip install -e ".[dev]"
pytest tests/ -v发布的包中包含预计算的 BGE 派生工件（semantic_bridge.npz, semantic_vocab.json）。若要从头开始重建它们（例如在修改极点同义词后），请安装构建扩展：
pip install -e ".[build]"
python -m nltk.downloader wordnet omw-1.4
python scripts/build_semantic_bridge.py构建过程使用 BAAI/bge-large-en-v1.5（约 1.3 GB，下载一次至 HuggingFace 缓存）和 wordfreq 进行频率排序。运行时依赖项不受影响 — 最终用户仅接收预计算的工件。
请参阅 CONTRIBUTING.md 获取开发设置和指南。
请参阅 SECURITY.md 获取漏洞报告说明。
MIT
Measure intent across 12 philosophical dimensions and return a construction basis.
Use this before constructing any prompt where dimensional precision, philosophical coherence, or systematic completeness matters.
Provide either 'intent' (natural language) or 'coordinate' (JSON object with 12 faces, each having x, y, weight).
Output modes (mutually exclusive, focused takes priority):
Default: full output (~50KB) with all pipeline data
compact=true: summary fields only (~2KB)
focused=true: guidance-centric output (~500 bytes) with dominant dimensions, gaps, resonance, and coherence — what a prompt engineer needs
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | ||
| coordinate | No | ||
| compact | No | ||
| focused | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It outlines output modes (default, compact, focused) with approximate sizes, and describes the coordinate structure. It does not mention side effects, permissions, or rate limits, but as a read-like creation tool, the disclosure is adequate.
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?
Three short paragraphs (about 100 words) that are front-loaded with the main purpose, followed by usage and output details. Every sentence adds value, no redundancy or fluff.
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 0 required params, 4 optional params, and an output schema, the description covers input options and output modes well. It could briefly name the 12 dimensions, but the output schema likely details that. Overall, sufficient for an AI agent.
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?
Schema coverage is 0%, so the description fully compensates. It explains that 'intent' is natural language, 'coordinate' is a JSON object with 12 faces (x, y, weight), and that compact/focused control output verbosity. This adds crucial meaning absent from the schema.
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 measures intent across 12 philosophical dimensions and returns a construction basis. It uses specific verbs ('measure', 'return') and a clear resource, and distinguishes itself from siblings by focusing on basis creation for dimensional precision.
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 explicitly advises using this tool before constructing prompts where dimensional precision, coherence, or completeness matters. It also explains input options (intent or coordinate) and output modes, but does not directly compare to sibling tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explore the philosophical manifold. Operations: list_faces, list_constructs, get_construct, get_neighborhood, find_path, get_spoke, stress_test, triangulate.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| face | No | ||
| x | No | ||
| y | No | ||
| target_face | No | ||
| target_x | No | ||
| target_y | No | ||
| coordinate | No | ||
| coordinate_a | No | ||
| coordinate_b | No | ||
| classification | No | ||
| provenance | No | merged |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Does not disclose side effects, permissions, rate limits, or any behavioral traits. Only states 'explore', which is non-committal.
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?
Short two sentences, but front-loading with vague phrase reduces impact. List of operations is useful but could be structured better. Minimal but not overly concise for the complexity.
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?
With 12 parameters and 0% schema coverage, description is severely incomplete. No explanation of operations, their required parameters, or return values. Output schema exists but unmentioned.
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?
Schema description coverage is 0%, so description must add meaning. It only lists operation names without explaining any parameter. Parameters like x, y, face, etc. are not described, leaving agent guessing.
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 verb 'explore' is vague and 'philosophical manifold' is abstract, but listing operations gives some idea. Not a tautology, but doesn't clearly state concrete purpose. Distinguishes from sibling tools implicitly via domain, but lacks explicit differentiation.
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?
No guidance on when to use this tool vs alternatives. Does not suggest scenarios or mention sibling tools. The list of operations implies different behaviors, but no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add constructs or relations to the graph. Contradiction detection is automatic.
Operations: add_construct, add_relation.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| face | No | ||
| x | No | ||
| y | No | ||
| question | No | ||
| tags | No | ||
| description | No | ||
| source_id | No | ||
| target_id | No | ||
| relation_type | No | ||
| strength | No | ||
| override_reason | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Notes automatic contradiction detection, which is a behavioral trait. However, with no annotations, the description should disclose more about side effects, reversibility, and required permissions; it only provides one behavioral insight.
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?
Two sentences plus a list of operations make it concise, but it lacks structure and omits important details; every sentence is functional but incomplete.
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?
With 12 parameters and no parameter descriptions, the tool is complex. The description does not explain return values (output schema exists) or how to use parameters, leaving significant gaps.
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?
Schema coverage is 0%, yet the description does not explain any of the 12 parameters (e.g., face, x, y, tags, strength). Users must infer meanings from names alone, which is insufficient.
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?
Description clearly states 'Add constructs or relations to the graph' and lists two operations (add_construct, add_relation). It distinguishes the tool's action from siblings like create_prompt_basis, explore_space, interpret_basis, but doesn't explicitly contrast them.
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?
No guidance on when to use this tool versus alternatives. Only mentions available operations without context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interpret a construction basis produced by create_prompt_basis.
Takes the JSON output from create_prompt_basis and returns a plain-language interpretation of the philosophical measurement. Extracts the guidance section and formats it as readable text with dominant dimensions, gaps, and strongest resonance.
| Name | Required | Description | Default |
|---|---|---|---|
| basis | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description details the tool's behavior: extracts the guidance section and formats it as readable text with dominant dimensions, gaps, and strongest resonance. This goes beyond a simple 'interpret' to specify output content.
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?
Three sentences, front-loaded with purpose, no wasted words. Each sentence adds value.
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 one parameter with no schema coverage, the description fully explains the parameter and behavior. Output schema exists, so return value details are not needed. The tool is simple and well-described.
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 only parameter 'basis' has no schema description, but the description compensates by specifying it expects 'JSON output from create_prompt_basis', adding essential meaning to the raw type string.
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?
Description clearly states the verb 'interpret' and the resource 'construction basis produced by create_prompt_basis', effectively differentiating it from sibling tools like create_prompt_basis (which produces the basis).
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?
Description implies usage context: takes JSON output from create_prompt_basis. While it doesn't explicitly state when not to use alternatives, the dependency on a prior tool output is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.8.0create_prompt_basisexplore_spaceextend_schemainterpret_basisScored across 4 tools
Each tool has a distinct purpose: create measures intent, explore navigates the manifold, extend modifies the graph, interpret explains results. No overlap in functionality.
All tool names follow a consistent verb_noun pattern (create_prompt_basis, explore_space, extend_schema, interpret_basis), making it easy to predict tool roles.
Four tools is an ideal number for a specialized philosophical engine, covering core operations without unnecessary bloat.
The toolkit covers creation, exploration, extension, and interpretation. The only minor gap is the lack of a deletion or reset tool, but this is acceptable for a focused engine.
MCP server for generating rough-draft project plans from natural-language prompts.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Hosted MCP server and Agent Skills for specs, engineering threads, and project memory.
