Read-only MCP endpoint for IELTS Writing Task 2 sample answers, Speaking Part 2 cue card topics and Writing band descriptors. No API key, no account, no install step.
Scored across 4 tools
Each tool has a clearly distinct purpose: band descriptors, writing sample listing, writing sample retrieval, and speaking cue cards. The list/get writing sample pair is explicitly cross-referenced, so selection is unambiguous.
All tool names use snake_case and follow a predictable verb_noun pattern with get_* and list_* prefixes. The convention is consistent throughout the small set.
Four tools is well-scoped for a focused IELTS content retrieval server. Each tool serves a distinct content type, with no filler or redundant operations.
The server covers writing band descriptors, Task 2 sample listing/retrieval, and Speaking Part 2 cue cards with a clear list/get lifecycle. Minor gaps remain, such as Task 1 writing samples and speaking sample answers, but core self-review workflows are covered.
Get the four IELTS Writing assessment criteria, the Task 1 and Task 2 differences, and plain-language summaries of Band 5 to Band 8. Useful for essay self-review, feedback prompts and study plans.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds scope detail the annotations cannot: it discloses exactly which content is returned and, importantly, that band summaries only span 5–8, which prevents the agent from promising Band 9 or Band 4 guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence enumerating the returned content, followed by a short use-case clause. Every element earns its place; no rephrasing of the title or 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?
For a static, parameterless reference lookup with no output schema, the description is nearly sufficient: content scope and band range are stated. It could go one step further and say whether the result is structured/markdown text and that criteria are criterion-by-criterion, but nothing blocks a correct call.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. No misleading parameter claims are made.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the four IELTS Writing assessment criteria') and enumerates the exact payload: criteria, Task 1/Task 2 differences, and Band 5–8 summaries. This is clearly distinguishable from the sibling sample/cue-card tools, which return user content rather than reference material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage context ('essay self-review, feedback prompts and study plans'), which tells the agent when this reference lookup is worth calling. It does not name alternatives or exclusions (e.g., telling the agent to prefer get_writing_sample when a concrete example is needed), 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.
Read one public IELTS Writing Task 2 sample answer in full, including the prompt, model essay text, reference band and word count. Use list_writing_samples first to find a sampleId.
| Name | Required | Description | Default |
|---|---|---|---|
| sampleId | Yes | Public sample ID returned by list_writing_samples. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context by listing what the read returns: prompt, model essay text, reference band, and word count.
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 tightly written sentences with the core action front-loaded. The prerequisite is included without extra verbosity.
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?
The tool is a simple read operation, annotations cover safety, the schema fully documents the only parameter, and the description explains the returned fields despite no output schema.
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 the single sampleId parameter is already documented. The description repeats that list_writing_samples is the source of sampleId, but adds little beyond the schema's own parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: read one public IELTS Writing Task 2 sample answer in full. It also names the returned contents and distinguishes itself from list_writing_samples by focusing on one full sample.
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 says to use list_writing_samples first to find a sampleId. This gives clear routing to the sibling tool and the prerequisite for obtaining the required parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public IELTS Speaking Part 2 cue card topics from the Youshow IELTS speaking question bank. Returns the cue card prompts, the points to cover and related Part 3 questions, in English or Chinese.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of cue cards to return. Defaults to 5, capped at 10. | |
| locale | No | Language of the cue card content. Defaults to zh. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by stating that it returns cue card prompts, speaking points, and related Part 3 questions, and that content is public and available in English or Chinese. It does not add caveats about pagination or result ordering, but that is a minor gap given 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?
The description is two tight sentences with no wasted language. The main purpose is front-loaded, followed immediately by useful return-content context.
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 two-parameter, read-only listing tool with no output schema, the description provides enough context about what is returned and the language options. It could be slightly stronger with explicit usage guidance, but the core calling information is complete.
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 parameters are already documented in the schema, including the limit cap and locale default. The description reinforces the English/Chinese language dimension but does not add significant semantic detail beyond the schema, so the baseline of 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 states a specific verb and resource: list public IELTS Speaking Part 2 cue card topics from a named question bank. It also scopes the content clearly to cue cards, prompts, points to cover, and related Part 3 questions, which distinguishes it from the writing-sample and band-descriptor 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 does not say when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The IELTS Part 2 context implies a use case, but there is no explicit routing guidance despite multiple sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public IELTS Writing Task 2 sample answers from Youshow IELTS. Returns the essay prompt, source paper, reference band, word count and a short preview for up to five model essays. Use get_writing_sample with a sampleId to read the full essay.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of public samples to return. Defaults to 5, capped at 5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds substantive behavioral context beyond them — the returned fields (prompt, source paper, reference band, word count, preview) and the hard cap of five results, which is a real constraint an agent must know. It does not mention ordering or how samples are selected, which keeps it below a 5.
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, front-loaded with what is listed and where from, then return contents, then the alternative tool. No filler, and the routing hint is placed last where it is most actionable.
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 no output schema, the description compensates by enumerating the returned fields, and it names the follow-up tool, so an agent has enough to call it and use the result. Minor gaps remain (no mention of how samples are ordered or filtered), but nothing essential is missing for a simple read-only 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 coverage is 100% and the single 'limit' parameter already documents the range and default. The description's 'up to five model essays' reinforces the cap but adds no syntax or semantics the schema lacks, so 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?
States a specific verb and resource ('List public IELTS Writing Task 2 sample answers from Youshow IELTS') and immediately distinguishes itself from the sibling get_writing_sample by contrast (list/preview vs full essay). An agent can tell exactly what this returns without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: 'Use get_writing_sample with a sampleId to read the full essay', which makes the list-then-fetch pattern obvious. It lacks an explicit 'when-not-to-use' statement (e.g., vs list_cue_cards), but the resource distinction is self-evident.
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.
get_band_descriptorsget_writing_samplelist_cue_cardslist_writing_samples
Add one secure layer between your agents and this server.