Skip to main content
Glama
Sign In

Convika

by com.convika
OverviewDiscussionsAdmin

Run AI answer check

run_answer_check

Use this tool when the user wants to ask the AIs now whether they mention or link to their brand (ホームページ, Webサイト, ランディングページ): 「AI に聞いてみて」「ChatGPT でうちの名前が出るか今すぐ確かめて」, "run the AI answer check", "check again now".

Asks the workspace's saved questions (update_answer_check_prompts) on ChatGPT, Perplexity, Gemini, and Google AI Overviews. One question on one AI is 1 check: a run of q questions on e AIs uses q × e checks, taken before anything is asked, first from the month's included checks (Pro 100, MAX 500, Free 0; Pro from a reverse trial or included with Made for you has none), then from packs the user bought on the dashboard, oldest first. Only a check whose answer comes back is used: one that errors or comes back empty (such as no AI Overview for the search) is given back.

  • promptIds: ids from get_answer_check_results' prompts; leave it out to ask every saved question. engines: some of chatgpt, perplexity, gemini, overview; leave it out for all four.

  • idempotencyKey: a new id (such as a UUID) for each run the user asks for. If a call times out or fails with no reply, call again with the same key: Convika returns the run it already started (repeated: true) and uses nothing more.

  • Before running, tell the user how many checks the run uses (q × e) and what get_answer_check_results' balance.left says is left; run when they agree.

  • Answers come in over a few minutes (up to about 12 per check); read them later with get_answer_check_results. A workspace has one run at a time: never call this again to wait for answers.

  • not_enough_answers: the run needs more checks than are left. Tell the user the numbers, and that packs are bought on the dashboard's AI & search screen, or ask fewer questions or AIs. run_in_progress: an earlier run is still asking; nothing was used; read its answers with get_answer_check_results and run again once running is 0. check_unavailable: Convika can't ask right now; nothing was used. no_brand / no_prompts: save them first with update_answer_check_prompts.

  • expectedBrandId: with get_brand's id, a connection that now works on another workspace asks nothing and uses no checks (brand_mismatch). Returns the run (answers, fromIncluded, fromPacks, all counted in checks; repeated when the key named an earlier run) and the balance left.

Input Schema

NameRequiredDescriptionDefault
enginesNoThe AIs to ask; leave out for all four
promptIdsNoSaved question ids to ask; leave out to ask all of them
idempotencyKeyNoA new id for this run, such as a UUID; send the same one again only to retry a call that got no reply
expectedBrandIdNoThe workspace's id from get_brand. When the connection now works on another workspace (the dashboard's active workspace was switched), the call changes nothing and answers brand_mismatch.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / expectedBrandId / description
      Previous value: -"The brand's id from get_brand. When the connection now works on another brand (the dashboard's active workspace was switched), the call changes nothing and answers brand_mismatch."New value: +"The workspace's id from get_brand. When the connection now works on another workspace (the dashboard's active workspace was switched), the call changes nothing and answers brand_mismatch."
  2. Changed1 schema field changed
    • addedInput schema / properties / expectedBrandId
      Added value: +{
+  "description": "The brand's id from get_brand. When the connection now works on another brand (the dashboard's active workspace was switched), the call changes nothing and answers brand_mismatch.",
+  "maxLength": 100,
+  "minLength": 1,
+  "type": "string"
+}
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, it discloses a lot: cost accounting (q × e checks taken up front from monthly quota, then purchased packs oldest first), refunds for errored or empty answers, a one-run-per-workspace concurrency limit, latency of up to ~12 minutes, and the meaning of each error code. It also explains idempotency-key retry semantics, which the annotations' idempotentHint=false would otherwise leave unclear. This is exactly the context that annotations cannot carry.

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 trigger phrases and cost rule are front-loaded well, but the paragraph is dense and over-long: billing, refunds, error codes, and idempotency all run together in one block. Some sentences duplicate the schema text ('leave it out for all four'), which does not earn its place.

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?

There is no output schema, so the description must explain returns, and it does: the run object with answers, fromIncluded, fromPacks, repeated, plus the remaining balance. Error states and the pre-run confirmation requirement are all covered, so an agent can call this correctly without further inference.

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 coverage is 100%, so the baseline is 3, but the description adds cross-tool provenance for promptIds (the ids from get_answer_check_results' prompts) and the brand_mismatch consequence for expectedBrandId. It loses a point because the engines and promptIds default wording largely restates the schema descriptions verbatim.

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?

States a specific verb and resource: it asks the workspace's saved questions on ChatGPT, Perplexity, Gemini and Google AI Overviews. It is clearly distinguished from the sibling tools it could be confused with, get_answer_check_results (reads answers later) and update_answer_check_prompts (saves questions first).

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

Usage Guidelines5/5

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

It gives explicit trigger phrases, including the Japanese ones, and states when to call it versus when to read results later, and it warns against calling it again to wait for answers. It also names the prerequisite siblings: update_answer_check_prompts for saving questions, and get_answer_check_results for the prompts and balance.

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

All Convika toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources