Skip to main content
Glama
ball2jh

fold3-com-mcp

by ball2jh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Fold3 collections

fold3_collection
Read-onlyIdempotent

Find military records by searching collection titles, retrieving collection details, and browsing hierarchical categories to narrow to specific files.

Instructions

Fold3's collections ("titles", about 1,000). Actions:

  • list: collections whose title contains all the given words (name), with record counts, e.g. name "1812 pension" or "Confederate Tennessee".

  • get: one collection (needs collectionId): full title, description, source and NARA publication/catalog numbers, access level (free or subscription), record count, browse levels.

  • browse: walk a collection's browse tree (needs collectionId; path = labels chosen so far). War of 1812 Pension Files: [] → states, ["South Carolina"] → surnames, ["South Carolina","Hunt"] → given names, ["South Carolina","Hunt","Joseph"] → the file(s) with ids. Levels list up to 5,000 entries; contains narrows a long level.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNolist: words in the collection title
pathNobrowse: the labels chosen so far, top level first, e.g. ["South Carolina","Hunt"]
countNolist/browse: items per call (list default 50, browse default 100)
startNoPaging offset: index of the first item to return (default 0)
actionYeslist · get · browse
containsNobrowse: only entries whose label contains this text
collectionIdNoget/browse: collection id, e.g. "761"

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral detail beyond that: record counts for list, returned fields for get, browse-level limits up to 5,000 entries, and the narrowing effect of the contains parameter. No contradictions with annotations exist.

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?

The description is well-organized into a compact bullet list with no wasted words. Each action gets a focused line, examples are embedded efficiently, and the browse-tree traversal example communicates a complex idea in a concise form.

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 tool with three actions and seven parameters, the description covers the main behaviors, parameter relationships, and return highlights well. It could be slightly more complete by explicitly noting pagination semantics for list versus browse, but the schema already documents start and count, so the description is largely sufficient.

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 meaningful parameter semantics: it maps actions to their required parameters, explains path as labels chosen so far, and gives concrete examples such as name="1812 pension" and path=["South Carolina","Hunt"]. This goes beyond the schema's isolated property descriptions.

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?

The description names a specific resource (Fold3 collections) and enumerates three concrete actions: list, get, and browse. Each action is tied to a clear verb and resource, and the examples make it easy to tell this tool apart from siblings like fold3_search or fold3_record.

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

Usage Guidelines4/5

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

The description provides clear context for each action, including which parameters each action needs and illustrative use cases. It does not explicitly name sibling tools or state when not to use this tool, but the action-specific guidance leaves little ambiguity.

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