Skip to main content
Glama
zihin-ai

Zihin MCP Server

by zihin-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

update_schema

Idempotent

Updates an existing schema by replacing its full schema_data, using base_version to avoid overwriting concurrent edits.

Instructions

Atualiza os dados (schema_data) de um schema existente — o nome que vale fica dentro de schema_data. Fluxo seguro com mais de um editor: get_schema → use a version como base_version → update_schema (com changelog). Para api_config: endpoint.name DEVE ser igual a tool_definition.name. Para persona_config: usar formato { editor_schema: { persona: { role, objective, ... } } }.

Input Schema

NameRequiredDescriptionDefault
changelogNoPor que a mudança foi feita. Fica gravado na versão criada (list_versions/compare_versions).
schema_idYesUUID do schema a atualizar
schema_dataNoNovos dados do schema (mesma estrutura por tipo de create_schema). IMPORTANTE: enviar schema_data completo, não parcial — o objeto substitui o anterior por inteiro.
base_versionNoRecomendado. A `version` que você leu em get_schema. Se o schema mudou desde então (outra pessoa editou), nada é gravado e volta CONFLICT com a versão atual — releia e reaplique. Sem ele, a última escrita vence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.2.2
    • addedInput schema / properties / base_version
      Added value: +{
+  "description": "Recomendado. A `version` que você leu em get_schema. Se o schema mudou desde então (outra pessoa editou), nada é gravado e volta CONFLICT com a versão atual — releia e reaplique. Sem ele, a última escrita vence.",
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / changelog
      Added value: +{
+  "description": "Por que a mudança foi feita. Fica gravado na versão criada (list_versions/compare_versions).",
+  "maxLength": 500,
+  "type": "string"
+}
    • removedInput schema / properties / description
      Removed value: -{
-  "description": "Nova descrição",
-  "type": "string"
-}
    • removedInput schema / properties / name
      Removed value: -{
-  "description": "Novo nome",
-  "minLength": 1,
-  "type": "string"
-}
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover the safety profile (idempotent, non-destructive, closed-world); the description adds substantive behavior: schema_data replaces the prior object in full, and a stale base_version yields a CONFLICT with the current version. That is real disclosure beyond the annotations, though the full-replace and CONFLICT semantics are partly duplicated in the schema's own parameter descriptions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with the action and followed by workflow, then per-type constraints; nothing is filler. Slightly dense with back-to-back type-specific rules, but each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description covers replacement semantics, conflict handling, changelog recording, and per-type payload shape — enough for correct invocation. It omits what a successful response returns, but with no output schema that is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: required type-specific shapes for api_config (endpoint.name must equal tool_definition.name) and persona_config ({ editor_schema: { persona: { role, objective, ... } } }). These constraints are not derivable from the generic 'same structure as create_schema' schema note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Atualiza os dados (schema_data) de um schema existente' — and clarifies that the effective name lives inside schema_data, which is a meaningful disambiguation. It does not explicitly name a sibling to differentiate from (e.g., create_schema, validate_schema_data, toggle_schema), so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit safe-editing workflow: get_schema → reuse `version` as base_version → update_schema with changelog, which is actionable context for concurrent editors. It does not state when to prefer alternatives such as validate_schema_data first or when this tool should not be used, so no exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools