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차원 철학적 매니폴드에 배치합니다:
면 | 하위 차원 | 단계 |
존재론 | 개별 ↔ 보편, 정적 ↔ 동적 | 이해 |
인식론 | 경험적 ↔ 합리적, 확실 ↔ 잠정 | 이해 |
가치론 | 절대적 ↔ 상대적, 양적 ↔ 질적 | 이해 |
목적론 | 즉각적 ↔ 궁극적, 의도적 ↔ 창발적 | 이해 |
현상학 | 객관적 ↔ 주관적, 표면 ↔ 심층 | 이해 |
윤리학 | 의무론적 ↔ 결과론적, 행위자 ↔ 행위 | 평가 |
미학 | 자율적 ↔ 맥락적, 감각적 ↔ 개념적 | 평가 |
실천론 | 개인적 ↔ 조정된, 반응적 ↔ 선제적 | 적용 |
방법론 | 분석적 ↔ 종합적, 연역적 ↔ 귀납적 | 적용 |
기호학 | 명시적 ↔ 암시적, 통사적 ↔ 의미론적 | 적용 |
해석학 | 문자적 ↔ 비유적, 저자 의도 ↔ 독자 반응 | 적용 |
휴리스틱 | 체계적 ↔ 직관적, 보수적 ↔ 탐색적 | 적용 |
각 면은 144개의 인식론적 관찰 지점으로 구성된 12x12 격자입니다. 위치에 따라 분류(모서리/중점/가장자리/중심), 잠재력 및 스펙트럼 소속이 결정됩니다. 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.3GB, HuggingFace 캐시로 1회 다운로드)와 빈도 순서 지정을 위한 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.
