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

With no annotations, the description carries the full burden and does substantial work: it explains that a plain find returns only the published main-table state, that drafts are hidden unless draft:true, that public read is exposed via /api/agents, and it flags that MCP deletes are PERMANENT hard-deletes the admin Trash will not catch. The delete/capability chatter is largely irrelevant to a find tool and risks misleading an agent about what this call can do.

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?

The valuable scoping facts (required fields, draft behavior) are reasonably front-loaded, but the text degenerates into a fragment chain that mixes in inapplicable material — the delete permanence warning and the 'MCP capabilities' list belong to other operations, not this query tool. Several sentences could be cut without losing information an agent needs to call findFaqs.

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 10-parameter, annotation-free query tool with no output schema, the description supplies the context that matters most: draft/publish semantics, locale handling, relationship population via categories, and the writing-guidelines prerequisite. Return shape and pagination defaults are delegated to a fully documented schema, so little an agent needs is missing.

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 100%, so the baseline is 3, but the description earns a bump by explaining semantics the schema does not: `draft` switches between the versions table and the published main-table state, and `_status` values control visibility. It also ties `locale` to the getWritingGuidelines call. `where`, `sort`, `select`, and pagination are left entirely to the schema, which is acceptable given full coverage.

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 opening "FAQ entries." is a bare noun fragment rather than a verb+resource statement, and the explicit verb only appears buried in "MCP capabilities: find, create, update, delete", which lists operations this find tool likely does not perform. The field inventory (question, answer, categories) and the "a find WITHOUT draft:true..." clause do let an agent infer it queries the faqs collection, and the find* sibling family makes the resource obvious.

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?

It gives concrete operational rules: use `_status:"published"` to go live, use `draft:true` to reach the versions table, and it names two alternatives with the condition that selects them — `schedulePost` for scheduling and `getWritingGuidelines` before writing public text. What is missing is any statement of when to prefer this over the sibling finders (findPages, findPosts, etc.).

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