Skip to main content
Glama
Sign In
Scormave

Gramps Web MCP

by Scormave
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Get Object

get_object
Read-only

Read one Gramps Web record in full by Gramps ID or handle, including its fields, links, and backlinks. Use it when you already know the record identifier; search or list records to find one first.

Instructions

Read one record in full: its fields, its links to other records, and the records that point to it (backlinks, read-only here). Use it once you know the Gramps ID or handle; to find a record by text use search, to browse a type use list_objects, and for a person's relatives or dated events get_person_tree and get_timeline are shorter. A Gramps ID names its type by prefix, so objectType is needed only with a handle, and an objectType that disagrees with the prefix is rejected rather than guessed. extended (people and families only) puts each event's date and place on its line, names the others in an event where the person is not Primary, such as a child's birth, and adds note text, tag names, citations and media in the same call. Returns plain text for one record, without paging: a header with its type, label, handle and Gramps ID, then its fields, its links one per line with label, handle and, for events, the role, and "Referenced by" sections for the backlinks. A missing record returns a not-found message with a hint.

Input Schema

NameRequiredDescriptionDefault
extendedNoPeople and families only: also resolve the linked records (event dates and places, note text, tag names, citations, media) in the same call; default false is faster. Rejected for other types.
identifierYesGramps ID (e.g. I0001) or handle. ID prefixes give the type: I person, F family, E event, P place, S source, C citation, N note, O media, R repository, T tag.
objectTypeNoRecord type: person, family, event, place, source, citation, note, media, repository or tag. Omit for a Gramps ID; required for a handle.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.3.0
    • changedInput schema / properties / extended / description
      Previous value: -"For person and family only: resolve linked objects inline. Default: false."New value: +"People and families only: also resolve the linked records (event dates and places, note text, tag names, citations, media) in the same call; default false is faster. Rejected for other types."
    • changedInput schema / properties / identifier / description
      Previous value: -"Object handle or Gramps ID (e.g. I0001). Gramps ID prefixes: I person, F family, E event, P place, S source, C citation, N note, O media, R repository, T tag."New value: +"Gramps ID (e.g. I0001) or handle. ID prefixes give the type: I person, F family, E event, P place, S source, C citation, N note, O media, R repository, T tag."
    • changedInput schema / properties / objectType / description
      Previous value: -"Optional for a Gramps ID, whose prefix determines the type. Required for an opaque handle: person | family | event | place | source | citation | note | media | repository | tag."New value: +"Record type: person, family, event, place, source, citation, note, media, repository or tag. Omit for a Gramps ID; required for a handle."
  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?

Annotations already declare a safe read (readOnlyHint true, destructiveHint false, closed world), yet the description still adds real behavior: backlinks are read-only here, an ID/type mismatch is rejected rather than guessed, extended is additive and limited to people and families, results come back as plain text with no paging, and a missing record yields a not-found message with a hint. That is well past what the annotations carry.

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-loaded with the core action and the routing to siblings before the finer details, and every sentence carries information — no filler. It is a dense single paragraph, though, and the return-format sentence is long enough that an agent must read carefully rather than skim.

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 three-parameter read tool with no output schema, the description covers the remaining burden fully: input validation rules, the extended flag's scope, the shape of the plain-text return including 'Referenced by' sections, and the not-found path. 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 genuine interpretation: objectType is needed only with a handle because a Gramps ID prefix encodes the type, and a disagreeing objectType is rejected. It also explains what 'extended' actually yields for a person whose role in an event is not Primary, which the schema only gestures at.

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 — 'Read one record in full' — and enumerates what full means: fields, links, and backlinks. It also draws a clear boundary against search, list_objects, get_person_tree and get_timeline by name, so an agent can pick it without opening the 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 an explicit entry condition ('once you know the Gramps ID or handle') and names the alternatives with the conditions that select them: text lookup goes to search, type browsing to list_objects, relatives/dated events to get_person_tree and get_timeline because they are 'shorter'. Both when-to-use and when-not-to-use are covered.

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