Un servidor MCP para Vocabit, una aplicación de tarjetas de memoria. Permite a un asistente de IA escribir un conjunto de estudio en una aplicación real en un teléfono real, y luego leer cómo le fue realmente al estudiante con él.
La mayoría de los servidores MCP leen desde una API. Este cierra un bucle:
flowchart LR
A["Assistant<br/>teaches a topic"] --> B["create_study_set"]
B --> C["Set appears in the<br/>Vocabit app"]
C --> D["Learner works<br/>through it"]
D --> E["get_set_results"]
E -->|weak cards| ALa herramienta interesante no es create_study_set — cualquier cosa puede generar tarjetas. Es get_set_results: qué tarjetas marcó el estudiante como difíciles, cuáles nunca alcanzó, cuántas revisiones tomó cada una. El siguiente conjunto se construye a partir de eso, no de una suposición.
Sin backend, sin cuenta, sin clave de API:
npx -y vocabit-mcp --demoEl modo demo ejecuta el mismo servidor contra un Vocabit en memoria con dos conjuntos precargados. Crea un conjunto, pide resultados, y un estudiante sustituto determinista lo habrá trabajado — marcado en la respuesta como simulado, para que nunca se confunda con datos reales.
Para probarlo con una interfaz de usuario:
npx @modelcontextprotocol/inspector npx -y vocabit-mcp --demoRelated MCP server: EduBase MCP Server
Listado en el Registro MCP como io.github.JohnBilousov/vocabit-mcp, por lo que los clientes que leen el registro pueden encontrarlo por sí mismos.
claude mcp add vocabit -- npx -y vocabit-mcp{
"mcpServers": {
"vocabit": {
"command": "npx",
"args": ["-y", "vocabit-mcp"],
"env": {
"VOCABIT_BASE_URL": "https://your-vocabit-backend.example.com",
"VOCABIT_AGENT_KEY": "your-agent-key"
}
}
}
}Elimina el bloque env para ejecutar en modo demo.
Tool | What it does |
| Comprueba la conexión y en qué modo está el servidor. |
| Publica un conjunto en la aplicación del estudiante. Devuelve un enlace profundo que lo abre en el dispositivo. |
| Conjuntos recientes, primero los más nuevos, cada uno con un resumen de progreso. |
| Contenido completo de un conjunto, más el tema y las notas que adjuntó el asistente. |
| La mitad de retroalimentación. Estado por tarjeta, |
| Cambiar título, reetiquetar o añadir tarjetas — normalmente el seguimiento después de leer los resultados. |
| Aviso por Telegram de que un conjunto está esperando. |
| Elimina un conjunto de la aplicación. Se conserva el historial de estudio. |
También se exponen: el recurso vocabit://set/{setId} (un conjunto como JSON, listable) y un prompt study-session que recorre todo el bucle.
El progreso proviene del motor de repetición espaciada de la aplicación, no del asistente:
Status | Meaning |
| Nunca revisada. |
| El estudiante la marcó como difícil. |
| Marcada como buena. |
| Marcada como fácil. |
Un conjunto informa completed: true cuando no queda ninguna tarjeta en new.
Apunta el servidor a un backend de Vocabit que tenga habilitada la API de agente:
export VOCABIT_BASE_URL=https://your-vocabit-backend.example.com
export VOCABIT_AGENT_KEY=... # must match one of AGENT_API_KEYS on the backend
npx -y vocabit-mcpVariable | Purpose |
| URL base del backend. |
| Se envía como |
| UID de Firebase del estudiante. Opcional; el backend tiene un valor predeterminado. |
| Valores predeterminados para nuevos conjuntos, p. ej. |
| Destinatario para |
| Tiempo de espera de la solicitud, predeterminado |
|
|
Si no se establecen ni la URL ni la clave, el servidor se inicia en modo demo. Si se establece exactamente una, se niega a iniciarse — media configuración es un error, no una pista.
El modo demo es un cliente de primera clase, no un stub. HttpVocabitClient y DemoVocabitClient implementan la misma interfaz VocabitClient, por lo que ninguna herramienta tiene una rama para "¿estamos fingiendo?". Un revisor puede ejecutar el servidor antes de tener credenciales, y la suite de pruebas ejercita la superficie real de las herramientas sobre un transporte MCP real en lugar de simular el SDK.
Los errores son recuperables, no fatales. Una llamada fallida regresa como isError con el mensaje del propio backend más una pista dirigida al modelo — 404 dice "llama a list_study_sets para ver qué conjuntos existen", 401 dice "o ejecuta con VOCABIT_DEMO=1". Los argumentos mutuamente excluyentes se rechazan con una explicación en lugar de una suposición.
Los esquemas de salida se mantienen flexibles en los bordes. Los campos de identificación son obligatorios; todo lo demás es opcional, por lo que un backend que añade un campo no convierte una herramienta funcional en un error de validación.
Las anotaciones son honestas. delete_study_set está marcado como destructiveHint, las herramientas de lectura como readOnlyHint. notify_learner envía un mensaje a una persona real, y su descripción dice que se use con moderación.
git clone https://github.com/JohnBilousov/vocabit-mcp && cd vocabit-mcp
npm install
npm run build
npm test # tool surface + full loop, plus the HTTP client against a mocked fetch
npm run lint # eslint
npm run format # prettier --write
npm run inspect # demo mode in the MCP InspectorCI ejecuta typecheck, lint, format:check, test y build en cada push y pull request.
src/
index.ts CLI entry, stdio transport
config.ts env → Config, demo-mode resolution
server.ts tool / resource / prompt registration
schemas.ts zod input and output shapes
format.ts human-readable summaries next to structuredContent
client/
types.ts wire types + VocabitClient contract
http.ts live backend
mock.ts in-memory backend for demo mode
test/
server.test.ts tool surface + full loop — over an in-memory MCP transport
client/
http.test.ts query encoding, error-body parsing, timeouts — against a mocked fetchLa publicación utiliza la publicación confiable de npm (OIDC) — sin secreto NPM_TOKEN, nada que pueda filtrarse o expirar. Configuración única en npmjs.com, en Configuración → Publicación confiable → GitHub Actions del paquete: organización JohnBilousov, este repositorio, nombre de archivo del flujo de trabajo publish.yml.
Para hacer un lanzamiento: sube la versión en package.json, server.json y VERSION en src/server.ts juntos (una prueba asegura que no puedan divergir), haz commit, push, y luego publica un Release de GitHub con una etiqueta vX.Y.Z correspondiente. Eso activa .github/workflows/publish.yml, que ejecuta la suite de pruebas y publica en npm con procedencia — la página del paquete muestra un enlace verificado a este commit y ejecución de flujo de trabajo exactos, no solo un nombre en el registro.
Transporte HTTP transmisible junto a stdio
Soporte para múltiples estudiantes sin un UID predeterminado del backend
Tarjetas de pronunciación de audio
MIT © Ivan Bilousov
Build a flashcard set and publish it to the learner's Vocabit app. Returns a deep link that opens the set on their device. Prefer one focused topic and 8-15 cards per set — long sets get abandoned. Use the notes field for what you want to check afterwards; the learner never sees it.
| Name | Required | Description | Default |
|---|---|---|---|
| cards | Yes | The flashcards, 1-300. Keep a set to one theme and around 8-15 cards for a single session | |
| notes | No | Your own notes about what to check when reviewing results. Never shown to the learner | |
| title | Yes | Set title as the learner will see it in the app | |
| topic | No | Topic tag used to group sets and to filter them later, e.g. 'church vocabulary' | |
| notify | No | Ping the learner on Telegram that the set is ready | |
| userId | No | Firebase UID of the learner. Omit to use the server default | |
| visibility | No | Defaults to private | |
| description | No | Short description shown under the title | |
| termLanguage | No | Language of the terms, e.g. 'de' | |
| definitionLanguage | No | Language of the definitions, e.g. 'en' |
| Name | Required | Description |
|---|---|---|
| setId | Yes | |
| title | Yes | |
| userId | No | |
| deepLink | Yes | Universal link that opens the set in the app |
| notified | No | |
| cardCount | Yes | |
| visibility | No | |
| appSchemeLink | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral detail beyond the annotations: it states the tool publishes to the learner's app, returns a deep link, and specifically discloses that the notes field is never shown to the learner. This gives the agent solid expectations for side effects and privacy, complementing the readOnlyHint=false and destructiveHint=false annotations.
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 with no redundancy: it states the action, the return, then two pieces of practical guidance. Information is front-loaded (action first), and each sentence earns its place without fluff.
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 10-parameter creation tool with a rich schema and output schema present, the description covers the core purpose, return behavior, best-practice usage, and a privacy nuance. Nothing essential is missing for an agent to invoke it correctly; the schema handles parameter details.
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 every parameter has a description. The description does not introduce new parameter meaning beyond restating the notes privacy and the card-count advice already present in the schema. It adds no new semantics that the schema doesn't already provide, so the 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?
The description clearly states the action ('Build a flashcard set and publish it') and the resource (flashcard set in Vocabit). It also mentions the return value (deep link), distinguishing it from list/get/update/delete siblings. The verb is specific and the purpose is unambiguous.
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 description provides strong best-practice context ('Prefer one focused topic and 8-15 cards per set') but does not explicitly contrast with alternatives like update_study_set or when not to use it. It gives clear context for using the tool effectively but lacks an explicit 'use X instead' routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a set from the learner's app. Study history is kept on the backend, but the set disappears from their device. Ask before calling this.
| Name | Required | Description | Default |
|---|---|---|---|
| setId | Yes | Set id returned by create_study_set or list_study_sets |
| Name | Required | Description |
|---|---|---|
| setId | Yes | |
| deleted | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only. The description adds context by specifying that study history persists on the backend while the device copy is removed, and instructs to seek permission. This goes beyond the annotation flags, giving the agent a precise understanding of side effects.
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, each adding distinct value: purpose, scope nuance, and usage directive. No filler or redundancy.
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 single-parameter destructive operation with an output schema available, the description covers purpose, scope, and a user-consent requirement. Nothing critical is missing.
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?
The schema fully documents the sole parameter (setId) with a source reference, and the description adds no additional parameter semantics. With 100% schema coverage, the baseline 3 applies.
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 clearly states the action (remove) and resource (a set from the learner's app), with further scope clarification (backend history kept, device set removed). It does not explicitly name sibling tools, but the verb distinguishes it from create/update/list, making its purpose unambiguous.
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?
Provides an explicit directive 'Ask before calling this' and clear context of what removal entails. It lacks explicit exclusions or alternatives, but the usage context is obvious for a deletion task and the consent instruction is a strong behavioral guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read back real study results for a set: which cards the learner marked hard (weakCards), which they never reached (untouchedCards), and per-card review counts. This is the feedback half of the loop — read it before writing the next set, and build the follow-up out of weakCards.
| Name | Required | Description | Default |
|---|---|---|---|
| setId | Yes | Set id returned by create_study_set or list_study_sets | |
| userId | No | Read progress for a different learner than the set owner |
| Name | Required | Description |
|---|---|---|
| cards | No | |
| notes | No | |
| setId | Yes | |
| title | Yes | |
| topic | No | |
| summary | Yes | |
| demoNote | No | |
| completed | Yes | |
| weakCards | Yes | |
| dueCardIds | No | |
| untouchedCards | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate safety. It adds value by explaining what the read returns (weakCards, untouchedCards, review counts) and how to use it, which goes beyond the schema. No contradiction is present.
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 sentences, zero fluff. The purpose is front-loaded, and the usage guidance is packed into the second sentence. Every word earns its place.
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?
Since an output schema exists, return values are covered. The description gives the loop context and the key fields, which is sufficient for an agent to select and call correctly. Minor gaps like pagination or error handling are not critical for a simple read 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 description coverage is 100%, so both setId and userId are already documented. The description adds no parameter-level detail beyond what the schema provides, so it doesn't compensate further, but it also doesn't detract. Baseline 3 applies.
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 uses a specific verb ('Read back') and identifies the resource ('real study results for a set') with concrete fields (weakCards, untouchedCards, per-card review counts). It clearly distinguishes itself from siblings like get_study_set by focusing on performance results, and explicitly frames this as the 'feedback half of the loop'.
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 description gives explicit usage guidance: 'read it before writing the next set' and advises building follow-up from weakCards. This tells the agent exactly when to use this tool and how to act on its output, which is more explicit than most tool definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full contents of a set — every card, plus the topic and notes you attached when you created it.
| Name | Required | Description | Default |
|---|---|---|---|
| setId | Yes | Set id returned by create_study_set or list_study_sets |
| Name | Required | Description |
|---|---|---|
| cards | Yes | |
| notes | No | |
| setId | Yes | |
| title | Yes | |
| topic | No | |
| deepLink | Yes | |
| cardCount | Yes | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to repeat that it's a read operation. The description adds valuable context beyond the annotation by specifying the exact content returned: 'every card, plus the topic and notes you attached when you created it.' This enriches the agent's understanding of what the tool provides without contradicting any annotation.
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 a single, front-loaded sentence that starts with the verb 'Read,' immediately conveying the action. There is no fluff or redundancy. It efficiently conveys the scope of the tool in a way that is easy to scan, earning a full score for conciseness and structure.
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?
Given that an output schema exists (has_output_schema=true) and the single parameter is documented in the schema, the description need not explain return formats or parameter formats. The description covers the necessary contextual information—what data is returned (all cards, topic, notes)—which is sufficient for an agent to call the tool correctly. There is no missing information that would impede correct usage.
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%; the parameter setId has a clear description ('Set id returned by create_study_set or list_study_sets'). The tool description adds no additional information about the parameter—it doesn't mention setId at all. Since the schema fully documents the parameter, the description does not need to compensate, so 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?
The description clearly states a specific verb ('Read') and resource ('full contents of a set'), and specifies exactly what is included (every card, topic, notes). This distinguishes it from sibling tools like list_study_sets (which likely provides summary metadata) and get_set_results (which likely returns performance data). The agent can immediately understand what the tool does 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 description implies this is the tool to use when you need the full contents of a study set, but it does not explicitly mention when not to use it or name alternatives. For example, it doesn't say 'use list_study_sets for a summary' or 'use get_set_results for results.' There is no explicit guidance on choosing among the related collection/read tools, leaving the agent to infer when this one is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the sets you created for this learner, newest first, each with a progress summary. Use it to find a setId, or to see at a glance which sets were never opened.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many sets to return, newest first (default 20) | |
| topic | No | Only sets with this exact topic tag | |
| userId | No | Firebase UID of the learner. Omit to use the server default | |
| includeProgress | No | Attach a progress summary to each set (default true) |
| Name | Required | Description |
|---|---|---|
| sets | Yes | |
| count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so read-only safety is covered. The description adds value beyond that by disclosing the scope (sets created for this learner), the newest-first ordering, and that each set carries a progress summary showing whether it was opened. No contradiction with the annotations.
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 sentences with zero waste. The core purpose is front-loaded, and the second sentence earns its place by adding the two primary use cases. Nothing extraneous.
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, read-only/open-world annotations, and 100% schema coverage, the description doesn't need to explain return values or parameters. It covers purpose, scope, ordering, and use cases well. The only minor gap is that it doesn't explicitly route users to the get_study_set/get_set_results siblings for more detail, and it omits pagination specifics — both minor for a list 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 description coverage is 100%, so all four parameters (limit, topic, userId, includeProgress) are already well-documented in the schema itself. Under the rubric, this yields a baseline of 3; the description adds no parameter-specific 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 states a specific verb (list), resource (study sets), scope (created for this learner), ordering (newest first), and content (progress summary per set). It also frames concrete use cases — finding a setId and spotting never-opened sets — which make its purpose unmistakable and distinct from the singular get_study_set and get_set_results siblings.
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 description gives explicit when-to-use guidance ('Use it to find a setId, or to see at a glance which sets were never opened'). However, it does not name alternatives or state when not to use it, such as pointing to get_set_results for detailed results, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send the learner a Telegram message that a set is waiting. Use sparingly — one ping per set, right after you create it.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Custom message. Omit for the default 'your set is ready' ping | |
| setId | Yes | Set id returned by create_study_set or list_study_sets |
| Name | Required | Description |
|---|---|---|
| setId | Yes | |
| notified | Yes | |
| telegramId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag non-read-only, non-idempotent behavior; the description adds the 'use sparingly / one ping' rule, which reinforces the side-effectful nature beyond what annotations state. No contradiction.
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 concise sentences with the purpose first and the guidance second. 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?
A simple notification tool with an output schema; the description covers what it does and when to call it. Nothing critical is missing.
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?
Both parameters are fully described in the schema (100% coverage), and the description adds no additional parameter semantics, so it meets the baseline.
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 action (send a Telegram message) and the resource (learner about a set). Clearly distinguishes from the CRUD siblings—it's a notification tool, not a data operation.
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 instructs sparing use and the exact timing ('right after you create it'), which tells the agent when to invoke it. Lacks explicit 'when not to use' or alternatives, but the constraint is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change a set in place: retitle it, retag it, or add cards. Pass addCards to append (the usual case after reviewing results) or cards to replace the list wholesale — never both. Replacing the cards resets what the learner has already studied.
| Name | Required | Description | Default |
|---|---|---|---|
| cards | No | Replace the whole card list. Cannot be combined with addCards | |
| notes | No | ||
| setId | Yes | Set id returned by create_study_set or list_study_sets | |
| title | No | ||
| topic | No | ||
| addCards | No | Append cards to the existing list. Cannot be combined with cards | |
| visibility | No | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| setId | Yes | |
| updated | Yes | Which fields changed, e.g. ['title', 'addCards'] |
| cardCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutability (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds a valuable side effect beyond annotations: 'Replacing the cards resets what the learner has already studied,' which is a behavioral consequence not captured in structured fields. It also warns against combining addCards and cards, adding safety context.
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 tight sentences carry all essential information: the action, the two operational modes, the constraint, and a key side effect. No filler, front-loaded with purpose, and every phrase earns its place.
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 mutation tool with 8 parameters, the description provides enough to call it correctly: it explains the main operational choices, the safety constraint, and the meaningful side effect. The output schema covers return details, and remaining parameters are straightforward. Nothing an agent needs is missing.
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 only 38%, so the description must compensate. It does so by explaining the two most ambiguous parameters—addCards (append) and cards (replace)—and their mutual exclusivity, plus the learning-reset consequence. Other parameters (title, topic, visibility) are self-explanatory, and the critical ones are well addressed, bridging the coverage gap.
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 action ('Change a set in place') and lists concrete operations (retitle, retag, add cards), clearly distinguishing it from create/delete/list siblings. The verb 'change' and resource 'study set' are explicit, and the added detail on cards vs. addCards further sharpens the purpose.
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?
Provides explicit guidance on choosing between addCards (append, 'the usual case after reviewing results') and cards (replace wholesale), including the 'never both' constraint. It implies when to use the tool (modifying an existing set) but does not directly contrast with create_study_set for new sets; however, the parameter-level usage is well covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the server can reach Vocabit and report which mode it is in (live backend or in-memory demo). Call this first if anything else fails.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| baseUrl | Yes | |
| defaultUserId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description needn't restate safety. It adds value by disclosing that the tool reports the operational mode (live vs demo), which is beyond the annotations. It doesn't elaborate on failure behavior, but the output schema likely covers that, and the description is sufficient for a health check.
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 tight sentences: the first states purpose and behavior, the second gives usage guidance. No filler, and the most important information (what it does) is front-loaded.
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 zero-parameter, read-only health check with an output schema, the description is complete. It states what it verifies, what it reports, and when to call it. The output schema handles return-value details, so nothing essential is missing.
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?
With zero parameters and 100% schema coverage, there is nothing for the description to explain. The baseline for 0 params is 4, and the description appropriately does not invent unnecessary parameter details.
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 clear verb 'Verify' and resource 'Vocabit', and specifies the output (mode: live or in-memory demo). It is immediately distinct from siblings, which all handle study sets and notifications, so an agent can easily tell this is a health-check tool.
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?
Explicit guidance is given: 'Call this first if anything else fails.' This provides a concrete trigger condition and implies it's a diagnostic first step. No ambiguity about when to use it.
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.3create_study_setdelete_study_setget_set_resultsget_study_setlist_study_setsnotify_learnerupdate_study_setvocabit_healthScored across 8 tools
Each tool has a clearly distinct purpose: health check, CRUD for study sets, results feedback, and learner notification. Even get_study_set and get_set_results are unambiguously separated—one retrieves content, the other study metrics. No two tools appear to do the same thing.
Most tools follow a verb_noun pattern (create_study_set, list_study_sets, update_study_set, delete_study_set, get_study_set, get_set_results). However, vocabit_health deviates from the verb-first style and notify_learner uses a non-set object, so the pattern is not perfectly uniform but remains predictable.
8 tools is well within the ideal 3-15 range and each earns its place in the set lifecycle. The count matches the server's scope—managing study sets with health check and notification—without redundancy or unnecessary bulk.
The tool surface covers the full lifecycle: create, read, update, delete, list, plus results feedback and learner notification. The feedback loop is closed by get_set_results informing update_study_set. Health check aids debugging. No obvious gaps that would cause agent failures.
Free: turn your AI chats into spaced-repetition vocabulary. 13 tools, reads and writes.
Spaced-repetition flashcards your AI writes, quizzes you on by voice, and schedules with FSRS.
Create, edit, translate, and export SCORM eLearning modules from a connected AI assistant.
Save vocabulary from any AI chat; see each word in every language you know; review it with FSRS.
