Skip to main content
Glama
ianderso

gramps-evidence-mcp

by ianderso
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

add_event_ref

Link an existing event to another person in a role, so shared citations and corrections cover everyone involved.

Instructions

Share an existing event with another person, in a role.

For one census entry, residence or burial that several people took part in: each references the same event, so its citations and later corrections serve all of them. Refused if the person already has it; update_event_ref edits that reference. A new fact is add_event_to_person.

Input Schema

NameRequiredDescriptionDefault
roleNoThe person's role in it: 'Primary', 'Witness', 'Informant', 'Godparent', 'Family', 'Clergy', or a custom role the tree already has.Primary
eventYesHandle or gramps_id of the EXISTING event, e.g. 'E0007'.
personYesHandle or gramps_id of the person to add the event to.
attributesNoAttributes of this person's reference: what is theirs alone, e.g. {'As enumerated': '<their line on the sheet>', 'Age': '34'}. A name is matched against standard names, the tree's, and those on the event's other references.
allow_new_typeNoAccept a type that is neither a Gramps standard type nor one of the tree's custom types, creating it as a new custom type. Only when meant: a near-miss is refused with the closest names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.3.0
    • addedInput schema / properties / attributes
      Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Attributes of this person's reference: what is theirs alone, e.g. {'As enumerated': '<their line on the sheet>', 'Age': '34'}. A name is matched against standard names, the tree's, and those on the event's other references."
+}
  2. Changed1 schema field changedv1.2.0
    • addedInput schema / properties / allow_new_type
      Added value: +{
+  "default": false,
+  "description": "Accept a type that is neither a Gramps standard type nor one of the tree's custom types, creating it as a new custom type. Only when meant: a near-miss is refused with the closest names.",
+  "type": "boolean"
+}
  3. Addedv1.0.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare write/not-destructive/not-idempotent, and the description corroborates the non-idempotent profile by stating it is 'Refused if the person already has it.' It also discloses the shared-citation behavior of references, which annotations cannot express. It does not cover permissions/auth or what the call returns, keeping it short of a 5.

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?

Three tight sentences, front-loaded with the verb and resource, then the scenario, then the routing rules. Every sentence carries distinct information with no 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 write tool with no output schema, it covers purpose, the sharing model, refusal behavior, and sibling routing — enough to invoke it correctly. The only omission is any hint of the return value or side effects on the tree, a minor gap given the annotations.

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 role, event, person, attributes and allow_new_type in detail. The description only alludes to the role concept ('in a role') and adds no format or constraint information beyond the schema. 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?

States a specific verb (share/add a reference to) and resource (an EXISTING event) for a person in a role. It explicitly distinguishes itself from the two nearest siblings: 'update_event_ref edits that reference' and 'A new fact is add_event_to_person.' An agent can route correctly without opening either schema.

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?

Gives a concrete when-to-use scenario (a census entry, residence or burial several people took part in) plus the rationale (shared citations and later corrections). It also states the when-not (refused if the person already has it) and names the correct alternatives for that case and for creating a new fact.

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