Skip to main content
Glama

get_captcha

Fetch a CAPTCHA image from VTOP to begin login and save it to a file, so you can read the characters and submit them before the code expires.

Instructions

Step 1 of login: fetch a CAPTCHA image from VTOP. Returns the image AND saves it to a file. CRITICAL - never invent the characters. If no image is rendered above, you cannot read the captcha: do NOT guess. Open captchaFile from the response and read that, or ask the user to open it and tell you the characters. A guess is always wrong and counts as a real failed login attempt against the student's account. After reading it, immediately call login — the image is only valid for 30-60 seconds. Failures come back as structuredContent.error.code (e.g. RECAPTCHA_REQUIRED, CAPTCHA_NOT_FOUND) with an ordered recovery plan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.5

TDQS

A4.8/5.0
Behavior5/5

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

Annotations say readOnlyHint=false, and the description explains exactly why: it saves the image to a file. It adds genuinely new behavioral context beyond annotations — a 30-60 second validity window tied to the next `login` call, plus structured failure modes (structuredContent.error.code such as RECAPTCHA_REQUIRED, CAPTCHA_NOT_FOUND) with an ordered recovery plan.

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 essential purpose and the critical 'don't guess' rule, and every sentence carries actionable weight. It runs long, but the length is justified by the anti-guessing safety warning and the error-code/recovery detail; no sentence is filler.

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 carries the return-value burden and does so: it explains that the response contains an image plus a saved file and structured error codes. Combined with the timing and sequencing guidance, an agent has everything needed to call it correctly.

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?

The tool takes no parameters, so the baseline is 4. The description usefully references a response field (`captchaFile`) the caller must consume, but does not elaborate further since there is nothing to document on the input side.

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 precise verb and resource ('fetch a CAPTCHA image from VTOP') and explicitly positions it as 'Step 1 of login', making its role in the flow unambiguous. It also discloses the side effect of saving the image to a file, so an agent can distinguish it from the sibling `login` and other read-only getters.

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?

Explicit when-to-use (immediately before `login`), what to do instead when the image isn't readable (open `captchaFile` or ask the user), and a hard prohibition ('never invent the characters', 'do NOT guess'). It even names the consequence of misuse (counts as a real failed login).

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