Skip to main content
Glama
ianderso

gramps-evidence-mcp

by ianderso
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

update_event

DestructiveIdempotent

Edit an existing Gramps event in place to correct its type, date, place, or description; only supplied fields change while IDs, citations, notes, media, and linked people stay intact.

Instructions

Edit an existing event in place: its type, date, place or description.

Only what you pass changes. The event keeps its id, citations, notes, media and every person sharing it, so correct a wrong type or an unsupported place here rather than replacing the event. Citations: cite_event.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoNew date, Gramps style: '1899', '12 JAN 1899', 'ABT 1900', 'BEF 1950'; 'BET 1898 AND 1901' happened once within the range; 'FROM 4 MAY 1864 TO 16 SEP 1864' lasted the whole span; 'FROM 1880' or 'TO 1890' is open at one end. Omit to leave unchanged.
eventYesEvent handle or gramps_id (e.g. 'E0007').
placeNoNew place: existing handle/gramps_id, exact title, or exact unique name — created only if nothing matches. Omit to leave unchanged.
clear_dateNoRemove the event's date.
event_typeNoNew event type, e.g. 'Census', 'Visit'. Must already be a standard or custom type in the tree (list_object_types) unless allow_new_type is set. Omit to leave unchanged.
clear_placeNoRemove the event's place, e.g. one no source states. An empty place string is refused rather than read as this.
descriptionNoNew free-text description. Omit to leave unchanged.
allow_new_typeNoAccept an event_type the tree does not have yet, creating it as a custom type. Only for a deliberate new type, never a typo.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.0.1
    • addedInput schema / properties / allow_new_type
      Added value: +{
+  "default": false,
+  "description": "Accept an event_type the tree does not have yet, creating it as a custom type. Only for a deliberate new type, never a typo.",
+  "type": "boolean"
+}
    • addedInput schema / properties / clear_date
      Added value: +{
+  "default": false,
+  "description": "Remove the event's date.",
+  "type": "boolean"
+}
    • addedInput schema / properties / clear_place
      Added value: +{
+  "default": false,
+  "description": "Remove the event's place, e.g. one no source states. An empty place string is refused rather than read as this.",
+  "type": "boolean"
+}
    • changedInput schema / properties / date / description
      Previous value: -"New date, free text in Gramps style ('1899', 'ABT 1900'). Omit to leave unchanged."New value: +"New date, Gramps style: '1899', '12 JAN 1899', 'ABT 1900', 'BEF 1950'; 'BET 1898 AND 1901' happened once within the range; 'FROM 4 MAY 1864 TO 16 SEP 1864' lasted the whole span; 'FROM 1880' or 'TO 1890' is open at one end. Omit to leave unchanged."
    • addedInput schema / properties / event_type
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "New event type, e.g. 'Census', 'Visit'. Must already be a standard or custom type in the tree (list_object_types) unless allow_new_type is set. Omit to leave unchanged."
+}
  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 already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: partial-update semantics ('Only what you pass changes') and what is preserved (id, citations, notes, media, sharing persons), which is exactly what an agent needs to avoid a harmful rewrite.

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?

Three tightly written sentences with the core action front-loaded and no filler. The only sentence doing less work is the trailing 'Citations: cite_event' pointer, which is brief and still useful for routing.

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

Completeness5/5

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

With no output schema, the description supplies what an agent needs: the mutation is partial, the resource identity and related data survive, and related citation work is delegated. Combined with the rich 100%-coverage schema and the destructive/idempotent annotations, nothing essential is missing.

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 fully documents all eight parameters including the clear_* flags and allow_new_type. The description only names the four editable fields at a high level and adds no syntax beyond the schema, so the baseline of 3 applies.

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 names a specific verb (edit/update) and resource (event) and enumerates the mutable fields (type, date, place, description). It distinguishes the tool from replacement-style siblings by stating it edits in place rather than replacing the event, though it does not name those siblings explicitly.

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?

It gives a concrete when-to-use trigger: 'correct a wrong type or an unsupported place here rather than replacing the event,' and routes citation work to cite_event. It stops short of explicit when-not-to-use or naming a competing tool, but the guidance is clear.

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