ielts-speaking-coach MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.50
Disambiguation4/5
Most tools are clearly distinct: initialization, selection, dashboard, context, question bank (list/import), session review, history, and data retrieval each serve a unique purpose. The only minor ambiguity is between get_dashboard_data and get_training_context, and between open_dashboard and get_dashboard_data, which both touch dashboard-related concerns but differ in interaction style (UI open vs data fetch).
Naming Consistency4/5
Tools follow a consistent verb_noun pattern: initialize/list/import/save/get/set/open prefixes with clear object nouns. The pattern is largely predictable, though mixing first-word verbs (initialize, set, open, get, list, import, save) is fine—the objects (workspace, selection, dashboard, context, question_bank, session_review, history, data) are consistently snake_case nouns.
Tool Count5/5
Nine tools is well-scoped for an IELTS speaking coach server. Each tool covers a distinct workflow step (init, configure, view options, retrieve context, browse/import questions, save review, view history, fetch dashboard), and none feel redundant or trivial.
Completeness4/5
The tool surface covers the full practice lifecycle: workspace setup, training selection/configuration, question bank management (list/import), session review saving, and history/dashboard retrieval. Minor gaps include no tool to update or delete the question bank (only import), and no tool to directly edit saved reviews, but the core workflow is complete and functional.
Average 3.4/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, which indicate this mutates local state. The description says 'save them to the learner's local question bank' which implies persistence, but doesn't disclose whether existing questions are overwritten, merged, or duplicated. It doesn't mention validation behavior, failure handling, or whether the import is transactional. With no destructive hint and multiple possible write behaviors, more disclosure is needed.
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?
Single efficient sentence that conveys the core action and target within one clause. No wasted words. It's appropriately compact, though it could arguably be longer given the lack of behavioral disclosure elsewhere. Structure is clean and front-loaded with the primary verb.
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?
The tool has 3 parameters with 0% schema description coverage, no enums, and no nested objects, so the description is the primary documentation source. Yet it fails to explain the JSON format requirements, the relationship between sourceName/sourceUrl, merge vs replace behavior, response/return values (though output schema exists), and interaction with siblings like list_question_bank. For an import tool, this is notably incomplete.
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 description coverage is 0%, so the description carries the full burden for parameter meaning. However, the description itself mentions 'JSON array' which aligns with questionsJson, and 'normalized' hints at expected format. But it doesn't explain sourceName vs sourceUrl distinction, what maxLength limits imply, or what 'normalized' actually means structurally. The description adds partial meaning beyond the schema but leaves the parameter semantics significantly under-specified.
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 action (import), the resource (IELTS speaking questions from a JSON array), and the destination (learner's local question bank). It uses a specific verb+resource construction that effectively communicates the core function. It doesn't explicitly distinguish from sibling tools like list_question_bank, but the import-vs-list distinction is reasonably implied.
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 gives no guidance on when to use this tool versus alternatives like list_question_bank or initialize_ielts_workspace. It also doesn't clarify whether an initial workspace must exist before importing, whether the import appends to or replaces existing questions, or what format expectations exist beyond 'normalized.' No exclusions or alternative tool recommendations are provided.
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?
Annotations include readOnlyHint=false, which partially signals this is a mutating operation, and the description's 'Create' verb aligns. However, no annotations declare auth requirements or idempotency, and the description adds nothing about what 'creating a workspace' entails — does it overwrite existing data? Is it safe to call multiple times? What gets created? With a mutating operation and only minimal annotation coverage, the description carries more burden than it satisfies.
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, efficient sentence with zero waste. It front-loads the core action ('Create the learner's private local data workspace') and adds relevant timing context. Brief but complete for what it attempts to convey.
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 stateful initialization tool (readOnlyHint=false) with no output schema explanation in the description and an optional parameter that isn't explained, this is under-specified. The description doesn't address idempotency (a key concern for 'initialize' operations), return behavior, or the effect of the displayName parameter. Given the tool's mutating nature and the existence of an output schema, more disclosure is warranted.
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?
There is only one optional parameter, displayName, with no required params and 0% schema description coverage. The description does not mention displayName at all — what it does or how it affects workspace creation. However, with a single, self-explanatory parameter name (displayName), the schema arguably conveys most meaning. The description adds nothing beyond schema for this parameter, so baseline is appropriate.
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 states a specific verb (Create) and a resource (learner's private local data workspace), and provides clear context (before the first practice session). It distinguishes the action from sibling tools like set_training_selection and open_dashboard, though it doesn't explicitly contrast them. The purpose is genuinely clear and specific.
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 implies usage context via 'before the first practice session' but provides no when-to-use vs alternatives guidance, no prerequisites, and no exclusion scenarios. There is no mention of when NOT to call this tool (e.g., if workspace already exists) or whether it's safe to call repeatedly. The one usage hint ('before first session') is helpful but insufficient for an initialize/stateful operation.
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?
Annotations declare readOnlyHint=false, destructiveHint=false, providing a baseline safety profile. The description adds that it 'saves' a 'freely chosen route' and 'practice settings,' implying a persistence/write action. It doesn't disclose side effects like overwriting existing selections or whether the save is required for a valid session, but annotations already cover the mutation/destruction dimensions.
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?
A single, efficient sentence that earns its place by defining scope ('before a Voice session') and content ('freely chosen route' and 'practice settings'). No wasted words. Could slightly enrich by listing the key saved fields, but stays appropriately tight.
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?
The tool has 8 parameters (3 enums), 0% schema coverage, and an output schema exists. For a complex setup tool with multiple route enums and conditional parameters (questionId vs questionIds, planItemId, selectedReference), the description provides minimal context: it says it saves route and settings but doesn't explain the selection logic, how the route values map to required parameters, or what the output represents. The output schema exists, which slightly lowers the burden, but for a tool with this param complexity, the 2-3 sentence description is insufficient.
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 for explaining parameters. The description mentions 'route' and 'practice settings' at a high level, partially mapping to 'route' and 'length' parameters, but it does not explain the semantics of required parameter 'part' (Part 1/2/3 vs Full mock) or optional params like questionId vs questionIds, planItemId, or singleGoal, nor when each route value is appropriate. With 8 parameters at 0% coverage, this is a significant gap.
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 states a specific action ('Save the learner's freely chosen route and today's practice settings before a Voice session') with a clear resource (training selection). It distinguishes the tool's role as a pre-session setup action versus siblings like 'save_session_review' (post-session). However, it does not explicitly differentiate from 'get_training_context' or 'initialize_ielts_workspace' beyond implying setup.
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 signals the timing ('before a Voice session'), giving a clear context for when to call it. However, it does not explicitly state when NOT to use it or name alternative tools. There is no exclusion guidance, e.g., when to use save_session_review vs this, or get_training_context vs this.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the agent knows this is a safe, bounded read operation. The description adds that it lists 'imported' content (establishing the data source). With annotations covering the safety profile, the description's marginal value is modest but present, landing at a 3 rather than higher.
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?
A single concise sentence that front-loads the core purpose and mentions the filtering options. Zero wasted words, appropriately sized for a read-only listing tool. Every element earns its place.
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?
The tool has an output schema (which explains return values, reducing the description's burden) and good annotations for safety. The description covers the primary function and filter options. However, with 0% schema coverage for the three params, it would benefit from a bit more prose on search semantics and limit behavior to be fully complete.
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 description coverage is 0%, meaning the description must compensate for documenting parameters. The description mentions filtering by 'Part or search text' which maps to the part and search parameters, and implies limit exists. However, it doesn't clarify the exact 'Part' enum values beyond what the schema shows, nor whether search applies to topic names, exact question text, or both. The limit param's semantics and default are undocumented in prose.
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 states a clear verb+resource ('List imported IELTS speaking topics or exact questions') with optional filters. It distinguishes the read-only listing purpose from sibling tools like import_question_bank (ingestion) and get_training_context (retrieval of a specific session context). However, it doesn't explicitly differentiate from other read-only list tools like get_dashboard_data or list_practice_history, though the domain (question bank vs practice history) is implied.
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 implies usage context ('imported topics', 'optionally filtered by Part or search') which suggests this operates on an already-imported bank, and the sibling name import_question_bank implies the prerequisite. However, it doesn't explicitly state when to use this vs alternatives like get_dashboard_data or get_training_context, nor does it state when not to use it.
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?
Annotations declare readOnlyHint=false and destructiveHint=false, which already indicate this is a write (non-readonly) operation that isn't destructive. The description adds that it saves 'the fixed-format Markdown review' and 'its machine-readable JSON record', giving some specification about what gets persisted. It doesn't mention overwrite behavior, ID association, or whether the session must exist first.
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?
A single, concise sentence that fronts the verb and resource clearly. Every word earns its place - no filler, no redundancy, efficient delivery of purpose.
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 tool with 2 required params, 0% schema coverage, and no explanation of the fixed format or how sessionId relates, some gap remains. The output schema exists but its content isn't shown in the definition. The description adequately covers the core save action but omits details about the reportJson format requirements and session association semantics.
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 description coverage is 0%, so the description carries the burden for parameter meaning. It references reportMarkdown (fixed-format Markdown review) and reportJson (machine-readable JSON record), adding meaning beyond the bare schema. However, it doesn't explain the 'fixed format' specifics, required format of reportJson, or the role of sessionId (which is optional in schema).
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 states a clear action: saving a fixed-format Markdown review and its JSON record after a practice session. It identifies the two artifacts (reportMarkdown, reportJson) and the timing ('after a practice session'). However, it doesn't distinguish from potential siblings like list_practice_history, though those are reading tools, so sibling differentiation is less critical here.
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 conveys this is used post-practice-session to persist review artifacts. It doesn't explicitly state when NOT to use it or name alternatives, but the context (after a practice session) is clear. No exclusions or alternative tool references are provided.
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?
Annotations provide readOnlyHint=false, openWorldHint=false, and destructiveHint=false, which give some baseline. The description adds that this opens a 'learner's private local' dashboard, conveying a personal-scope and UI-navigation behavior. However, it doesn't disclose what 'open' entails (e.g., whether it navigates the learner's browser, launches a local file, or returns a view) or any side effects, leaving behavioral clarity incomplete.
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?
One clean sentence that states the action, target, and purpose. It is front-loaded and free of filler. A minor deduction because 'with buttons' is slightly redundant detail, but the overall structure is tight and effective.
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?
Given this is a zero-parameter, navigation-style tool with an output schema present, the description is adequately complete. It explains the purpose and scope. It could be enhanced by clarifying what happens after opening (what the output represents) and its relationship to get_dashboard_data, but the presence of an output schema reduces that burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (nothing to document). Per the rubric, 0 params earns a baseline of 4. The description doesn't need to add parameter semantics since there are none, and it correctly conveys the tool requires no inputs.
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 states a specific verb ('Open') and resource ('learner's private local dashboard') with a clear purpose ('to choose a practice route with buttons'). It distinguishes itself from siblings like get_dashboard_data, which likely returns data rather than opening a UI. Slight ambiguity about what 'open' means in an MCP context (navigate vs. launch) prevents a 5.
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 implies this is a navigation/action tool to reach the dashboard for choosing practice routes, contrasting with get_dashboard_data. However, it does not explicitly state when to use this versus get_dashboard_data or when not to use it. There is also no mention of prerequisites like whether the workspace must be initialized first (sibling initialize_ielts_workspace suggests this may be needed).
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?
Annotations provide readOnlyHint=true and destructiveHint=false, largely covering the safety profile. The description adds scope context ('local session and target data') beyond annotations. It doesn't disclose whether data requires initialization or whether an empty result is possible if no session exists, but with annotations covering safety, a mid score is appropriate.
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?
Single, efficient sentence. Zero wasted words, clearly front-loaded with the resource type and purpose. Nothing extraneous.
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?
The tool is a simple no-parameter read operation with strong annotations (readOnlyHint, destructiveHint) and an output schema present. For a zero-parameter retrieval tool, the description adequately captures scope. Could note behavior when no data exists yet, but the output schema likely handles structure, keeping this mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and schema coverage is 100%, so the baseline is 4. With no parameters to document, the description doesn't need to add parameter semantics. There is nothing missing here since there are no params.
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?
Clear verb+resource: 'Return the learner's local session and target data' specifies what data is retrieved. The purpose for a dashboard/progress summary is stated. It doesn't explicitly distinguish from siblings like get_training_context, but the resource ('local session and target data') is reasonably specific.
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 implies use when building a dashboard or progress summary. It doesn't name alternatives or exclusions, though sibling tools like open_dashboard could overlap. The context is implied rather than explicit, and no when-not-to-use guidance is given.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds context about what data is read (selection, sessions, saved target) but doesn't disclose details like return format, size of data returned, or rate limits. With annotations covering the safety profile, the additional value is the 'optional saved target' mention, which is modest. No contradiction with annotations.
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?
Single sentence, zero wasted words. Every clause adds meaning: what's read (selection, sessions, saved target), and when (before continuing or retraining). Perfectly front-loaded with the action verb and resource in the opening clause.
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?
The tool is simple (0 params, read-only, no nested objects) and has an output schema present, which covers return-value documentation. The description sufficiently establishes what context is gathered and when to call it. It is complete for a parameterless read tool with annotations and an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so schema coverage is trivially 100%. Per the rubric, 0 params earns a baseline of 4. The description correctly implies no inputs are needed and simply reads current state, which aligns with the parameterless signature. No parameter ambiguity exists to resolve.
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?
Clear verb+resource: 'Read the current selection, recent sessions, and optional saved target' precisely describes what this tool retrieves (training context) for the purpose of continuing or retraining. It distinguishes adequately from siblings like get_dashboard_data and list_practice_history since it's specifically about training context rather than dashboards or raw history.
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 phrase 'before continuing or retraining' provides clear context for when to use the tool (at the start of a training flow). However, it doesn't explicitly exclude alternatives or name sibling tools that might be confused with it. The usage guidance is implied through the purpose statement rather than explicitly stated.
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?
Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is already established. The description adds the 'locally saved' scoping detail, clarifying that sessions are stored locally rather than cloud-based. However, it doesn't describe return format, ordering, or pagination behavior. The description adds modest value beyond annotations but not rich context.
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?
A single concise sentence that states the action clearly without wasted words. It names the verb (list), resource (recent locally saved IELTS speaking sessions), and purpose (for review or optional retraining). Efficient and well-structured.
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?
The tool has only one parameter already fully documented in the schema (limit with min/max/default), a readOnly annotation, and an output schema. For such a simple listing tool, the description covers the essential intent. The purpose statement ('for review or optional retraining') adds useful context for when the agent might want this. Adequate completeness for a low-complexity tool.
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 description coverage is 0%, meaning the description itself contains no parameter documentation. However, the single parameter 'limit' is fully self-documenting via the schema (integer, default 10, min 1, max 50) — its semantics are obvious. With only 1 param and the description noting 'recent' sessions (implying ordered output), the parameter meaning is clear without additional explanation. No meaningful gap exists.
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?
'List recent locally saved IELTS speaking sessions' uses a specific verb (list) plus a clear resource (IELTS speaking sessions) and a scoping modifier (recent, locally saved). The purpose statement 'for review or optional retraining' adds valuable intent context. It distinguishes from siblings like get_dashboard_data (which aggregates different data) and get_training_context (training-specific). Clear and specific.
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 implies use cases ('for review or optional retraining') but does not explicitly distinguish when to use this tool versus siblings like get_dashboard_data, save_session_review, or set_training_selection. No when-not-to-use guidance or alternative recommendations are provided. Some context is implied via the purpose phrase, but explicit comparison to alternatives is absent.
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:

[![ielts-speaking-coach MCP server](https://glama.ai/mcp/servers/lindsey-labs/ielts-speaking-coach/badges/card.svg)](https://glama.ai/mcp/servers/lindsey-labs/ielts-speaking-coach)

Score Badge

Copy to your README.md:

[![ielts-speaking-coach MCP server](https://glama.ai/mcp/servers/lindsey-labs/ielts-speaking-coach/badges/score.svg)](https://glama.ai/mcp/servers/lindsey-labs/ielts-speaking-coach)

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/lindsey-labs/ielts-speaking-coach'

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