Skip to main content
Glama

letters_templates

Read-only

Retrieve dispute letter templates, verified consumer reporting agency contacts, and disclaimer text before drafting credit-report dispute letters.

Instructions

The letter templates, the agencies with checked contact details, and the disclaimer. Read this before generating a letter.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
agenciesYesOnly contact details checked on the official site are shown.
templatesYes
disclaimerYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds that this is prerequisite context for letter generation, which is useful, but says nothing about response size, whether data is bundled or paged, or how fresh the contact details are.

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?

Two short sentences with no filler, and the imperative 'Read this before generating a letter' is placed last where it acts as a call to action. The noun-list opening is slightly dense but every item is informative.

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?

An output schema exists, so return-value details are not the description's burden, and the tool has no parameters to document. The one gap is that it doesn't hint at the shape or volume of the bundled data, but for a zero-arg reference fetch with an output schema this is adequate.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-arg tool applies. The description correctly implies no inputs are required by framing it as a fetch of existing reference data.

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 enumerates the exact resources returned: letter templates, agencies with verified contact details, and the disclaimer. It is clearly distinguishable from the sibling letters_generate (which produces output) since this one is framed as reference data to read first. It lacks an explicit verb like 'retrieve/list', but the enumerated content makes the purpose unambiguous.

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?

'Read this before generating a letter' gives explicit sequencing relative to letters_generate, which is the actionable guidance an agent needs. It does not state when-not to call it or mention alternatives, so it falls short of a full 5.

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