Skip to main content
Glama
caix84476-netizen

personal understanding

personal_add_record

Creates a derived memory record from an existing verbatim capture, specifying kind, tier (light or full), and associated metadata for personal knowledge tracking.

Instructions

创建派生记录。若来源是当前用户补充,必须先有 verbatim capture,并把 verbatim_refs 写入记录。活动足迹类微型记录传 tier=light(salience 0-1),完整档记录不传或传 full;记录层 tier 仅表示记录形态,不再表示调用档位。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
kindYes
tierNo记录形态:light=活动足迹微型记录(salience 0-1);缺省/full=完整档记录。仅表示形态,不再表示调用档位
phaseNo
domainNo
aliasesNo
summaryYes
date_endNo
salienceNo
capture_idNo
confidenceNohigh
date_basisNo
valid_fromNo
entity_refsNo
record_roleNo
related_idsNo
sensitivityNoordinary
source_refsNo
verbatim_refsNo
date_precisionNo
last_confirmedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.6.0
    • addedInput schema / properties / tier
      Added value: +{
      +  "description": "记录形态:light=活动足迹微型记录(salience 0-1);缺省/full=完整档记录。仅表示形态,不再表示调用档位",
      +  "enum": [
      +    "full",
      +    "light"
      +  ],
      +  "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?

With no annotations provided, the description carries the full burden. It discloses important behavioral traits: the dependency on prior verbatim capture, the requirement to write verbatim_refs, and the semantic shift for tier (now only represents record form, not API tier). This is substantial behavioral context for a create operation.

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?

The description is compact, with key information front-loaded about the derived-record purpose. The tier explanation is dense but necessary. It earns its place, though it could be slightly more structured for readability.

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 21-parameter create tool with no output schema and no annotations, the description covers the most critical preconditions (verbatim capture) and the ambiguous tier parameter. It doesn't explain all parameters, but the sibling tools and schema already provide structural context. The core call-critical constraints are well covered.

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 only 5%, so description must compensate. The description explains the critical tier parameter semantics ('记录层 tier 仅表示记录形态,不再表示调用档位') and the verbatim_refs requirement, which are not self-evident from the schema. It also clarifies the salience range for light tier. This meaningfully adds value beyond the bare schema.

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?

The description uses a specific verb ('创建派生记录' - create derived record) and resource, and differentiates it from capture tools by stating it creates derived records. However, it doesn't explicitly distinguish itself from sibling tools like personal_add_followup or personal_add_hypothesis, so it's clear but lacks sibling differentiation.

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?

The description provides clear context: it must be used after a verbatim capture when the source is user-supplied, and specifies when to use tier=light vs full. However, it doesn't explicitly state when NOT to use this tool or name alternatives, leaving some room for inference.

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