Skip to main content
Glama

Create Event

create_event

Create a standalone event such as Birth, Marriage, or Residence with date, place, citations, notes, and media, then attach it to people or families using update_person or update_family.

Instructions

Create a standalone event (Birth, Marriage, Residence, Census, …) with its date, place, description, citations, notes and media. Returns the new handle, Gramps ID and type, with next steps. The event is linked to nobody yet: attach it with update_person or update_family (eventRefs, linkMode add), which keeps their other events; several people can share one event, each with their own role. The role is stored on their eventRefs (HANDLE::Role, default Primary on a person and Family on a family), not on the event, and a Birth or Death becomes a person's birth or death only in the Primary role. The place must exist: find it with search or create it with create_place. A dated range such as 1890-1900 means the event happened once, some time within it; for something that lasted, such as a Residence or Occupation, write from 1890 to 1900. A register that gives both birth and baptism makes two events, Birth and Baptism. Citations, notes, media, tags and attributes passed here belong to the event and show for everyone who shares it; one participant's own details, such as their Age, go on that person's eventRefs entry (its attribute_list). Change an existing event with update_event. An unknown type or unreadable date is rejected before anything is saved. For several new records that link to each other, such as the people, events, source and citation of one register entry, use create_records instead: one transaction, all created or none. Writes run one at a time and need a Gramps Web account allowed to edit the tree; a locked or rate-limited write fails with the delay to wait before retrying it. Formats of every argument: get_reference(topic: "input-guide").

Input Schema

NameRequiredDescriptionDefault
dateNoWhen it happened, optional. Date text: 1856-07-20, 1920-05, 1920, 1 Jul 1919, about/before/after 1920, 1800-1850, between … and …; append the calendar for other calendars, e.g. 1856-07-20 (Julian). Unreadable dates are rejected.
eventTypeYesEvent type, e.g. Birth, Baptism, Death, Burial, Marriage, Residence, Occupation. Must be a standard Gramps type or a custom one the tree already uses; anything else is rejected with suggestions. List: get_reference(topic: "types").
isPrivateNoMark the event private (default false).
attributesNoAttributes: JSON array of objects {type,value,...}, or strings "Type: Value" (first colon), or one string with lines or | between entries. A type must be a standard Gramps attribute type or a custom one the tree already uses; anything else is rejected with suggestions. Full grammar: gramps://input-guide.
tagHandlesNoTags. Handles, not Gramps IDs: JSON array ["h1","h2"], one handle, or a comma/semicolon/newline-separated string; entries may also be objects {"ref":"…"}.
descriptionNoShort description, optional.
noteHandlesNoNotes. Handles, not Gramps IDs: JSON array ["h1","h2"], one handle, or a comma/semicolon/newline-separated string; entries may also be objects {"ref":"…"}.
placeHandleNoWhere it happened, optional; the place must exist (create_place). Handle or Gramps ID (e.g. I0001), resolved automatically; find it with search or list_objects.
mediaHandlesNoMedia. Media handles, not Gramps IDs: JSON array ["h1","h2"], one handle, or a comma/semicolon/newline-separated string. To show only part of an image, such as one record on a page scan, give an object {"ref":"…","region":[left, top, right, bottom]} in place of the handle. A region is [left, top, right, bottom]: its edges in percent of the image width and height, 0 to 100, measured from the top-left corner; [10, 20, 60, 45] runs from 10% to 60% across and from 20% to 45% down. [0, 0, 100, 100] shows the whole image again; read_media with the same region shows what it covers.
citationHandlesNoCitations supporting the event. Handles, not Gramps IDs: JSON array ["h1","h2"], one handle, or a comma/semicolon/newline-separated string; entries may also be objects {"ref":"…"}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.5.1
    • changedInput schema / properties / mediaHandles / description
      Previous value: -"Media. Handles, not Gramps IDs: JSON array [\"h1\",\"h2\"], one handle, or a comma/semicolon/newline-separated string; entries may also be objects {\"ref\":\"…\"}."New value: +"Media. Media handles, not Gramps IDs: JSON array [\"h1\",\"h2\"], one handle, or a comma/semicolon/newline-separated string. To show only part of an image, such as one record on a page scan, give an object {\"ref\":\"…\",\"region\":[left, top, right, bottom]} in place of the handle. A region is [left, top, right, bottom]: its edges in percent of the image width and height, 0 to 100, measured from the top-left corner; [10, 20, 60, 45] runs from 10% to 60% across and from 20% to 45% down. [0, 0, 100, 100] shows the whole image again; read_media with the same region shows what it covers."
  2. Changed1 schema field changedv2.3.2
    • changedInput schema / properties / attributes / description
      Previous value: -"Attributes: JSON array of objects {type,value,...}, or strings \"Type: Value\" (first colon), or one string with lines or | between entries. Full grammar: gramps://input-guide."New value: +"Attributes: JSON array of objects {type,value,...}, or strings \"Type: Value\" (first colon), or one string with lines or | between entries. A type must be a standard Gramps attribute type or a custom one the tree already uses; anything else is rejected with suggestions. Full grammar: gramps://input-guide."
  3. Changed9 schema fields changedv2.3.0
    • changedInput schema / properties / citationHandles / description
      Previous value: -"Citation handles (optional). Handles: JSON array [\"h1\",\"h2\"], a single handle as a plain string, comma/semicolon/newline-separated list, or a JSON-array string. Array entries may be strings or objects {\"ref\":\"…\"} / {\"handle\":\"…\"}."New value: +"Citations supporting the event. Handles, not Gramps IDs: JSON array [\"h1\",\"h2\"], one handle, or a comma/semicolon/newline-separated string; entries may also be objects {\"ref\":\"…\"}."
    • changedInput schema / properties / date / description
      Previous value: -"Optional event date text. Date format: use ISO dates (1990-03-15), year-only (1920), or modifiers (before 1920, about 1950). Add the calendar at the end for Old Style and other calendars: 1856-07-20 (Julian). See gramps://input-guide resource or call get_reference(topic: \"input-guide\", section: \"dates\") for full syntax."New value: +"When it happened, optional. Date text: 1856-07-20, 1920-05, 1920, 1 Jul 1919, about/before/after 1920, 1800-1850, between … and …; append the calendar for other calendars, e.g. 1856-07-20 (Julian). Unreadable dates are rejected."
    • changedInput schema / properties / description / description
      Previous value: -"Event description (optional)"New value: +"Short description, optional."
    • changedInput schema / properties / eventType / description
      Previous value: -"Event type key from the tree. Type values are validated by the server; see gramps://types resource or call get_reference(topic: \"types\") for available values."New value: +"Event type, e.g. Birth, Baptism, Death, Burial, Marriage, Residence, Occupation. Must be a standard Gramps type or a custom one the tree already uses; anything else is rejected with suggestions. List: get_reference(topic: \"types\")."
    • changedInput schema / properties / isPrivate / description
      Previous value: -"Mark record private (default: false)"New value: +"Mark the event private (default false)."
    • changedInput schema / properties / mediaHandles / description
      Previous value: -"Media handles (optional). Handles: JSON array [\"h1\",\"h2\"], a single handle as a plain string, comma/semicolon/newline-separated list, or a JSON-array string. Array entries may be strings or objects {\"ref\":\"…\"} / {\"handle\":\"…\"}."New value: +"Media. Handles, not Gramps IDs: JSON array [\"h1\",\"h2\"], one handle, or a comma/semicolon/newline-separated string; entries may also be objects {\"ref\":\"…\"}."
    • changedInput schema / properties / noteHandles / description
      Previous value: -"Note handles (optional). Handles: JSON array [\"h1\",\"h2\"], a single handle as a plain string, comma/semicolon/newline-separated list, or a JSON-array string. Array entries may be strings or objects {\"ref\":\"…\"} / {\"handle\":\"…\"}."New value: +"Notes. Handles, not Gramps IDs: JSON array [\"h1\",\"h2\"], one handle, or a comma/semicolon/newline-separated string; entries may also be objects {\"ref\":\"…\"}."
    • changedInput schema / properties / placeHandle / description
      Previous value: -"Place handle for this event. Optional. Handle or Gramps ID (e.g. I0001). Handles are opaque strings from the API. Gramps IDs (like I0001, F0023) are auto-resolved to handles. Find handles with search() or list_objects()."New value: +"Where it happened, optional; the place must exist (create_place). Handle or Gramps ID (e.g. I0001), resolved automatically; find it with search or list_objects."
    • changedInput schema / properties / tagHandles / description
      Previous value: -"Tag handles (optional). Handles: JSON array [\"h1\",\"h2\"], a single handle as a plain string, comma/semicolon/newline-separated list, or a JSON-array string. Array entries may be strings or objects {\"ref\":\"…\"} / {\"handle\":\"…\"}."New value: +"Tags. Handles, not Gramps IDs: JSON array [\"h1\",\"h2\"], one handle, or a comma/semicolon/newline-separated string; entries may also be objects {\"ref\":\"…\"}."
  4. First observedv2.2.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare a non-idempotent, non-destructive write, and the description goes well beyond them by disclosing the return payload (handle, Gramps ID, type), validation-before-save on bad type/date, sequential writes, edit-permission requirements, and rate-limit retry behavior. However, a large share of the text is domain modelling advice about eventRefs roles and date ranges rather than behavior of this call, so the behavioral disclosure, while above the annotated baseline, is diluted.

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

Conciseness3/5

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

The purpose is front-loaded, but the paragraph is long and mixes creation mechanics with genealogy modelling rules about Primary roles, birth/death pairing, and shared citations. Useful content, yet the agent must wade through domain lore to reach the operational facts about return values and rate limits.

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?

With ten parameters, no output schema, and one required field, the description covers the return shape, failure modes, and attachment workflow adequately. The only gap is that the formats of every argument are deferred to get_reference(topic: "input-guide") rather than summarized inline.

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; the description exceeds it by explaining that a range like 1890-1900 means a single occurrence within that span versus 'from 1890 to 1900' for a duration, and that placeHandle requires an existing place. It also clarifies that citation/note/media/tag payloads belong to the shared event while participant-specific data belongs on eventRefs, which the schema alone does not convey.

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?

Opens with a specific verb and resource — 'Create a standalone event' — and immediately enumerates the payload it carries (date, place, description, citations, notes, media). The word 'standalone' plus the later 'The event is linked to nobody yet' cleanly separates it from create_records and update_event.

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

Usage Guidelines5/5

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

Explicit routing is given throughout: attach via update_person or update_family with eventRefs/linkMode add, find the place with search or create_place, modify with update_event, and use create_records for several interlinked new records. It even states the precondition exception (data that must be created atomically) that selects the alternative tool.

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