FIVE Character Engine을 위한 MCP 서버 — 일관된 캐릭터 목소리를 위해 JSON 성격/스타일 제약 조건을 생성하는 LLM 제약 엔진입니다.
pip install five-mcpAPI 키를 환경 변수로 설정하세요:
export FIVE_API_KEY=five_sk_your_key_herefiveengine.dev에서 키를 발급받으세요.
claude_desktop_config.json에 추가하세요:
{
"mcpServers": {
"five-character-engine": {
"command": "five-mcp",
"env": {
"FIVE_API_KEY": "five_sk_your_key_here"
}
}
}
}모든 MCP 호환 클라이언트는 stdio 전송을 통해 연결할 수 있습니다:
five-mcpRelated MCP server: CSL-Core
generateFIVE 엔진을 통해 캐릭터 제약 조건을 생성합니다.
매개변수 | 유형 | 필수 | 설명 |
| string | 예 | 캐릭터 이름 |
| A / B / C / D | 예 | 성격 축 선택 |
| 1–5 | 아니요 | 스타일 슬라이더 (기본값: 3) |
| string | 아니요 | 자유 형식 설명 |
{
"status": "ok",
"remaining": 42,
"constraint": { "..." }
}각 generate 호출은 $1의 비용이 발생하며 크레딧 1개를 소모합니다. fiveengine.dev에서 크레딧을 관리하세요.
API 및 문서: fiveengine.dev
GitHub: github.com/kiro0x/five-mcp
MIT
Generate persona constraints using the FIVE engine.
This tool calls the FIVE Persona Engine API to produce JSON constraints that prevent persona drift and keep an LLM character's voice consistent.
Each call costs $1 and consumes one credit from your account.
Args: character_name: Name of the character to generate constraints for. q1: Personality axis 1 – choose A, B, C, or D. q2: Personality axis 2 – choose A, B, C, or D. q3: Personality axis 3 – choose A, B, C, or D. q4: Personality axis 4 – choose A, B, C, or D. s1: Style slider 1 (1-5, default 3). Optional fine-tuning. s2: Style slider 2 (1-5, default 3). Optional fine-tuning. s3: Style slider 3 (1-5, default 3). Optional fine-tuning. s4: Style slider 4 (1-5, default 3). Optional fine-tuning. free_text: Optional free-form description to further guide generation.
Returns: A dict with keys: status, remaining (credits left), constraint (the generated JSON constraint object).
| Name | Required | Description | Default |
|---|---|---|---|
| character_name | Yes | ||
| q1 | Yes | ||
| q2 | Yes | ||
| q3 | Yes | ||
| q4 | Yes | ||
| s1 | No | ||
| s2 | No | ||
| s3 | No | ||
| s4 | No | ||
| free_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses cost per call and credit consumption, which is helpful. However, it lacks details on idempotency, side effects, or rate limits. The return format is described, but behavioral transparency is not exhaustive.
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?
The description is well-structured, starting with a one-line summary, then engine explanation, cost, and a clear parameter list. While the style slider descriptions are repetitive, the overall structure is logical and efficient.
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 the complexity of 10 parameters, no output schema, and no annotations, the description covers the essential aspects: purpose, inputs, output format, and cost. It is sufficiently complete for an agent to invoke the tool correctly, though additional behavioral details would be beneficial.
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 adds significant value by explaining each parameter: character_name, q1-q4 (enum selections), s1-s4 (integer ranges with defaults), and free_text. It clarifies the purpose of optional fields and provides defaults, compensating for the lack of schema descriptions.
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's purpose: 'Generate persona constraints using the FIVE engine.' It explains the specific API and output format, leaving no ambiguity about what the tool does. With no sibling tools, distinction is not applicable.
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 provides no guidance on when to use this tool versus alternatives or prerequisites. It simply describes the function without context for selection.
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.1.2generateScored across 1 tool
With only one tool, there is no possibility of confusion between tools. The single 'generate' tool has a clearly distinct purpose.
The tool name 'generate' is a single verb, which is clear and follows a common convention. While there is no noun to form a verb_noun pattern, the name is consistent as the only tool.
The server has only one tool, which feels thin for a general-purpose utility. However, for a very focused single-API function, it is borderline acceptable.
The tool covers the core functionality of generating persona constraints with many parameters. Minor gaps exist (e.g., no credit management or constraint listing), but the tool is complete for its stated purpose.
Jailbreak-proof AI guardrails. Automated Reasoning SMT solver, not an LLM. ZK proofs included.
Personality tuning files for AI agents: 43 MIT-licensed tunings + 5 inline personality tests.
A personal RAG database you build from chat, so AI creates work that sounds like you.
Stop re-explaining yourself to AI. Save knowledge once, use it in every conversation.
