create_schema
Creates a typed schema for an AI agent, supporting persona, API, database, workflow, skill, and MCP tool/resource configurations. Structure payloads by schema type and validate them before saving.
Instructions
Cria um novo schema para um agente. O schema_data varia conforme o tipo:
persona_config: { editor_schema: { persona: { role, objective, tone, language, expertise, constraints, personality_traits, custom_guidelines } } }
api_config: { tool_definition, editor_schema } — ATENÇÃO: endpoint.name DEVE ser igual a tool_definition.name
db_config: { connection_id, tool_definition, query_template, parameter_mapping }
workflow_config: { steps, transitions, conditions }
skill_config: { skill: { name, instructions, priority? } } — instruções comportamentais transversais
mcp_tool_config / mcp_resource_config: vínculo de tool/resource de MCP server (normalmente gerados pelo Builder) Triggers e CSPs NÃO são schemas: use create_trigger e create_csp.
WORKFLOW RECOMENDADO (evita erros de contrato): leia o resource zihin://schemas/{schema_type} (JSON Schema formal — o mesmo que o servidor valida), monte o schema_data, valide com validate_schema_data (dry-run), então crie.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Nome do schema | |
| agent_id | Yes | UUID do agente | |
| description | No | Descrição do schema | |
| schema_data | Yes | Dados do schema. Estrutura por tipo: PERSONA_CONFIG: { editor_schema: { persona: { role: string (obrigatório, minLength 3), objective: string (obrigatório, minLength 10), tone?: string, language?: string, expertise?: string[], constraints?: string[], personality_traits?: string[], custom_guidelines?: object, response_style?: { format?: string, rules?: string[], max_response_length?: number } } } } API_CONFIG: { tool_definition: { name: string (snake_case), description: string (min 20 chars), input_schema: { type: "object", required: string[], properties: { campo: { type, description } } } }, editor_schema: { api: { base_url: string (URL), endpoints: [{ name: string (DEVE ser igual a tool_definition.name), method: "GET"|"POST"|"PUT"|"DELETE", path: string }], auth?: { prefix: "Bearer"|"Basic", secret_ref: string } } } } REGRAS CRÍTICAS para API_CONFIG: 1. endpoint.name DEVE ser IGUAL a tool_definition.name (senão a tool falha no roteamento interno) 2. Path parameters usam formato ${variavel} (com cifrão). Ex: /resources/${resource_id}/items 3. Auth: usar "prefix" (não "type") no objeto auth. Ex: { "prefix": "Bearer", "secret_ref": "MY_TOKEN" }. Para Basic Auth, armazenar o secret já em base64 4. Para input_schema com objetos aninhados (ex: body complexo com sub-objetos), definir cada campo como type "object" com suas próprias properties CAMPOS DE TRANSFORMAÇÃO (opcionais em cada endpoint): - default_body: { "from": "noreply@x.com" } — valores fixos mergeados no body (LLM pode sobrescrever, exceto locked_fields) - locked_fields: ["from"] — campos do default_body que o LLM NÃO pode sobrescrever (enforcement server-side) - field_mapping: { "body": "html" } — renomeia campos do body antes de enviar (body vira html) - array_fields: ["to", "cc"] — garante que esses campos sejam sempre arrays - body_format: "array" — wrappa o body inteiro em array [body] (default: "object") - defaults_from_context: { "userId": "idUsuario" } — auto-inject de valores do webhookContext quando LLM não fornece DB_CONFIG: { connection_id: uuid (de private_context_connections), tool_definition: { name, description, input_schema }, query_template: string (SQL com $1, $2...), parameter_mapping: string[] (campos do input na ordem dos $N), result_mapping?: { format: "raw"|"table"|"summary", max_rows?: number } } WORKFLOW_CONFIG: { steps: [{ id, name, action }], transitions: [{ from, to, condition }], conditions?: array } SKILL_CONFIG: { skill: { name: string (minLength 3), instructions: string (minLength 50, markdown com regras comportamentais), priority?: integer (0-1000, default 0, maior = aparece primeiro no prompt) } } Contrato formal de cada tipo: resource zihin://schemas/{schema_type}. CSPs não são schemas — campos multi-agent (max_agent_depth, allowed_invoke_agents, child_timeout_ms) vivem em create_csp com policy_type=behavior. | |
| schema_type | Yes | Tipo do schema |