Skip to main content
Glama

fetch

Read-onlyIdempotent

Fetch the full SwiftProbate reference record for an id returned by search (a state overview, county court guide, institution notification guide, or a jurisdiction's forms).

Input Schema

NameRequiredDescriptionDefault
idYesAn id from a `search` result, e.g. 'county:california:alameda'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / id / maxLength
      Added value: +200
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered; the description adds the useful behavioral fact that this returns the *full* record (implied: more than the `search` summary) and lists the four record categories. It does not say what happens for an unknown or stale id, which is the main remaining gap.

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?

One sentence, front-loaded with the verb and resource, with the provenance constraint and the record-type enumeration packed into a single parenthetical. Nothing is wasted and nothing is buried.

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 one-parameter read-only fetch with full schema coverage and no output schema, the description supplies what the agent needs: where the id comes from and what class of record it returns. Only the not-found / invalid-id behavior is missing, which keeps it from a 5.

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% and the single id parameter already carries an example and its provenance ('An id from a `search` result'). The description restates that provenance but adds no format, validation, or failure semantics beyond the schema, so baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description pairs a specific verb ('Fetch') with a specific resource ('full SwiftProbate reference record') and enumerates the record types it can return, so the agent knows exactly what comes back. It falls short of a 5 because it does not distinguish itself from apparent look-alike siblings such as get_state_overview, lookup_county_guide, or lookup_institution_guide, which the enumerated record types overlap with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the precondition clearly: the id must come from a `search` result. That is real usage guidance. However, it gives no exclusion against the several siblings that appear to retrieve the same kinds of content directly by name/state, so an agent cannot tell from this text when fetch is preferred over get_state_overview or lookup_county_guide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources