Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BanqueUNT MCP Give me a 10-question mock exam on Cardiology."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that connects the BanqueUNT medical question bank (1,400+ exam questions from the Universidad Nacional de Trujillo, Peru) to AI assistants such as Claude, Cursor and VS Code Copilot.
Students can search questions, take mock exams, get graded with detailed explanations and track their weak topics, all from a chat with their favorite assistant. The server is built so the assistant cannot see the answer key before grading, so the practice stays honest.
The full bank is private. This repository ships with a public sample of 30 questions from past exams, so everything below works out of the box.
You: Give me a 5-question mock exam on Cardiology.
Claude: [generar_simulacro] Mock exam 5e63c63bf544 · med2_unt · 5 questions
1. A 62-year-old man with dyspnea and orthopnea… A) … B) … C) … D) … E) …
…
You: 1 C, 2 A, 3 B, 4 D, 5 A
Claude: [corregir_simulacro] Score: 4/5 (80 %)
✘ 3. You answered B, key D. Why D: … Why not B: … Remember: …
You: What should I review?
Claude: [mi_progreso] Weakest topics: Heart failure (40 %), Valvular disease (50 %)…Related MCP server: Student Progress Tracker MCP Server
Tool | What it does |
| Counts questions by course, specialty, year and topic. Duplicates published in several exams count once. |
| Full-text search (accent and case insensitive) with filters and cursor pagination. Never returns the answer. |
| Builds a random mock exam (1–100 questions), preferring questions the student has not seen yet. Stored with an expiry time. |
| Grades a mock exam once: score, answer key and a normalized explanation for every wrong answer. Records results by topic. |
| History, accuracy by specialty and topic, the 5 weakest topics and recently failed topics. |
| Full explanation of a question the student has already answered and had graded. |
Every tool declares an input and output schema with zod and returns structuredContent; read-only tools are annotated with readOnlyHint.
banqueunt://cursos, banqueunt://cursos/{curso}/temas (with argument completion) and banqueunt://pregunta/{id} (public version, no answer).
sesion_de_repaso: a tutor that asks one question at a time, waits for the answer, grades it and explains.
repasar_temas_debiles: reads your progress and builds a mock exam from your weak topics.
Requires Node.js 22.13 or later (it uses the built-in node:sqlite).
git clone https://github.com/zumaetaadriel2/banqueunt-mcp.git
cd banqueunt-mcp
npm ci
npm run buildThen add the server to your client. Replace the path with the absolute path to dist/index.js on your machine.
claude mcp add --scope user banqueunt -- node /absolute/path/to/banqueunt-mcp/dist/index.jsEdit claude_desktop_config.json (Settings → Developer → Edit Config) and restart the app:
{
"mcpServers": {
"banqueunt": {
"command": "node",
"args": ["C:\\path\\to\\banqueunt-mcp\\dist\\index.js"]
}
}
}Add to ~/.cursor/mcp.json (global) or .cursor/mcp.json (project):
{
"mcpServers": {
"banqueunt": {
"command": "node",
"args": ["/absolute/path/to/banqueunt-mcp/dist/index.js"]
}
}
}Add to .vscode/mcp.json:
{
"servers": {
"banqueunt": {
"type": "stdio",
"command": "node",
"args": ["/absolute/path/to/banqueunt-mcp/dist/index.js"]
}
}
}Then ask: "How many questions are there per specialty?" or "Give me a 10-question mock exam."
All settings are environment variables, passed through the env field of your client config.
Variable | Default | Description |
| (unset: bundled sample) | Path to a local bank folder containing |
|
| Enabled courses, comma separated. |
|
| SQLite file for mock exams and progress ( |
| (unset: no limit) | Maximum questions a user can receive per day (resets at midnight, Peru time). |
flowchart LR
client["AI assistant<br/>(Claude, Cursor, VS Code)"] -- "MCP over stdio" --> server
subgraph server["banqueunt-mcp"]
tools["tools · resources · prompts"]
dominio["domain<br/>search · mock exams · grading · progress"]
publico["aPreguntaPublica()<br/>strips key, explanation and topic"]
tools --> dominio
dominio --> publico
end
dominio --> fuente["question source<br/>sample JSON or local bank folder"]
dominio --> repo[("SQLite<br/>mock exams · results · call log")]src/
index.ts stdio entry point
server.ts registers tools, resources and prompts
datos/ zod schema, explanation normalizer, dedup signature, question sources
dominio/ pure logic: search, mock exams, grading, progress, daily limit
persistencia/ ProgresoRepo interface + SQLite implementation
tools/ one file per group of tools
tests/ Vitest: unit tests + end-to-end tests with a real MCP client in memoryNo answer leaks before grading. Every pre-grading output goes through a single function, aPreguntaPublica(), which removes the key, the explanation and also the topic (a topic such as "Digoxin toxicity" gives the answer away). Integration tests serialize the response of every tool and fail if any of that appears.
Two explanation formats, one output. The bank mixes an old {correcta, descarte} format with a richer one (key idea, why each option is wrong, what to remember, reference). Both are validated with a zod union and normalized into a single Explicacion.
Deduplication. The same question often appears in several exams. A signature over the normalized stem and sorted options (ported from the original app) keeps counts and mock exams free of repeats.
Bank protection. Searches return at most 20 questions per call, an optional daily cap limits how many questions a user can receive, and every call is logged (npm run uso) to spot bulk extraction.
Async persistence interface. ProgresoRepo is async so the local SQLite implementation and the planned Cloudflare D1 one share the same contract.
npm test # Vitest (set BANQUEUNT_DATA to also validate the full bank)
npm run lint # ESLint
npm run typecheck # tsc --noEmit
npm run inspector # open MCP Inspector against dist/index.js
npm run uso -- 7 # calls and questions served per user in the last 7 daysRemote mode for subscribers: Streamable HTTP on Cloudflare Workers, OAuth 2.1 with Supabase Auth login, the bank in a private R2 bucket and progress in D1.
More courses (ENCIB, Residentado) and images.
npx banqueunt-mcp on npm.
Code under the MIT License. The bundled sample (data/muestra.json) contains questions from past exams for demonstration only; the full BanqueUNT bank is not part of this repository.
Busca preguntas del banco por texto y filtros. Devuelve enunciado y alternativas, nunca la respuesta ni la explicación. Para practicar con corrección usa generar_simulacro.
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | P. ej. "2021" o "Sin fecha" | |
| tema | No | Parte del nombre del tema | |
| curso | No | Id del curso; opcional si el servidor tiene uno solo | |
| texto | No | Palabras que deben aparecer (sin importar tildes ni mayúsculas) | |
| cursor | No | El valor "siguiente" de la página anterior | |
| limite | No | ||
| dificultad | No | "Fácil", "Intermedio" o "Difícil" | |
| especialidad | No | P. ej. "Cardiología" | |
| solo_prioritarias | No |
| Name | Required | Description |
|---|---|---|
| curso | Yes | |
| total | Yes | |
| preguntas | Yes | |
| siguiente | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, but the description adds a non-obvious behavioral fact: results contain the stem and options only, never the answer or explanation. That shapes how the agent uses the output. It says nothing about pagination behavior (cursor/limite), which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero filler, and the capability plus the key output constraint are front-loaded. The alternative-tool pointer is placed last where it belongs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, and the description still adds the crucial constraint that answers/explanations are withheld. For a read-only, filterless-optional search tool that is largely sufficient. Only pagination expectations are left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 78%, so the schema carries nearly all parameter meaning. The description only gestures at 'texto y filtros' and adds no syntax, defaults, or filter semantics beyond what properties already say. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('busca preguntas del banco') and immediately narrows scope ('por texto y filtros'). It also distinguishes itself from the sibling meant for graded practice, so an agent can tell the two apart without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: 'Para practicar con corrección usa generar_simulacro.' That is a concrete alternative with a selecting condition. It doesn't cover other plausible siblings (explicar_pregunta, estadisticas_banco), so it falls short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Corrige un simulacro generado con generar_simulacro. Devuelve la nota, la clave de cada pregunta y la explicación de las falladas. Las preguntas sin respuesta cuentan como incorrectas. Cada simulacro se corrige una sola vez.
| Name | Required | Description | Default |
|---|---|---|---|
| respuestas | Yes | Número de pregunta → letra, p. ej. {"1": "A", "2": "C"} | |
| simulacro_id | Yes |
| Name | Required | Description |
|---|---|---|
| curso | Yes | |
| items | Yes | |
| total | Yes | |
| aciertos | Yes | |
| falladas | Yes | |
| porcentaje | Yes | |
| simulacro_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that unanswered questions count as incorrect and that each simulacro can be corrected only once, but it does not clarify whether the correction is persisted, what happens on a second attempt, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences with no wasted text. Purpose, return content, scoring rule, and one-time constraint are front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not fully explain return values, and it still summarizes the grade, answer key, and explanations. It covers the main behavioral rules for a two-parameter tool, with the only notable gap being the lack of detail around simulacro_id and error behavior when a simulacro was already corrected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is exactly 50%: the respuestas parameter is well documented in the schema, while simulacro_id is not. The description adds some meaning by linking simulacro_id to a simulacro produced by generar_simulacro, but it does not add format or validation details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: correcting a mock exam (simulacro) generated by generar_simulacro. It clearly distinguishes the tool from its sibling generator and explains what the result contains, so an agent can identify the tool 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'generado con generar_simulacro' establishes the prerequisite and routes the agent from the generator sibling to this correction step. It does not explicitly state when not to use it or name alternative siblings such as explicar_pregunta, so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cuenta las preguntas del banco por curso, especialidad y año (y por tema si se indica una especialidad). Las preguntas repetidas en varios exámenes se cuentan una sola vez. No devuelve preguntas ni respuestas.
| Name | Required | Description | Default |
|---|---|---|---|
| curso | No | Id del curso, p. ej. "med2_unt". Sin él: todos los disponibles | |
| especialidad | No | Si se indica, añade el conteo por tema de esa especialidad (p. ej. "Cardiología") |
| Name | Required | Description |
|---|---|---|
| cursos | Yes | |
| origen | Yes | De dónde salen las preguntas: "muestra" (pública) o "carpeta" (banco local) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: repeated questions across exams are counted once, and it explicitly excludes returning questions or answers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences: the counting behavior and grouping dimensions come first, followed by the deduplication rule and the negative scope. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape need not be explained, and the description covers counting scope, dedup semantics, and exclusions. The unexplained 'año' grouping versus the two-parameter schema is the only residual gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are fully documented in the schema and the description only mirrors that (especialidad triggers a per-tema breakdown). It also mentions grouping 'por año' although no year parameter exists, which adds mild ambiguity rather than clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Cuenta') and resource ('preguntas del banco') plus the grouping dimensions (curso, especialidad, año, tema). An agent can tell this is an aggregate-count tool, distinct from buscar_preguntas or generar_simulacro, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'No devuelve preguntas ni respuestas' signals that question retrieval belongs to buscar_preguntas, and the optional-especialidad rule is conveyed. There is no explicit when-to-use or when-not-to-use statement referencing alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve la clave y la explicación completa de una pregunta que el alumno YA corrigió en un simulacro. No sirve para preguntas que todavía no respondió.
| Name | Required | Description | Default |
|---|---|---|---|
| pregunta_id | Yes | El pregunta_id que aparece en la corrección |
| Name | Required | Description |
|---|---|---|
| tema | Yes | |
| pregunta | Yes | |
| explicacion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description adds useful behavioral context: it only works after a question has been corrected and it returns both the answer key and the full explanation. It does not describe what happens when the precondition is not met beyond saying it does not work.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is two short sentences with no waste. The key constraint is front-loaded in the first sentence and the negative condition follows immediately, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with full schema coverage, annotations, and an output schema, the description is complete enough. It states what is returned and the key eligibility condition without needing to explain output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already defines pregunta_id as 'El pregunta_id que aparece en la corrección'. The description reinforces that the question must come from a correction, but adds little parameter-level syntax or format detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Devuelve la clave y la explicación completa de una pregunta'. It also scopes the tool to questions the student already corrected in a mock exam, which differentiates it from unanswered-question flows. However, it does not explicitly name or contrast with sibling tools such as buscar_preguntas or corregir_simulacro.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives both a positive usage condition ('una pregunta que el alumno YA corrigió en un simulacro') and a negative condition ('No sirve para preguntas que todavía no respondió'). The guidance is clear, but it does not name alternative tools to use when the condition is not met.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Arma un simulacro al azar con preguntas del banco, sin repetir y priorizando las que el alumno aún no vio. Devuelve un simulacro_id y las preguntas numeradas SIN respuesta. Muéstralas al alumno sin resolverlas y, cuando responda, llama a corregir_simulacro.
| Name | Required | Description | Default |
|---|---|---|---|
| anios | No | P. ej. ["2020", "2021"] | |
| curso | No | Id del curso; opcional si el servidor tiene uno solo | |
| temas | No | Partes del nombre del tema; basta con que coincida uno | |
| cantidad | No | ||
| dificultad | No | "Fácil", "Intermedio" o "Difícil" | |
| especialidades | No | P. ej. ["Cardiología", "Nefrología"] | |
| excluir_vistas | No | Primero preguntas que no salieron en simulacros anteriores; si no alcanzan, completa con vistas | |
| solo_prioritarias | No |
| Name | Required | Description |
|---|---|---|
| curso | Yes | |
| total | Yes | |
| nuevas | Yes | |
| expira_en | Yes | |
| preguntas | Yes | |
| repetidas | Yes | |
| disponibles | Yes | Preguntas que cumplen los filtros |
| simulacro_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the load and does well: it discloses randomness, no-repeat selection, the unseen-first prioritization with a fallback, and critically that answers are stripped from the output. It omits any note on quotas (cantidad max 100), what happens with zero matches, or permission/course requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences in a strict priority order: what it builds, what it returns, what the agent must do next. No filler and no repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the return shape needn't be spelled out, though the description usefully adds that answers are excluded. For an 8-param generation tool with all-optional inputs, the main remaining gap is that an agent isn't told what happens with no filters or when the bank can't satisfy the request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so the baseline is 3. The description's mention of 'priorizando las que el alumno aún no vio' gives behavioral meaning to excluir_vistas, but it never addresses solo_prioritarias, which has no schema description at all, nor how the filters (anios, temas, especialidades, dificultad) combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('arma un simulacro al azar con preguntas del banco') and adds the two defining selection rules (sin repetir, priorizando no vistas). An agent can distinguish it from buscar_preguntas or estadisticas_banco 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit downstream routing: show the questions unresolved, and call corregir_simulacro once the student answers. Strong context, but it never states when NOT to use it (e.g., vs. buscar_preguntas for ad-hoc lookups) or that all filter params are optional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume los simulacros corregidos del alumno: porcentaje global, rendimiento por especialidad, temas débiles (2+ respuestas), temas fallados recientemente y últimos simulacros. Úsalo para recomendar qué repasar.
| Name | Required | Description | Default |
|---|---|---|---|
| curso | No | Solo ese curso; sin él, todos |
| Name | Required | Description |
|---|---|---|
| ultimos | Yes | |
| aciertos | Yes | |
| porcentaje | Yes | |
| simulacros | Yes | |
| respondidas | Yes | |
| temasDebiles | Yes | |
| temasFallados | Yes | |
| porEspecialidad | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds real substance on top by disclosing the returned dimensions and the explicit '2+ respuestas' threshold that defines a weak topic. It does not explain what happens when the student has zero corrected simulacros or how the list of recent simulacros is bounded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler: each clause enumerates a distinct dimension of the summary, and the usage hint is appended last. Nothing repeats the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and a fully described optional parameter, the description covers everything an agent needs to select and call it, including the weak-topic threshold. The only gap is edge-case behavior (empty progress history), which is minor for a read-only summary tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single optional 'curso' parameter is already documented in the schema as 'Solo ese curso; sin él, todos'. The description adds nothing about the filter, so this is the baseline 3 where the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Resume') and resource ('simulacros corregidos del alumno') and enumerates exactly what the summary contains: global percentage, per-specialty performance, weak topics, recently failed topics, and latest simulacros. It is clearly distinguishable from estadisticas_banco (bank-level stats) by its per-student scope, though the description never names the sibling it differs from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Úsalo para recomendar qué repasar' gives a concrete use context that tells an agent when this tool is the right pick. It offers no when-not conditions and names no alternatives (e.g., estadisticas_banco for aggregate difficulty data), so routing among siblings is still partly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0buscar_preguntascorregir_simulacroestadisticas_bancoexplicar_preguntagenerar_simulacromi_progresoScored across 6 tools
Each tool targets a clearly distinct action in the study workflow: counting bank statistics, searching questions, generating a practice exam, summarizing progress, grading an exam, and explaining an already-graded question. The descriptions explicitly clarify boundaries, such as buscar_preguntas never returning answers and explicar_pregunta only working after correction.
All names use consistent snake_case and are readable. However, four tools follow a verb_noun pattern (buscar_preguntas, generar_simulacro, corregir_simulacro, explicar_pregunta) while two use noun/possessive forms (estadisticas_banco, mi_progreso), a minor deviation from a single predictable convention.
Six tools is well-scoped for a question-bank practice assistant. Each tool covers a necessary step in the student workflow without redundancy or filler.
The surface covers the core lifecycle: inspect bank stats, search questions, generate a simulacro, grade it, review progress, and explain missed questions. Minor gaps include no explicit tool to list available courses/specialties/themes for filter discovery, though estadisticas_banco partially surfaces that metadata.
Build study flashcards and exam-prep decks from your AI chat, all stored locally.
Create AI-generated exam questions and save them to your paperee question bank for review.
Spaced-repetition flashcards your AI writes, quizzes you on by voice, and schedules with FSRS.
Save the courses you make with AI and review them with spaced repetition and a daily session.
