Skip to main content
Glama

update_entity

Update only the specified entity fields, keeping all other data intact, and run a data audit before writing to maintain integrity.

Instructions

字段级更新 entity 页(只改传入字段,保留其余)。写入前跑数据审计。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes现有 entity 名称(不含 .md 后缀,定位目标文件)
domainNo可选:改业务域归属
contentNo可选:正文内容(Markdown body,不含 frontmatter;省略 = 保留原正文)
newNameNo可选:改名(新名称,不含 .md 后缀)
relationsNo可选:JSON 格式关联关系(belongs_to / has_many),整体替换 relations
descriptionNo可选:改 entity 简述

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses two key behaviors: only passed fields are changed while the rest are preserved, and a data audit runs before writing. It omits permissions, audit-failure consequences, and reversibility, but the core mutation semantics are clearly exposed.

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

Conciseness5/5

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

Two short Chinese sentences front-load the core behavior and then add the audit caveat. There is no filler, redundancy, or repetition of schema content.

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 six-parameter mutation tool with no annotations or output schema, the description covers the essential semantics: target identification via name, partial-update behavior, and pre-write audit. It omits return values and audit-failure behavior, but the schema fills parameter details, making the definition largely complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents every parameter, including optionality and the '省略 = 保留原正文' behavior for content. The tool description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

Purpose5/5

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

Description states a specific verb and resource: field-level update of entity pages, with explicit 'only changes passed fields, preserves the rest.' This clearly distinguishes it from create_entity, delete_entity, read_entity, and from full-overwrite operations.

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

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use guidance is provided, and no alternatives such as create_entity or delete_entity are named. The partial-update semantics imply this is for modifying existing entities, but the agent must infer the usage context.

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