Skip to main content
Glama
ianderso

gramps-evidence-mcp

by ianderso
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

update_url

DestructiveIdempotent

Correct or remove one existing URL entry on a person, place, or repository in a Gramps Web tree. Fix a Find a Grave link filed under the wrong type.

Instructions

Edit or remove ONE existing URL entry on a person, place, or repository.

add_url can only append -- this corrects an entry already there (the classic case: a Find a Grave link filed under the wrong type). The other fields on the object are untouched.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoNew URL path. Omit to keep.
matchYesCase-insensitive substring identifying WHICH url entry to edit, tested against each entry's path and description (e.g. 'findagrave.com/memorial/123'). Must match exactly one entry; matching none or several returns the candidate list instead of guessing.
removeNoRemove the matched entry instead of editing it.
targetYesHandle or gramps_id of the object.
url_typeNoNew URL type, e.g. 'Web Home', 'Web Search', or a custom type the tree already has. Omit to keep.
descriptionNoNew link description. Omit to keep.
object_typeYesType of the object: 'person', 'place', or 'repository' only.
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. Changed2 schema fields 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"
+}
    • changedInput schema / properties / url_type / description
      Previous value: -"New URL type, e.g. 'Find A Grave', 'Web Home Page'. Omit to keep."New value: +"New URL type, e.g. 'Web Home', 'Web Search', or a custom type the tree already has. Omit to keep."
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (destructiveHint=true, idempotentHint=true, readOnlyHint=false). The description adds genuinely new context beyond them: only one entry is touched and 'the other fields on the object are untouched,' clarifying the partial-update semantics of a mutation. It stops short of describing removal consequences or return behavior, but with annotations carrying safety that gap is minor.

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 short sentences, front-loaded with the core action, then sibling routing, then a scope note. Every sentence earns its place; nothing is redundant with the schema or annotations.

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 an eight-parameter mutation tool with full schema coverage, no output schema, and annotations covering the safety profile, the description supplies everything an agent needs: what it does, when to choose it over add_url, and that untouched fields are preserved. Parameter-level detail is correctly delegated to the schema.

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 eight parameters including the match, allow_new_type, and omit-to-keep semantics. The description adds no syntax or format detail beyond what the schema provides; its only contribution is the illustrative miscategorized-link case. Baseline 3 is correct when the schema does the heavy lifting.

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 (edit/remove), a specific resource (ONE existing URL entry), and the exact scope (on a person, place, or repository). It also explicitly distinguishes itself from the sibling tool add_url, so an agent can tell them apart 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?

Names the alternative (add_url) and the condition that selects between them: add_url only appends, so this tool is for correcting an entry already present. The 'Find a Grave link filed under the wrong type' example makes the intended use case concrete rather than inferred.

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