What can you do with this server?

This MCP server provides tools to search and retrieve information from the Ace Achievers course catalog and question bank, enabling MCP-compatible AI clients to answer queries about courses, practice questions, and pricing. * Search Courses – Filter the 26-course catalog by subject (maths, science, computer-science), year level (5–12), and course type (e.g. foundation, advanced, mock, bundle, acceleration). * Get Course Details – Retrieve full details for a specific course by ID, including structure, target band, and free-tier info. * Search Questions – Search the practice question bank by topic (e.g. geometry, algebra, number-theory) and/or difficulty (easy, medium, hard); returns question stems only, never solutions. * Get Question with Tiered Hints – Fetch a specific question with controlled hint reveal: level 0 (question only), level 1 (nudge), level 2 (approach), level 3 (full solution), enforcing pedagogical guardrails server-side. * Get Question Bank Statistics – Overview of the question corpus with counts by subject, difficulty, and topic. * Get Pricing Info – Returns a redirect to the live pricing source rather than stored prices, ensuring up-to-date information. The server can use a bundled sample question set or be configured to load larger private question banks via environment variables, and integrates with MCP-capable clients like Claude Desktop.

How do I use Ace Achievers MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Ace Achievers MCP Server Find a hard geometry question and give me a nudge hint" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Ace Achievers MCP Server

by Star4future

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Ace Achievers MCP Server

An MCP (Model Context Protocol) server exposing the Ace Achievers course catalog and question-bank tools to any MCP client — Claude Desktop, Claude Code, or your own agent.

Python MCP MIT

What this is

MCP is the open standard that lets an LLM agent call typed tools over a common wire protocol (JSON-RPC over stdio or HTTP) — write the server once, and any MCP-capable client can use it. This server packages the product-data tools I built for an Australian K-12 competition-learning platform, so an agent can answer "which course fits a Year 7 student new to competition maths?" against live catalog data instead of guessing.

Related MCP server: University Course Catalog MCP Server

Tools

Tool	What it does
`search_courses(subject?, year_level?, course_type?)`	Filter the 26-course catalog (maths / science / computer-science, Years 5–12)
`get_course(course_id)`	One course in full — structure, target band, free-tier info
`search_questions(topic?, difficulty?)`	Search the question bank — returns stems only, never spoilers
`get_question(question_id, hint_level)`	Tiered reveal: 0 = question, 1 = nudge, 2 = approach, 3 = full solution
`qbank_stats()`	Corpus overview — data source and counts by subject / difficulty / topic
`get_pricing_info()`	The redirect-volatile pricing contract (see design notes)

Quick start

git clone https://github.com/Star4future/aceachievers-mcp-server
cd aceachievers-mcp-server
pip install -e ".[dev]"
pytest                      # 16 tests
aceachievers-mcp            # runs the stdio server

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "aceachievers": {
      "command": "aceachievers-mcp"
    }
  }
}

Then ask Claude: "Find a hard geometry question and give me a nudge, not the answer."

TypeScript client

The server is Python; the product that would consume it is TypeScript. So the repo also ships a typed, zod-validated TS/Node client (clients/ts/) built on the official @modelcontextprotocol/sdk — the same six tools behind typed methods, every result validated at runtime (not cast):

cd clients/ts
npm install
npm run test:unit    # 5 hermetic tests — green with NO Python installed
npm test             # + 4 integration tests against the real server
npm run demo         # call every tool through the typed client
npm run report       # catalogue contract check (a real consumer, CI-gated)

See clients/ts/README.md for the design notes.

Design notes

Redirect-volatile pricing. Prices and enrolment windows change on the live site, so this server refuses to store them: get_pricing_info returns the live source instead of numbers. Stable facts (course structure, topics, question content) are served from the bundled snapshot. This is the same volatile/stable knowledge split that let the platform's production chat assistant absorb a 3× catalog expansion with zero pricing-logic rewrites — the bot can't go stale on facts it never stored.

Tiered hint reveal. get_question mirrors the production RAG tutor's pedagogy: a student who asks for a nudge must not receive the answer, so hints unlock level by level and the listing view never includes solutions. The guardrail lives server-side — the client can't accidentally spoil.

Sample data in the repo, real bank via env. The bundled question set is original material written for this demo in the production bank's format; licensed past-paper content is not redistributed here. The production deployment points these same tools at the private store (2,500+ taxonomically classified problems, extracted from PDFs via a Vision-API pipeline) — implemented via environment variables, with records from both production schemas (AMC maths and science-olympiad) normalised onto one shape (private_bank.py):

# option 1 — explicit files, ";"-separated
QBANK_PATHS="D:\private\amc_junior.json;D:\private\jso_master.json"
# option 2 — a directory of *.json bank files
QBANK_DIR="D:\private\qbank"

No env vars → the bundled sample serves; unknown ids and missing hints degrade gracefully.

Layout

src/aceachievers_mcp/
├── server.py          # FastMCP server: 6 tools, pure logic separated for testing
├── private_bank.py    # env-configured private bank loading + schema normalisation
└── data/
    ├── courses.json           # 26-course catalog snapshot (no prices — by design)
    └── sample_questions.json  # 10 original questions with 3-tier hints
scripts/demo_client.py # stdio client that exercises all six tools end-to-end
tests/test_tools.py    # 16 unit tests
clients/ts/            # typed, zod-validated TypeScript/Node client (9 tests + CI)

License

MIT — see LICENSE.

Tool Definition Quality

A4.4/5.0

Tool DescriptionsA

Average 4.2/5 across 5 of 5 tools scored.

Server CoherenceA

Disambiguation5/5

Each tool targets a distinct resource: courses, pricing, and questions. Get vs search are clearly separated, and no two tools overlap in purpose.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using 'get' or 'search', with clear and predictable names.

Tool Count5/5

With 5 tools, the set is well-scoped for the domain of retrieving course and question information, neither too sparse nor overloaded.

Completeness5/5

The tool set covers retrieval and search for courses and questions plus pricing info. No obvious gaps for the stated purpose of an informational assistant.

Available Tools

5 tools

get_courseA

Get one course by id (e.g. "amc-foundation").

Includes structure, target band and free-tier info. Pricing is deliberately redirected to the live source rather than stored.

ParametersJSON Schema

Name	Required	Description	Default
`course_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

Tool Definition Quality

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description discloses the key behavioral trait that pricing is redirected to a live source. It also lists included information (structure, target band, free-tier info), though it lacks details on error handling.

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?

Three concise sentences with the core action front-loaded, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple get-by-id tool with an output schema, the description covers the purpose, included data, and a notable processing behavior. No major gaps given the simplicity.

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?

With 0% schema description coverage, the description adds an example of the id format ('amc-foundation') but does not fully describe parameter constraints or format.

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 action 'Get one course by id' with an example, distinguishing it from siblings like search_courses (which likely returns multiple) and get_pricing_info.

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?

It implies that for pricing data one should use a different tool (pricing redirect to live source) but does not explicitly list alternatives or when to use this vs search_courses.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pricing_infoA

How to answer pricing questions: returns the live pricing source.

Prices are deliberately not stored in this dataset (redirect-volatile design) — always send users to the live page for money amounts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

Tool Definition Quality

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, but the description discloses that prices are not stored and users must be directed to the live page. This is an important behavioral trait for a read-only tool, though it doesn't elaborate on other aspects like rate limits or authentication.

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 extremely concise (two sentences) and front-loads the purpose. Every sentence provides essential information without redundancy.

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 the lack of parameters and presence of an output schema, the description is adequate. It explains the core functionality and design choice. It could mention the output format, but the output schema likely covers that.

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?

With zero parameters, the schema coverage is 100%. The description adds meaning by explaining the purpose of the tool, which is necessary since the input schema is empty. It clarifies what the tool does beyond the schema.

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 returns 'the live pricing source' and explains the design rationale. It is specific to pricing queries, distinguishing it from siblings like get_course or search_questions.

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 'How to answer pricing questions' and instructs to 'always send users to the live page for money amounts,' providing clear context for when to use this tool. While it doesn't mention alternatives, siblings are unrelated to pricing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_questionA

Fetch one question with tiered hint reveal.

Args: question_id: e.g. "SAMPLE-NT-001". hint_level: 0 = question only, 1 = + nudge, 2 = + approach, 3 = + full solution and answer.

ParametersJSON Schema

Name	Required	Description	Default
`hint_level`	No
`question_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

Tool Definition Quality

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Explains tiered hint reveal behavior, but lacks details on error handling or return structure; no annotations provided.

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?

Very concise with bullet-point parameter descriptions, front-loaded purpose, and no unnecessary words.

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?

With output schema present, return values need not be detailed, but missing mention of invalid inputs or error cases; adequate for simple tool.

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?

Adds meaning beyond schema by providing example for question_id and defining hint_level values 0-3, compensating for 0% schema description coverage.

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?

Clearly states it fetches one question with tiered hint reveal, distinguishing from siblings like search_questions for searching multiple questions.

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?

Implies usage for fetching a single question with hints, but does not explicitly state when to use vs alternatives like search_questions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_coursesA

Search the course catalog.

Args: subject: "maths", "science" or "computer-science". year_level: student year level (5-12); matches courses covering it. course_type: substring filter — "foundation", "advanced", "mock", "bundle" or "acceleration".

Returns matching courses (no prices — see get_pricing_info).

ParametersJSON Schema

Name	Required	Description	Default
`subject`	No
`year_level`	No
`course_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

Tool Definition Quality

A4.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It states it returns matching courses but doesn't disclose read-only status, pagination, rate limits, or side effects. For a search tool, the lack of behavioral detail is a minor gap; transparency is adequate but not comprehensive.

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?

Description is concise with clear sections (Args, Returns). It uses bullet points for parameters and ends with a useful note about pricing. No superfluous text; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (context: has output schema = true), the description doesn't need to detail return values. It covers all essential aspects: purpose, parameters with semantics, and a key limitation (no prices). The tool is well-documented for an AI agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so description must compensate. It does so excellently: subject lists allowed values ('maths', 'science', 'computer-science'), year_level explains meaning and range (5-12), course_type gives examples and states substring filter. This adds significant meaning beyond the schema.

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 'Search the course catalog' and distinguishes from siblings like get_course (specific course) and get_pricing_info (prices). It provides specific parameters and their values, making the purpose unambiguous.

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?

Description gives explicit guidance: 'Returns matching courses (no prices — see get_pricing_info)' redirects users needing pricing. It specifies parameter types and allowed values (subject enum, year_level range, course_type substring filter). However, it doesn't explicitly state when to use this tool over get_course or search_questions, though implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_questionsA

Search practice questions (sample set bundled with this repo).

Args: topic: substring filter — "number-theory", "geometry", "counting", "algebra", "rates". difficulty: "easy", "medium" or "hard".

Returns question stems only; fetch hints/solutions via get_question.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	No
`difficulty`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

Tool Definition Quality

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It states that the tool returns only question stems and mentions the sample set. However, it does not disclose potential destructive behavior (likely none), authentication needs, or rate limits.

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 very concise and well-structured: a one-line summary, then arg specifications, then return info and cross-reference. No unnecessary words.

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 the simplicity of the tool (2 parameters) and the presence of an output schema, the description is sufficiently complete. It covers purpose, parameters, return values, and the relationship to a sibling tool.

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 0% description coverage, so the description adds essential meaning. It lists valid values for topic and difficulty and indicates that topic performs a substring filter. This is very helpful, though it could be more precise about matching behavior.

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 'Search practice questions' with a specific verb and resource. It distinguishes itself from the sibling 'get_question' by noting that this tool only returns question stems, and hints/solutions require the other tool.

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 to use 'get_question' for hints/solutions, providing a clear alternative. It also lists valid argument values, guiding when to filter by topic or difficulty.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

license - permissive license

quality

maintenance

How are these scores calculated?

Maintenance

0Releases (12mo)

Commit activity

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Tools

Related MCP Connectors

mcp
app.aspirelearning
Aspire Learning MCP — browse courses, chapters, lessons, and import LaTeX quizzes
Education & Learning Tools Content Management Systems
2
HiveLearn A
io.github.williamechevarria
Read and author HiveLearn courses, events, quizzes, certificates, resources, leaderboards, tracks.
Education & Learning Tools Content Management Systems Workplace & Productivity
572
StudioMeyer Academy A
io.studiomeyer
The Academy curriculum as an offline MCP library. Hosted course connector adds progress.
Education & Learning Tools AI & Machine Learning
21
Vocab Voyage A
io.github.jaideepdhanoa
20 MCP tools + 17 widgets for SAT/ISEE/SSAT/GRE/GMAT/LSAT prep. Flashcards, quizzes & games. Hosted.
Education & Learning Tools Text Summarization
312

Related MCP Servers

learners-mcp
Education & Learning Tools Knowledge & Memory
arashbehmand
A
license
Not graded
quality
D
maintenance
Turns any source material into a guided learning experience with learning maps, notes, four-phase study loop, spaced repetition flashcards, and grounded Q\&A.
Updated 4 months ago (2026-04-25 18:43 UTC)
1
MIT
University Course Catalog MCP
Education & Learning Tools Search
chandrabhanu18
F
license
Not graded
quality
C
maintenance
Provides intelligent access to a university course catalog with full-text search, prerequisite tracking, instructor lookups, and course comparison prompts.
Updated 2 months ago (2026-07-11 15:43 UTC)
Moodle Study MCP
Education & Learning Tools Search
franciscodngferreira
F
license
Not graded
quality
B
maintenance
Enables AI assistants to read your Moodle courses, list materials, quizzes, and search content to plan exam preparation through natural language.
Updated 2 months ago (2026-07-14 17:02 UTC)
1
learndeck
learn-deck
A
license
Not graded
quality
B
maintenance
Enables AI-assisted learning through structured courses with Socratic guidance, evaluating user answers against rubrics and managing learning progress locally.
Updated a month ago (2026-07-18 19:43 UTC)
Apache 2.0

View all related MCP servers

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/Star4future/aceachievers-mcp-server'

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