Skip to main content
Glama

mark_lesson_complete

Idempotent

Mark a published lesson complete. A personal API key needs Premium. A paired agent key works on free lessons on any plan, and on Premium lessons when your human has Premium; answer every quiz question first. Paired writes are saved to your human’s account, marked as done via the agent. Quiz: question and choice are 0-based indexes (the first question is 0, option A is 0). Wrong answers return correct:false, feedback Not quite and a hint, the correct choice and explanation appear only once you’ve answered that question correctly, and stay with it after later wrong retries. Unlimited retries; best results count. Minimum 2 seconds between attempts on one question and at most 10 attempts per minute per account. Pass when all questions are answered and at least ceil(2/3 N) are right (2 of 3), on any attempt. Points once per lesson. Completing without a pass earns no points until you pass. Always returns points; points_note explains zero awards (already_counted, no_points_yet or legacy).

Input Schema

NameRequiredDescriptionDefault
slugYesLesson identifier: lesson-<id> (e.g. lesson-12) or the numeric id (12), from list_lessons or search.
tokenNoOptional fallback: your agent_signup token or paired agent key, only if your MCP client can't send an Authorization: Bearer header (the header is preferred and wins). Treated exactly like the header; never shown back.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / token
      Added value: +{
      +  "description": "Optional fallback: your agent_signup token or paired agent key, only if your MCP client can't send an Authorization: Bearer header (the header is preferred and wins). Treated exactly like the header; never shown back.",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / slug / description
      Previous value: -"Stable lesson-<id> identifier or numeric ID"New value: +"Lesson identifier: lesson-<id> (e.g. lesson-12) or the numeric id (12), from list_lessons or search."
  3. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations (which only declare non-read-only, idempotent, non-destructive), the description discloses auth/entitlement rules, write attribution to the human's account, retry semantics, a rate limit (2s between attempts, 10/min per account), pass thresholds, and the return contract (always returns points; points_note explains zero awards). This is unusually rich behavioral context.

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, but the body is a dense wall of quiz mechanics, rate limits, scoring and points rules that mixes this tool's behavior with what is really quiz-answering mechanics. Much of it earns its place, but it is overlong and could be tightened.

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?

With no output schema, the description correctly explains the return contract (points and points_note values) and covers entitlements, retries and pass criteria. The main gap is the extraneous quiz-index parameter discussion, which duplicates another tool's domain and muddies the picture.

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

Parameters2/5

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

Schema coverage is 100%, so slug and token are already documented, and the description adds nothing new about them. Worse, it spends significant text on 'question' and 'choice' indexes that do not exist in this tool's schema, creating a mismatch that could mislead parameter selection.

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 opening sentence gives a specific verb and resource ('Mark a published lesson complete'), which is distinct from siblings like get_lesson, list_lessons and agent_quiz_answer. An agent can identify the operation 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?

It states clear preconditions, notably 'answer every quiz question first', which implicitly routes the agent through quiz answering before this call, and it spells out the entitlement rules per key type. It never explicitly names a sibling alternative, but the context is unambiguous.

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.