polski-tutor

by maution

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: listening task vs listening check, pronunciation task vs pronunciation check, concept lookup vs explanation vs practice, and progress/weak-point tracking. The complementary pairs are related but not overlapping.
Naming Consistency3/5
Names mix verb-first patterns (escuchar, comprobar_escucha, buscar_concepto) with noun-first patterns (diagnostico_inicial, ejercicio_pronunciacion, puntos_debiles, cobertura_concepto, estado_alumno), plus an odd 'audio_de'. They are descriptive but not uniform.
Tool Count5/5
13 tools is within the ideal 3-15 range for a language tutor. Each tool covers a distinct aspect of learning or assessment, and none feel redundant or missing.
Completeness5/5
The surface covers the full learning loop: diagnostic placement, concept practice, listening and pronunciation exercises, response correction, progress tracking, weak-point analysis, and corpus coverage. There are no obvious dead ends or missing core operations.
Average 3/5 across 13 of 13 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 39 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries all responsibility for behavioral disclosure. It does not state what the tool returns, whether it is a read-only operation, or any side effects. The phrase 'what the corpus covers and what it doesn't' is a scope statement, not a behavioral description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than effective conciseness. It omits essential information such as return format, parameter behavior, and usage context, making it an ineffective tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain what the tool returns and how to use it correctly. It does not even hint at what the output looks like or how the 'solo_vacios' parameter influences the result. The tool cannot be invoked correctly by an agent relying solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single parameter 'solo_vacios' with no description, and the tool description does not mention it at all. With 0% schema description coverage, the agent has no idea what this parameter does, what values are expected, or how it affects the output. The description fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Qu� cubre el corpus y qu� no' conveys that the tool is about coverage of the corpus, which is a vague purpose but not a pure tautology. It names the resource (corpus) and the two sides (covers/doesn't cover), but lacks a specific verb like 'get', 'check', or 'returns'. It does not clearly distinguish itself from siblings like 'buscar_concepto' or 'explicar_concepto' without additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It gives no context, no exclusions, and no reference to any sibling tool. This is a single clause with no actionable usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the content but does not indicate whether the operation is read-only, what 'peor dominados' means, or any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, almost terse. While brevity is good, it omits essential information about the parameter and behavior, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain the parameter and output format. It fails to do so, leaving gaps in agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'n' is completely undocumented in both the schema and the description, leaving agents to guess its purpose (likely a count limit).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the output as the weakest-mastered concepts with their prerequisites, which is a clear purpose. However, it lacks an explicit verb and does not differentiate from sibling tools like 'cobertura_concepto'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided; there is no mention of when to use this tool versus alternatives like 'diagnostico_inicial' or 'estado_alumno'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Busca' implies a read-only search, but no details are given about return format, behavior with missing query, pagination, or side effects. It adds little beyond the tool's name.
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 description is a single concise sentence with no filler, effectively front-loaded. However, it is too terse to provide sufficient context, bordering on under-specification rather than efficient clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description is inadequate for reliable tool invocation. It does not explain required inputs, expected output, or when to prefer this tool over siblings; only 'consulta' is hinted at.
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 description coverage is 0%, so the description must compensate. It partially clarifies that 'consulta' is the name/id search term, but leaves 'cefr' and 'limite' completely unexplained, ignoring two of three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Busca' (search) and identifies the resource 'conceptos', with criteria 'por nombre o id'. This makes the tool's purpose clear and distinct from sibling tools like 'explicar_concepto' or 'audio_de', though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not state prerequisites, when not to use it, or the relationship to sibling tools that also deal with concepts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool 'corrects' an auditory response, but does not explain whether it evaluates, provides feedback, modifies data, or requires specific permissions. The lack of detail about side effects or expected behavior is a significant gap.
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?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the action verb, but it is too brief to convey essential details. While brevity is good, the description would benefit from additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no output schema, and no annotations, the description is far too minimal. It does not address expected return values, parameter usage, or operational context. The description only provides a vague hint of the tool's purpose, leaving substantial gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (audio, concepto, respuesta) with 0% description coverage. The description does not explain what these parameters represent or how they relate to the correction process. With no guidance from the description, the agent cannot infer the meaning or format of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Corrige una respuesta de discriminación auditiva' clearly states the tool's action (correcting) and resource (an auditory discrimination response). It is specific enough to distinguish from sibling tools like comprobar_pronunciacion, which focuses on pronunciation, though it could be more explicit about the input-output relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or exclusions, leaving the agent without context for selecting it over similar tools like corregir_respuesta.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Propone un par de contraste' and does not disclose any behavioral details such as side effects, required inputs, or output format. This is a minimal statement that leaves much implicit.
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?
The description is a single concise sentence with no redundant words. It is front-loaded with the action and resource, making it efficient, though it may be too terse for full usefulness—but that is captured in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is incomplete. It does not explain the parameter semantics, the expected output, or when to use it in the broader learning context. The sibling tools suggest a language-learning environment, but the description lacks necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'concepto' with no description, and the tool description does not mention it at all. With 0% schema description coverage, the description fails to explain what 'concepto' means or how to use it, leaving the agent completely uninformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Propone' and a specific resource 'par de contraste' for pronunciation, clearly indicating the tool's function. It distinguishes from siblings like comprobar_pronunciacion or audio_de, though it does not explicitly differentiate from obtener_ejercicios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states what the tool does without mentioning prerequisites, contexts, or exclusions, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only says 'Resumen del progreso,' which implies a read-only operation but does not explicitly state that it has no side effects, what data is returned, or whether it reflects real-time or cached information. Minimal behavioral disclosure.
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?
The description is extremely concise, using a single short phrase. It is not verbose, but it is also too brief to provide meaningful guidance; the conciseness is adequate but does not fully compensate for the lack of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain what the progress summary contains, but it only gives a vague 'Resumen del progreso.' This leaves significant ambiguity about the nature of the returned information, especially relative to sibling tools.
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 input schema has zero parameters, and the description correctly implies no parameters are needed. With no parameters to document, the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resumen del progreso' indicates the tool provides a summary of the student's progress, which is a clear main function and distinct from sibling tools like puntos_debiles or diagnostico_inicial. However, it lacks specificity about what dimensions of progress are covered (e.g., overall, per skill), making it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool compared to siblings such as puntos_debiles or cobertura_concepto. The description does not mention any conditions for use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits such as whether it plays audio, returns a question, or requires a concepto. It only gives a static noun phrase and does not explain side effects, output, or dependencies.
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?
The description is a single sentence with no wasted words, but its brevity sacrifices necessary detail. It is front-loaded but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too thin. It does not say what the tool returns, how to call it, or how it fits with related listening tools, so an agent cannot reliably invoke it.
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?
The schema has one undocumented 'concepto' parameter with 0% description coverage. The description mentions 'phonetic contrast' but never explicitly maps it to the 'concepto' parameter, leaving the agent to infer what value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as an auditory discrimination question using minimal pairs for a phonetic contrast, which is a specific resource. However, it lacks a clear verb (e.g., 'generates', 'presents') and does not explicitly distinguish it from sibling tools like comprobar_escucha.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus siblings such as comprobar_escucha or audio_de. There is no mention of prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses that the tool records the attempt, which is a meaningful side effect, but it does not explain whether the correction is reversible, what permissions are needed, or how the correction is reported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the action and includes a key side effect. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values and broader context. It does not mention what the tool returns or how the correction is presented to the student, leaving the tool's full behavior underspecified.
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?
The input schema has zero parameter descriptions (0% coverage), so the description must compensate. It implies 'respuesta' is the student's answer and 'item' relates to the book key, but 'item' is never explicitly defined, leaving ambiguity.
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 description uses a specific verb 'Corrige' and identifies the resource ('la clave del libro') and a side effect ('registra el intento'). This clearly distinguishes the tool from siblings like comprobar_escucha and comprobar_pronunciacion, which target specific modalities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It doesn't mention conditions for use or exclusions, leaving the agent to infer appropriate contexts from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full responsibility for behavioral disclosure. It does not mention side effects, whether it mutates student state, return format, or any actions beyond providing exercises. The phrase 'to place a new student' implies a placement outcome but lacks explicit detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function and immediately followed by usage guidance. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and no annotations, the description is incomplete. It explains the purpose and usage but omits the meaning of 'n' and any details about the response or side effects. For a simple tool, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'n' with zero description coverage in the schema and no mention in the tool description. The description completely fails to explain what 'n' represents (e.g., number of exercises, level, or something else), making it impossible for an agent to correctly supply this parameter.
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 description clearly states the tool provides exercises distributed by level (A1/A2/B1) to place a new student, which is a specific verb+resource+scope. It distinguishes itself from sibling tools by explicitly targeting new student level placement.
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?
The description explicitly says 'Use it when someone starts or asks to know their level', providing clear when-to-use guidance. It does not mention when-not-to-use or alternative tools, but the usage context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a key behavioral constraint (never returns evaluation material) and implies a read-only operation. However, it does not detail return format, required parameters, or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose, and contains no unnecessary words. It is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no annotations and no output schema, the description leaves the 'n' parameter undefined and does not describe the return format or error behavior. The agent lacks sufficient context for confident invocation.
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 description coverage is 0%, so the description must compensate. It clarifies that 'concepto' is the concept to practice, but it does not explain the 'n' parameter at all, leaving significant ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides practice items for a concept, distinguishing it from evaluation material. However, it does not explicitly name sibling tools, so it lacks full sibling differentiation.
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?
The description explicitly indicates when to use the tool (for practicing a concept) and when not (never returns evaluation material). It does not name alternative tools, but the exclusion is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It states the core action and the corpus limitation, but does not mention output format, latency, side effects, permissions, or whether the tool modifies any state. It does not contradict any annotations because none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first front-loads the primary action, and the second adds useful context about why the tool exists. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is mostly adequate: it explains what the tool does and why it is needed. However, it lacks guidance on when to use it relative to sibling tools and does not describe the expected output, which is a gap given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'texto' string parameter with no description (0% schema description coverage). The description compensates partly by explaining that the text is the source for synthesis ('a partir de un texto') and gives examples, but it does not specify language constraints, length limits, or text formatting requirements.
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 description clearly states the tool's function: 'Sintetiza polaco hablado a partir de un texto' (synthesizes spoken Polish from text). It also provides concrete use cases (dictados, diálogos, shadowing), which distinguishes it from sibling tools like escuchar or comprobar_pronunciacion that deal with listening/pronunciation rather than generating audio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is implied: since the corpus has transcriptions but no audio files, this tool is used to generate the missing audio. However, it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions comparing two recordings but does not describe the output (e.g., boolean, score), side effects, or prerequisites. This is minimal transparency beyond the tool's obvious purpose.
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?
The description is a single, concise sentence with no filler. However, it sacrifices necessary detail for brevity, so it is not maximally effective for a tool with 5 parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, this one-sentence description is insufficient. It fails to explain what the tool returns, the role of 'concepto', or any special requirements, making it incomplete for practical invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It implicitly maps 'dos grabaciones' to audio_a/audio_b and 'dos palabras' to palabra_a/palabra_b, but it does not clarify the 'concepto' parameter or explicitly reference parameter names, leaving gaps.
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 description clearly states the tool's function: 'Comprueba si el alumno produce el contraste entre dos palabras, comparando sus dos grabaciones entre sí.' This is specific and distinguishes it from siblings like 'comprobar_escucha' by focusing on pronunciation contrast.
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?
The description implies the use case: when you need to check if a student can produce a contrast between two words. It provides clear context but does not explicitly mention alternatives or when not to use this tool. 'Comprueba si el alumno produce el contraste...' is a strong indicator of when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of transparency. It discloses that the output will include a definition, dependencies, study location, and a book/page citation, which gives the agent a clear expectation of the response. It does not mention side effects or error handling, but these are less critical for a read-only explanation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action 'Explica un concepto', followed by a concise list of content elements. There is no redundant information or filler.
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?
For a simple tool with one parameter and no output schema, the description provides sufficient context: it explains what the tool does, what the output will contain, and cites sources. It could mention potential errors or input format, but the core functionality is well-covered. The lack of annotations and output schema is compensated by the descriptive text.
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 schema has a single 'concepto' param with 0% description coverage. The description adds meaning by stating that the tool explains a concept, clarifying that 'concepto' is the subject of the explanation. It also describes the content of the explanation, which helps the agent understand what to pass, though it doesn't explicitly map the parameter name.
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 description clearly states the tool's function: 'Explica un concepto' (explains a concept) with specific sub-details (what it is, dependencies, study location, citation). This differentiates it from sibling 'buscar_concepto', which implies searching rather than explaining. The verb+resource is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for use (when you need a detailed explanation with source) but does not explicitly mention alternatives or when not to use it. Sibling tools like 'buscar_concepto' or 'obtener_ejercicios' are not referenced, so the agent must infer the appropriate use case. This is implied usage, not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![polski-tutor MCP server](https://glama.ai/mcp/servers/maution/polski-tutor/badges/card.svg)](https://glama.ai/mcp/servers/maution/polski-tutor)

Score Badge

Copy to your README.md:

[![polski-tutor MCP server](https://glama.ai/mcp/servers/maution/polski-tutor/badges/score.svg)](https://glama.ai/mcp/servers/maution/polski-tutor)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/maution/polski-tutor'

If you have feedback or need assistance with the MCP directory API, please join our Discord server