Skip to main content
Glama

Sync many prompts' FAQ answers

sync_prompt_answers
DestructiveIdempotent

Set the FAQ answers of up to 100 tracked prompts in one transaction, e.g. from a release that keeps its answers in a repository. items is [{ queryId or query, answer, expectedHash? }]. query matches a tracked prompt by its text with case and spacing ignored — the query or the faqQuestion list_prompts returns, a dimension variant included; a text that matches several tracked prompts is refused for that item with reason ambiguous-query and their candidateQueryIds (send one as queryId). A prompt that is not tracked is tracked first, under add_prompt's quota; an archived one with that text is revived (revived: true, its history continues), except one that was replaced by a reworded prompt (refused, reason replaced, with replacedByQueryId) or one tracked only as an archived variant (refused, reason archived-variant). A created prompt whose automatic checks start in a later month carries automaticChecksFrom, as add_prompt does. Every item is checked with set_prompt_answer's rule before anything is written: one invalid item — or the same prompt twice — refuses the whole batch with { ok: false, reason: "invalid", index, field, max }. dryRun: true returns exactly what the run would do and writes nothing. A real run needs idempotencyKey (≤200 characters) — one idempotencyKey per batch, e.g. - such as "v4.2-1", since a release of more than 100 answers is several batches. Only a run in which every item applied (unchanged, changed or created) is kept under its key: the same key with the same request again returns that first result and writes nothing, and the same key with a different request is refused with reason idempotency-mismatch. A run with a conflict, a refusal or a missing prompt is not kept, so after fixing the cause the same key runs again. A kept key lives 7 to 14 days (records older than 7 days are pruned weekly). Returns items [{ index, queryId, status, answerHash, previousHash, reason? }] and counts; status is unchanged, changed, created (would-create in a dry run), missing (no such tracked prompt), conflict (the stored answer's hash is not the item's expectedHash; nothing written for it) or refused (with its reason: add_prompt's, e.g. over-quota, or one above). answerHash is the item's answer after the run, previousHash before it. An unchanged item records nothing; each change is recorded with source in the answer's history, as set_prompt_answer records it.

Input Schema

NameRequiredDescriptionDefault
itemsYes
dryRunNotrue: say what would happen, write nothing (default false).
siteIdNoOptional on a connected app: the site chosen with select_site is used. If given, it must be that site. With an API key it is required: a site id from list_sites.
sourceNoOptional label for these writes (≤100 characters), e.g. "ci:release-4.2".
idempotencyKeyNoRequired for a real run (≤200 characters): one per batch, e.g. <release>-<batch>; resend the same key when you retry that batch.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the destructive/idempotent annotations, the description discloses transactional all-or-nothing behavior, whole-batch refusal on one invalid item, tracking and revival semantics for untracked/archived prompts, conflict detection via expectedHash, idempotency-key retention and mismatch behavior, and history recording. These are meaningful behavioral details an agent could not infer from annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is valuable and mostly earnable, but it is delivered as one dense paragraph with long run-on sentences and parentheses, making it harder to scan than necessary. It is front-loaded with the purpose, but the structural density costs readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex bulk-write tool with five parameters and no output schema, the description covers return statuses, counts, hash fields, refusal reasons, idempotency retention, and edge cases in enough detail for an agent to call and interpret it correctly. Nothing essential appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is already 80%, the description adds substantial meaning: query matching ignores case and spacing, ambiguous text is refused with candidateQueryIds, expectedHash produces a conflict with no write, dryRun returns the exact planned result, and idempotencyKey governs replay and mismatch behavior. These semantics go well beyond the field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Set the FAQ answers of up to 100 tracked prompts in one transaction.' This clearly distinguishes the batch operation from the singular set_prompt_answer and from add_prompt, and an agent can identify the tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong context for bulk syncing, including a release-with-repository-answers example, dry-run-first behavior, and idempotency-key-per-batch guidance. It references set_prompt_answer and add_prompt rules but does not explicitly say 'use set_prompt_answer for a single answer' or name other alternatives, so routing is clear but not exhaustively 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.