Servidor MCP para FIVE Character Engine, un motor de restricciones para LLM que genera restricciones de personalidad/estilo en JSON para lograr voces de personajes consistentes.
pip install five-mcpEstablece tu clave API como una variable de entorno:
export FIVE_API_KEY=five_sk_your_key_hereObtén tu clave en fiveengine.dev.
Añádelo a tu claude_desktop_config.json:
{
"mcpServers": {
"five-character-engine": {
"command": "five-mcp",
"env": {
"FIVE_API_KEY": "five_sk_your_key_here"
}
}
}
}Cualquier cliente compatible con MCP puede conectarse a través del transporte stdio:
five-mcpRelated MCP server: CSL-Core
generateGenera restricciones de personaje a través del motor FIVE.
Parámetro | Tipo | Requerido | Descripción |
| string | Sí | Nombre del personaje |
| A / B / C / D | Sí | Elecciones del eje de personalidad |
| 1–5 | No | Deslizadores de estilo (predeterminado: 3) |
| string | No | Descripción de forma libre |
{
"status": "ok",
"remaining": 42,
"constraint": { "..." }
}Cada llamada a generate cuesta $1 y consume un crédito. Gestiona tus créditos en fiveengine.dev.
API y documentación: fiveengine.dev
GitHub: github.com/kiro0x/five-mcp
Repositorio del motor: github.com/kiro0x/five-character-engine
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.
