Skip to main content
Glama
Scormave

Gramps Web MCP

by Scormave
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Get Timeline

get_timeline
Read-only

List dated events around a person, family, or place in date order to check life sequences or gaps, with filters for event category and dates.

Instructions

List the dated events around one person, family or place in date order: 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. Filter by event category and dates. 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

TableJSON 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.6/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnlyHint), so the description must carry behavioral burden and it does: it discloses that an undated person timeline pulls relatives' events across their whole lives including before the person's birth and after death, and that place timelines are computed from direct event backlinks with child places excluded. These are non-obvious semantics an agent could not infer from annotations or schema.

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?

Dense but front-loaded: purpose and returned fields come first, then sibling routing, then filtering and edge-case semantics. Every sentence carries information, though the description runs long and could be trimmed slightly without loss.

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?

No output schema exists, but the description compensates by naming the returned fields and covering the tricky cases (undated person timelines, place-backlink computation, date filtering behavior). Nothing essential for correct invocation 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 already documents all six parameters in detail (date syntax, category enums, relative roles). The description adds only a high-level 'Filter by event category and dates' plus the dates-narrowing hint, which is largely redundant with 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 and resource ('List the dated events around one person, family or place in date order') and enumerates the returned fields (date, event type, place, whose event, Gramps IDs). It also names the sibling tools it is not (get_object, get_person_tree, get_relations), so an agent can disambiguate without opening any 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?

Explicitly routes: 'for the full record use get_object, for ancestors or descendants use get_person_tree, for how two people are related use get_relations', plus the positive use case ('check a life's sequence or gaps'). Both when-to-use and when-to-use-something-else are stated.

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