Skip to main content
Glama

Have It Printed

Letter and postcard options

hip_get_catalog
Read-onlyIdempotent

The options for a postcard or a letter written here: the handwriting-style fonts, the letter types, the stationery designs (with a preview picture each), the postcard sizes and fronts, and the mailing options. Read it before hip_set_postcard or hip_set_letter, and offer the person choices from it; never invent a font, design or front.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds that each stationery design carries a preview picture and imposes a 'never invent' constraint, which is real added context, but it says nothing about catalog size or how the data is organized on return beyond the output schema.

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 tight sentences: the inventory first, then the usage rule. Every clause provides information, though the phrase 'written here' is slightly ambiguous and the sentence is inventory-heavy rather than front-loaded with a verb.

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?

With no parameters, an output schema present, and full annotation coverage, the description only needs to tell an agent when to call it and that the results feed a choice-presentation flow — which it does. Missing only minor details such as catalog size or whether previews are URLs.

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?

Zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The schema is closed with additionalProperties=false, matching the description's implication that the tool takes no inputs.

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 states exactly what the resource contains (fonts, letter types, stationery designs with previews, postcard sizes and fronts, mailing options) and implicitly identifies it as a read-only catalog via 'read it'. It doesn't lead with a clean verb+resource phrase, but the enumeration makes the tool's content unmistakable and distinct from hip_set_postcard/hip_set_letter.

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?

Explicit sequencing ('Read it before hip_set_postcard or hip_set_letter') names the dependent siblings, and it adds a downstream rule ('offer the person choices from it; never invent a font, design or front'). Both when-to-use and the alternative workflow are spelled out.

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