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

Annotations already cover readOnly, idempotent, non-destructive, closed-world, so the safety profile is done. The description adds real context beyond that: the result set is bounded by the server's enabled events/creative IDs, and output is posters/demos rather than personalized drafts. It omits pagination/limit behavior for the cursor, which keeps it from a 5.

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?

Front-loaded with the core action and scope, and the 'not personalized drafts' caveat is well placed. Mild redundancy in restating the language rule ('Every design suits every language' followed by the fr/en naming rule) that could be merged into one sentence.

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?

Five optional parameters at 20% coverage and no output schema means the description should explain the query/occasion/search-surface semantics and pagination. It does not, leaving an agent guessing how to construct a useful search beyond picking a language.

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 only 20%, so the description must carry the other four parameters and does not. It explains language (restating the schema's own enum description almost verbatim) but never says what 'query' matches, what 'occasion' filters on, what 'limit' defaults to, or how 'cursor' pages.

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: 'Search public animated card designs from the events and creative IDs currently enabled in the server MCP card catalog configuration.' The closing line 'Returns posters and design demos, not personalized drafts' clarifies it is a catalog browse, not a personal draft lookup, which implicitly separates it from get_ecard/list_ecards. No sibling is named explicitly, so it stops short of a 5.

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?

Use is implied rather than stated: an agent can infer this is the discovery step before prepare_ecard or send_ecard because it returns designs, not personalized drafts. There is no explicit 'use this when' or 'do not use this for' statement, and no mention of alternatives among the seven siblings.

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