Skip to main content
Glama

Words in Context

by com.gumballtools

Generate practice questions from a passage

generate_items
Read-only

Generate new practice items from a passage the learner supplies — their own reading, or the material they got wrong.

This is the PAID tier and it costs real money per call, unlike the curated bank. Prefer draw_items unless the learner specifically needs questions from their own material.

model is a priced choice: "economy" at $0.002 per item (Fast and cheap. Good enough for straightforward vocabulary in clear prose.); "standard" at $0.008 per item (Better at writing distractors that are genuinely tempting, which is the hard part of a good practice item.). Pick economy for straightforward prose and standard when the distractors need to be genuinely tempting, which is the hard part of a good question.

Limits: passage 200 characters minimum, and count at most 5 per call. Generation is capped at 10 calls per caller per day, separately from the free quota.

Generated items are NOT reviewed by a person. Every response carries a caveat saying so. Check the answer and the distractor reasons before giving them to a learner — a generated question with two defensible answers is worse than no question.

Returns 503 when generation is not enabled on the deployment; fall back to draw_items.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoHow many items, 1-5. Default 3.
modelNoPriced choice. "economy" is cheaper; "standard" writes more tempting distractors. Default economy.
sourceYesA passage of at least 200 characters. The learner's own reading.
difficultyNoTarget difficulty.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The description goes well beyond the readOnlyHint/openWorldHint annotations: it discloses per-call cost with exact prices, the 10-calls-per-day cap, that output is NOT human-reviewed, that every response carries a caveat, and the 503 failure mode. This is exactly the operational context an agent needs before spending money.

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

Conciseness4/5

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

Front-loaded with the core purpose and the critical paid-tier warning, with each paragraph serving a distinct role (cost, model selection, limits, quality caveat, fallback). Slightly verbose — 'which is the hard part of a good practice item/question' appears twice — but every section earns its place for a paid tool.

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 paid tool with no output schema, the description covers all invocation-critical info: minimum/maximum inputs, rate limit, cost model, review-quality warning, and error handling with fallback. It even hints at the response shape ('Check the answer and the distractor reasons'), so an agent can call this safely without guessing.

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 real value: for 'model' it gives exact per-item prices and a decision rule (economy for straightforward prose, standard for tempting distractors), and for 'source' it clarifies 'the material they got wrong.' The count limit of 5 is reinforced. Only 'difficulty' gets no added meaning.

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 ('Generate new practice items from a passage the learner supplies') and immediately distinguishes itself from the sibling draw_items with 'unlike the curated bank.' An agent can tell exactly what this tool does and how it differs from the alternative.

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 routes the agent: 'Prefer draw_items unless the learner specifically needs questions from their own material' and 'fall back to draw_items' on 503. It names both the when-to-use and when-not-to-use conditions with the sibling tool.

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

All Words in Context toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clear, non-overlapping role: draw_items pulls from a curated bank, generate_items creates custom items from a passage, and check_answer evaluates responses. The only potential pair (draw vs. generate) is explicitly contrasted by source, cost, and intended use.

Naming Consistency5/5

All tool names follow the same snake_case verb_noun pattern: check_answer, draw_items, generate_items. The naming is predictable and makes each tool's action immediately clear.

Tool Count5/5

Three tools is well-scoped for a focused vocabulary practice server: one to source items, one to create custom items, and one to check answers. There is no redundancy, and every tool earns its place.

Completeness5/5

The core workflow is fully covered: draw or generate items, then check answers with detailed teaching feedback. No critical dead ends exist, and the fallback from generate_items to draw_items plus the check_answer flow supports the server's stated purpose.

Resources