Skip to main content
Glama
Sign In
Scormave

Gramps Web MCP

by Scormave
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Get Timeline

get_timeline
Read-only

List a person's, family's or place's events in date order, grouped by decade, to spot life sequence gaps. Filter by dates and event categories.

Instructions

List the events around one person, family or place in date order, grouped by decade with undated ones last: date, event type, place, and whose event it is, with Gramps IDs. Use it to check a life's sequence or gaps; for the full record use get_object, for ancestors or descendants use get_person_tree, for how two people are related use get_relations. events filters the subject's own events and relativeEvents those of the relatives chosen in relatives (person timelines only, rejected otherwise); dates narrows both. Without dates, a person timeline lists relatives' events from their whole lives, also before the person's birth and after their death; pass dates to narrow it. Place timelines are computed from direct event backlinks; child places are not included.

Input Schema

NameRequiredDescriptionDefault
datesNoOnly events in these dates, written like any date: a year (1850), month (1850-03), day, or range (1850-1860, between 1850-03 and 1851). from and to include the date, before and after leave it out: from 1850, before 1900-05-01. Other calendars are converted: 1856-07-20 (Julian). The Gramps Web form 1850/1/1-1860/12/31 also works. Approximate dates (about, estimated) are rejected.
eventsNoOnly these event categories (omit for all): vital, family, religious, vocational, academic, travel, legal, residence, other, custom.
relativesNoPerson timelines only: whose events to add: father, mother, brother, sister, wife, husband, son, daughter.
identifierYesThe person, family or place. Handle or Gramps ID (e.g. I0001), resolved automatically; find it with search or list_objects.
objectTypeYesWhose timeline: person, family or place.
relativeEventsNoPerson timelines only: event categories to show for those relatives, same values as events.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.3.0
    • changedInput schema / properties / events / description
      Previous value: -"Event categories: vital, family, religious, vocational, academic, travel, legal, residence, other, custom."New value: +"Only these event categories (omit for all): vital, family, religious, vocational, academic, travel, legal, residence, other, custom."
    • changedInput schema / properties / identifier / description
      Previous value: -"Person, family, or place handle or Gramps ID."New value: +"The person, family or place. Handle or Gramps ID (e.g. I0001), resolved automatically; find it with search or list_objects."
    • changedInput schema / properties / objectType / description
      Previous value: -"Timeline owner type: person | family | place."New value: +"Whose timeline: person, family or place."
    • changedInput schema / properties / relativeEvents / description
      Previous value: -"For person only: event categories for the listed relatives."New value: +"Person timelines only: event categories to show for those relatives, same values as events."
    • changedInput schema / properties / relatives / description
      Previous value: -"For person only: include events of father, mother, brother, sister, wife, husband, son, or daughter."New value: +"Person timelines only: whose events to add: father, mother, brother, sister, wife, husband, son, daughter."
  2. First observedv2.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the readOnly/destructive annotations by disclosing cross-parameter interactions and edge cases: events/relativeEvents apply only to person timelines and are 'rejected otherwise', dates narrows both, and without dates relatives' whole-life events appear including before birth and after death. It also notes place timelines derive from direct event backlinks and exclude child places.

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?

Front-loads the core purpose and return shape, then layers in routing and parameter behavior. It is dense and slightly long as a single paragraph, but every sentence carries distinct, useful information rather than filler.

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?

For a 6-parameter read tool with no output schema, the description covers what the tool returns (fields and ordering), how each parameter interacts, and the key default/edge cases. Nothing an agent needs to call it correctly is missing.

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, but the description adds real cross-parameter semantics the schema cannot express: how events vs relativeEvents partition subject-vs-relative events, the rejection condition for non-person timelines, and the surprising default when dates is omitted.

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 and resource (list events around a person/family/place in date order) and even specifies the grouping (by decade, undated last) and returned fields (date, event type, place, whose event, with Gramps IDs). It explicitly distinguishes itself from get_object, get_person_tree, and get_relations.

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 explicit when-to-use ('check a life's sequence or gaps') and names three alternatives with the condition that selects each ('for the full record use get_object', 'for ancestors or descendants use get_person_tree', 'for how two people are related use get_relations'). Nothing is left to inference.

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