Skip to main content
Glama

Add Lingard Words To Collection

lingard_add_words_to_collection

Adds cards to an existing Lingard collection, deduplicating by normalized word title; commit=true writes them. Only collections with writable="full" accept new cards: curated Lingard collections are read-only and the unfiled bucket takes no new cards. Unless allowIncompleteCards is true, a new card needs title, translate, pos, pron/ipa, syns, and examples with translations; image is optional. A German or Romance noun title carries its dictionary article when one is used, e.g. der Hund, die Reise, das Haus. In example text and example translation the target word and the translated word are marked with {}. form is not part of speech: it holds the inflected-form category of the current word and stays empty for base forms. It only adds: a word already in the collection gets its empty fields filled (mergeMode "fill_missing", the default) or is left alone ("add_only"); a value that is already filled in is never changed or cleared.

Input Schema

NameRequiredDescriptionDefault
cardsYes
commitNo
mergeModeNoWhat to do with a word that is already in the collection: "fill_missing" (default) fills its empty fields, "add_only" leaves it as it is.
targetLangYes
collectionUuidNo
collectionTitleNo
allowIncompleteCardsNoDefault false. True marks the cards as a sparse import that the user asked for; it lets them through without the complete-card fields (everything except image, the dictionary article on a German/Romance noun title, {} highlights in examples).

Output Schema

NameRequiredDescriptionDefault
okYes
changesYes
payloadYes
summaryYes
committedNo
mergeModeNo
collectionYes
targetLangYes
upsertResultNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior1/5

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

The description richly discloses write behavior, deduplication, writable-collection constraints, completeness requirements, and merge semantics. But its guarantee that it deduplicates by normalized title and never changes or clears already-filled values conflicts with the annotation idempotentHint=false, so this is an annotation contradiction.

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?

Despite its length, the description is front-loaded with the core action and then adds necessary constraints in a dense, purposeful paragraph. The detail is justified by the complexity of the card model and merge behavior.

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?

The description is substantial for a complex write tool, and an output schema exists so return values need not be explained. The main remaining gaps are collection identification and explicit routing against sibling preview/fill/commit tools.

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 description coverage is low at 29%, but the description compensates for many key parameters by explaining commit behavior, mergeMode defaults, allowIncompleteCards, writable collection constraints, noun articles, and {} example markers. It still leaves top-level collectionUuid, collectionTitle, and targetLang less explained than an agent might want.

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 a specific verb and resource: adding vocabulary cards to an existing Lingard collection, with deduplication by normalized word title. It is clear about scope, but it does not explicitly distinguish itself from close siblings such as lingard_fill_missing_card_fields or the preview/commit workflow.

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?

The description gives important preconditions: only writable="full" collections accept new cards, curated collections are read-only, and commit=true writes them. However, it does not explicitly say when to use this tool versus lingard_fill_missing_card_fields, lingard_preview_vocab_changes, or lingard_commit_vocab_changes.

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