Wedding crosswords, newspaper templates, and printing guidance in English and French.
Scored across 3 tools
Each tool targets a clearly distinct action and resource: browsing templates, generating a crossword, and reading printing guidance. There is no meaningful overlap in purpose or expected inputs.
All three names follow a consistent verb_noun pattern: find_wedding_templates, generate_wedding_crossword, and get_printing_guide. The convention is predictable and readable.
Three tools is slightly thin but well-scoped for a narrow wedding-paper utility server. Each tool has a clear, non-redundant role, though the surface feels close to minimal.
The set covers template discovery, crossword creation, and printing guidance, but lacks ordering, saving, or post-generation editing operations. Agents may hit dead ends when users want to purchase or revise a generated item.
Find My Wed Paper wedding newspaper templates, real previews, and available four- or eight-page editions. Filter by a template ID or page count.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | ||
| locale | No | en | |
| pageCount | No |
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 clear. The description adds that previews and four/eight-page editions are available, but does not cover return format, auth needs, or rate limits, and it mentions a template ID filter that is not in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the core purpose front-loaded. Minor marketing phrasing ('real previews') is not harmful, but the reference to a nonexistent template ID makes the brevity less effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with three undocumented parameters and no output schema, the description is incomplete. It should explain the style and locale filters, and it incorrectly suggests a template ID parameter that the schema does not support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It partially covers pageCount by mentioning four- or eight-page editions, but it omits the style and locale parameters entirely and references a nonexistent template ID filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: find wedding newspaper templates, with previews and page editions. This is clear enough to distinguish it from the sibling generate/get tools, though it does not explicitly reference those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through filtering by template ID or page count, but it gives no explicit guidance on when to choose this over the sibling tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a complete connected crossword with numbered clues, its answer grid, and a 24-hour link to edit and print. Supply 2–12 different answers with 2–20 letters each. Latin accents and spaces are normalized to grid letters; spell out numbers and dates.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| locale | No | en | |
| entries | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior the annotations cannot: the output includes a 24-hour expiring edit/print link, and inputs are normalized (accents, spaces) with numbers and dates to be spelled out. It doesn't say whether identical inputs yield identical puzzles or what happens on validation failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: output description front-loaded, then input shape, then normalization caveats. Every sentence carries information an agent needs and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations on return values, the description does the work of explaining what comes back (clues, grid, expiring link). What's missing is documentation of title and locale and any failure behavior, which for a 3-parameter tool is a modest but real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it partially does: it explains the entries array bounds (2–12 answers, 2–20 letters) and normalization rules for answer text. It never mentions the title or locale parameters, leaving a third of the surface undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Build a complete connected crossword') and enumerates the deliverables: numbered clues, answer grid, and a 24-hour edit/print link. It is clearly distinct from the sibling tools find_wedding_templates and get_printing_guide, which cannot generate puzzles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives input constraints (2–12 answers, 2–20 letters) and a spelling convention, which implies how to prepare a request, but it never says when this tool should be chosen over the siblings or what to do if input doesn't fit the constraints. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read current My Wed Paper guidance for paper dimensions, print files, and home or professional printing. Select US Letter, A4, or Newspaper Club digital tabloid.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | en | |
| paperSize | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds that the guidance is 'current' (i.e., live content that may change) and enumerates the topics covered, but says nothing about response shape, caching, or whether content varies by locale.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the core purpose front-loaded before the parameter selection hint. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does enumerate what the returned guidance covers (paper dimensions, print files, printing methods), which is enough for an agent to know what it gets back. The only real gap is the silent locale parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description has to carry the parameter burden. It does map the paperSize enum to human labels ('US Letter, A4, Newspaper Club digital tabloid'), which is genuinely useful, but the locale parameter (en/fr) — which presumably changes the language of the guidance — is never mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Read current My Wed Paper guidance' scoped to paper dimensions, print files, and home/professional printing. It is clearly distinct from its siblings (template search, crossword generation) by domain, though it never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence ('Select US Letter, A4, or Newspaper Club digital tabloid') steers the invocation choice at the parameter level, but there is no guidance on when to call this versus anything else, no prerequisites, and no exclusions. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_wedding_templatesgenerate_wedding_crosswordget_printing_guidePersonalised printable crosswords with a hidden solution word for birthdays, weddings and couples
Word searches, crosswords, sudoku and Unicode text styles in 6 languages, accents kept.
Find published word searches, crosswords and mazes with matching Letter and A4 PDF files.
Find wedding venues and vendors, estimate costs, and manage guests, events and wedding details.
Add one secure layer between your agents and this server.