Sergio by Serviche

Add a quiz question

add_training_question

Idempotent

Adds a hand-written quiz question to one atom (sop_id) of a module, as Add question does (owner or admin seats only): question_text, two or more choices ({ key, text, is_correct }, one correct), explanation, optional image_url. A quiz question tests a lesson; it is not how to add new content to training: "add this to training" puts the text in a handbook article in the module (edit_training_module). Before adding anything to the handbook, search the sops read entity by the topic (search finds by meaning): when an article already covers it, put the new text into that article (edit_handbook_article with its full content_md, the new lines placed where they belong, or draft_handbook_edit) instead of a new one; create a new article only when none fits, and say which closest article you found and why it did not fit. Audience comes from the person's words: cleaner SOPs, cleaning standards or staff = cleaner; policies, office or VA = va; when the words do not say, ask in one line. Ask which place, in one line naming both, when two places fit the person's words equally well: two articles, or two training modules that both match (two new-hire modules are a tie whatever their status, draft or published); a place the person named outright is never a tie. The proposed change is the confirmation, so never ask "should I add this?" first. Pass the same idempotency_key when retrying; a repeat returns the same question.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "module_id": "<module_id>",
      "sop_id": "<sop_id>",
      "question_text": "<question_text>",
      "choices": "<choices>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "add_training_question"
  }
}

Input Schema

Name	Required	Description
`sop_id`	Yes
`choices`	Yes
`image_url`	No
`module_id`	Yes
`explanation`	No
`question_text`	Yes
`idempotency_key`	Yes	Your id for this operation (8-128 of A-Z a-z 0-9 . _ : -). Reuse it on every retry of the same operation; use a new one for a new operation.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare the mutation as non-destructive and idempotent, yet the description still adds real context: 'owner or admin seats only' is an authorization requirement found nowhere in structured data, and it spells out the retry contract ('pass the same idempotency_key... a repeat returns the same question') plus the rule that the proposed change is itself the confirmation. It does not, however, describe whether an added question is immediately live or what the response contains.

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 purpose is front-loaded in the first clause, but the description then runs to roughly 200 words of semicolon-chained routing, audience and tie-breaking policy that is dense and hard to scan in one pass. Nearly every sentence carries a rule, but several bundle two or three decisions into a single sprawling sentence.

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?

For a 7-parameter mutation with no output schema and 14% schema coverage, this covers the gaps that matter: what is created, who may create it, how duplicates and idempotent retries behave, and how to choose the target module/sop. The only real omission is any indication of what the call returns on success.

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?

With only 14% schema description coverage, the description carries the burden and largely does: it decomposes choices into {key, text, is_correct}, adds the 'one correct' and 'two or more' rules that the schema cannot express, and clarifies that sop_id is an atom inside module_id. It still says nothing about the format expectations for explanation or image_url beyond 'optional'.

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: 'Adds a hand-written quiz question to one atom (sop_id) of a module.' The word 'hand-written' and the pointer to edit_training_module / create_handbook_article make it distinguishable from generate_training_questions and from content-creation siblings without opening any schema.

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?

Explicitly separates this tool from alternatives: quiz questions test a lesson and are not how to add training content, which points to edit_training_module; before adding handbook content the agent must search sops and prefer edit_handbook_article or draft_handbook_edit. It also gives concrete decision rules for audience and tie-breaking between two equally fitting places.

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

All Sergio by Serviche tools Inspect

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

Need Help?