How do I use Study Tools MCP?

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., "@Study Tools MCP Create flashcards for chapter 3 of biology" 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.

Study Tools MCP

by francis-rf

Overview Schema Related Servers Score Discussions

Python

Hybrid

Study Tools MCP 📚

Python FastAPI MCP License CI/CD Live Demo

An AI-powered study assistant built with Model Context Protocol (MCP) that generates quizzes, flashcards, summaries, and concept explanations from your study materials.

🎯 Features

Smart Summarization — Generate concise summaries from study materials
Quiz Generation — Create customizable quizzes with difficulty levels
Concept Explanation — Get beginner/intermediate/advanced explanations
Flashcards — Auto-generate flashcard decks from documents
Comparison Tool — Compare and contrast multiple concepts
MCP Integration — Works directly with Claude Desktop
Web UI — Standalone chat interface with FastAPI backend

Related MCP server: Interleaved Learning MCP Server

🛠️ Tech Stack

Backend: FastAPI + Python 3.10
AI Framework: Model Context Protocol (MCP)
AI: OpenAI API
Document Parsing: PyPDF2, pdfplumber, python-docx
Frontend: Vanilla JavaScript, HTML, CSS
Cloud: AWS EC2 + S3 + Secrets Manager
CI/CD: GitHub Actions

🚀 Quick Start

Prerequisites

Python 3.10+
OpenAI API key

Installation

Clone the repository:

git clone https://github.com/francis-rf/study-Tools-mcp-server.git
cd study-Tools-mcp-server

Install dependencies:

pip install -r requirements.txt

Create .env file:

cp .env.example .env
# Edit .env and add your OPENAI_API_KEY

Add study materials:

Place PDF or Markdown files in data/notes/:

data/notes/
├── Machine Learning.pdf
└── Your Notes.md

Run the application:

python app.py

Open browser:

http://localhost:8080

🐳 Docker Deployment

Build and Run

docker build -t study-tools-mcp .
docker run -p 8080:8080 --env-file .env study-tools-mcp

☁️ AWS Deployment

Services Used

Service	Purpose
EC2 (t2.micro)	Hosts the Docker container
S3 (`study-tools-mcp-materials`)	Stores PDF study materials
Secrets Manager (`study-tools-mcp`)	Stores OpenAI API key
IAM Role	Grants EC2 access to S3 and Secrets Manager

Setup

Store OpenAI API key in AWS Secrets Manager under secret name study-tools-mcp
Upload PDFs to S3 bucket study-tools-mcp-materials
Launch EC2 instance with IAM role attached (study-tools-mcp-ec2-role)
SSH in, install Docker, clone repo and run container

⚙️ GitHub Actions CI/CD

Automated deployment is configured via .github/workflows/deploy.yml.

Workflow: Deploy to AWS EC2

On every push to main, the pipeline:

Checks out the code
SSHs into the EC2 instance
Pulls latest code from GitHub
Rebuilds the Docker image
Restarts the container with zero downtime

Required GitHub Secrets

Secret	Description
`EC2_HOST`	EC2 instance public IP
`EC2_USER`	`ubuntu`
`EC2_SSH_KEY`	Contents of the `.pem` key file

Workflow Status

Deploy to AWS EC2

📁 Project Structure

study-Tools-mcp-server/
├── app.py                          # FastAPI web application
├── src/study_tools_mcp/
│   ├── server.py                   # MCP server entry point
│   ├── config.py                   # Configuration (Secrets Manager + .env fallback)
│   ├── tools/                      # Quiz, flashcards, summarizer, explainer
│   ├── parsers/                    # PDF and Markdown parsers
│   └── utils/                      # Logger
├── static/                         # Frontend assets
├── templates/                      # HTML templates
├── data/notes/                     # Study materials (local only — S3 on AWS)
├── logs/                           # Application logs
├── .github/workflows/              # CI/CD
│   └── deploy.yml
├── Dockerfile
├── requirements.txt
└── pyproject.toml

📡 API Endpoints

Method	Endpoint	Description
GET	`/`	Web UI
GET	`/health`	Health check
GET	`/api/files`	List available study materials
POST	`/api/chat`	Chat with streaming
POST	`/api/chat/clear`	Clear conversation history

🔌 Claude Desktop Integration

Add to %APPDATA%\Claude\claude_desktop_config.json:

{
  "mcpServers": {
    "study-tools-mcp": {
      "command": "uv",
      "args": ["--directory", "C:\\path\\to\\study-tools-mcp", "run", "study-tools-mcp"]
    }
  }
}

Restart Claude Desktop — the tools will be available automatically.

📸 Screenshots

Application Interface Study Tool AI Interface with quiz generation

Claude Desktop Integration Study Tool AI Integration with Claude Desktop

📄 License

MIT License

Available Tools

6 tools

compare_two_conceptsC

Compare and contrast two related concepts

ParametersJSON Schema

Name	Required	Description	Default
`concept1`	Yes
`concept2`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided; description does not disclose behavioral traits beyond the obvious. Does not mention output format, scope, or 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence with no waste, but under-specifies important details. Appropriate length for a simple tool but could be more informative.

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 availability of an output schema, the description still lacks completeness. No mention of output structure or any contextual information beyond the minimal purpose.

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?

Schema description coverage is 0% and the description adds no meaning beyond parameter names. No clarification of what constitutes 'concept1' or 'concept2'.

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 the specific verb 'Compare and contrast' with the resource 'two related concepts', clearly distinguishing it from siblings like explain_topic or summarize_topic.

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 on when to use this tool versus alternatives like explain_topic or summarize_full_chapter. Missing when-not-to-use or context.

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

create_flashcardsC

Generate flashcards for a topic

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes
`num_cards`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only says 'Generate flashcards for a topic'. It does not disclose whether this creates new data, requires any permissions, or has side effects. The default number of cards (10) is not mentioned.

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, concise and front-loaded. However, it could include more useful information without significantly increasing length, such as mentioning the default number of cards or that output is structured.

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 low complexity and presence of an output schema, the description is too sparse. It omits behavioral traits, parameter details, and usage guidance, making it insufficient for reliable agent invocation despite the schema covering output structure.

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%, and the description does not elaborate on the parameters ('topic', 'num_cards') beyond their names. No details on format, constraints, or the meaning of 'num_cards' default are provided, leaving the agent to infer from parameter names alone.

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 'Generate flashcards for a topic' clearly states the verb (generate) and resource (flashcards) with a topic context, distinguishing it from sibling tools like create_quiz or summarize_topic. However, it lacks specificity on whether it generates from scratch or from existing content.

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 vs alternatives like create_quiz or compare_two_concepts. There is no mention of prerequisites, exclusions, or contexts where other tools would be more appropriate.

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

create_quizC

Generate a multiple-choice quiz on a specific topic

ParametersJSON Schema

Name	Required	Default
`topic`	Yes
`difficulty`	No	intermediate
`num_questions`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It does not mention output format, limitations, permissions, or side effects beyond 'generate a multiple-choice quiz'.

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 sentence, no wasted words, but could include more detail without being verbose. Front-loaded with action and resource.

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 simplicity of the tool and presence of output schema, the description is still insufficient. It does not explain parameter usage or provide enough context for an agent to invoke 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?

Schema description coverage is 0%, and the description adds no meaning to parameters. No mention of topic, difficulty, or num_questions, so it fails to compensate for missing schema descriptions.

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 'Generate a multiple-choice quiz on a specific topic' uses a specific verb ('generate') and resource ('multiple-choice quiz'), and clearly distinguishes from siblings like 'create_flashcards' and 'summarize_topic'.

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 on when to use this tool versus alternatives (e.g., compare_two_concepts, create_flashcards). The description only states what it does, not context for selection.

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

explain_topicB

Get an explanation of a concept at a specific difficulty level

ParametersJSON Schema

Name	Required	Description	Default
`term`	Yes
`level`	No		beginner

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full responsibility for behavioral traits. It only states the basic action without disclosing any side effects, dependencies, or how explanations are generated. There is no mention of authoritative sources or any limitations.

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 of 10 words, fully front-loaded with essential information. No extraneous content.

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 is simple, and an output schema exists to document return values. The description covers the core purpose but omits any hints about prerequisites, typical use cases, or limitations. Given the low complexity, it is marginally adequate.

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 partially compensates by mapping 'concept' to the 'term' parameter and 'specific difficulty level' to 'level'. However, it does not elaborate on the meaning of the levels or any constraints on the term. The baseline for 0% coverage is low, but the description adds marginal value 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 action (get an explanation), the resource (a concept), and the context (at a specific difficulty level). It distinguishes itself from sibling tools like 'compare_two_concepts' and 'summarize_topic' by focusing on explanation rather than comparison or summary.

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 does not provide guidance on when to use this tool versus alternatives. It lacks explicit when-to-use, when-not-to-use, or references to sibling tools.

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

summarize_full_chapterC

Create a comprehensive summary of an entire chapter

ParametersJSON Schema

Name	Required	Description	Default
`chapter_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of disclosure. It only says 'create a comprehensive summary' but does not reveal whether it modifies data, requires authentication, or has any side effects. The behavior beyond output is opaque.

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 short sentence without unnecessary words. However, it is too concise to be fully informative, sacrificing completeness for brevity.

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 simplicity (1 param, no annotations) and presence of an output schema, the description could be more complete. It fails to clarify output nature or constraints, relying on the name alone.

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 single required parameter 'chapter_name' has zero description in the schema, and the tool description adds no extra meaning. The agent cannot infer what format or valid values are expected.

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 ('create a comprehensive summary') and the resource ('an entire chapter'). It is specific enough to distinguish from sibling tools like 'summarize_topic' which implies a narrower scope, though not explicitly differentiated.

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 like 'summarize_topic' or 'explain_topic'. No context about prerequisites or exclusions is given.

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

summarize_topicC

Create a summary of a specific topic from study materials

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes
`length`	No		brief

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

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 states the basic action without disclosing whether it is read-only, destructive, or requires authentication. No mention of side effects or limitations.

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 sentence, no redundant information. Efficient but may be too brief for a full understanding.

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 presence of an output schema, return values are not required. However, the description lacks guidance on choosing between siblings and fails to elaborate on parameter usage, leaving the agent underinformed.

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?

Schema description coverage is 0%, and the tool description provides no details about the parameters. The enum values for 'length' are not explained.

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?

Description clearly states verb (create summary) and resource (specific topic from study materials). However, it does not differentiate from sibling tools like explain_topic or summarize_full_chapter.

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 on when to use this tool versus alternatives such as explain_topic or summarize_full_chapter. Missing context on prerequisites or typical use cases.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jul 13, 2026
- First observedcompare_two_concepts
- First observedcreate_flashcards
- First observedcreate_quiz
- First observedexplain_topic
- First observedsummarize_full_chapter
- First observedsummarize_topic

Install Server

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

TDQS

B3.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: compare concepts, generate flashcards, create quizzes, explain topics, summarize chapters, and summarize topics. Even the two summarization tools are differentiated by scope (chapter vs. topic). Agents can easily select the appropriate tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., compare_two_concepts, create_flashcards). The naming convention is uniform and predictable across all tools.

Tool Count5/5

Six tools is an appropriate number for a study aid server, covering core actions like explanation, comparison, summary generation, flashcard creation, and quiz creation. The count is neither too thin nor too heavy.

Completeness4/5

The tool set covers essential study material generation tasks: explaining, comparing, summarizing, creating flashcards, and creating quizzes. A minor gap is the lack of tools to manage or edit generated items, but this is acceptable for a generation-focused server.

Maintenance

ActivityInactive

ResponsivenessNo issues

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.

Related MCP Connectors

Fiveable for AP Students A
io.github.thinkfiveable
AP study content, practice, FRQ feedback, progress, plans, and student tools for AI apps.
371
Quizlar — voice-powered AI flashcards with spaced repetitionOAuth
io.github.quizlar
Voice-led, FSRS-scheduled flashcards from YouTube, PDFs, web, or text. Auto-graded quizzes.
Education & Learning Tools Speech Processing Knowledge & Memory
2
llamanotesOAuth
ai.llamanotes
Lucky AI study buddy over your own LlamaNotes courses: chat, progress, and AI course generation.
Education & Learning Tools AI & Machine Learning
2
Acornonaut MCP ServerOAuth
io.github.zerolve-io
AI-powered YouTube to flashcards with spaced repetition and Anki export
Education & Learning Tools AI & Machine Learning
2

Related MCP Servers

Rember MCPofficial
Education & Learning Tools Autonomous Agents Note Taking
rember
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that allows Claude to create flashcards for Rember, helping users study and remember information through spaced repetition reviews.
Updated a year ago (2025-03-28 09:29 UTC)
36
63
MIT
Interleaved Learning MCP
Education & Learning Tools Note Taking Knowledge & Memory
sheikhcoders
F
license
Not graded
quality
D
maintenance
Implements cognitive science-backed interleaved learning techniques to create study plans, generate mixed-topic quizzes, manage flashcard decks, and track learning progress for optimal knowledge retention.
Updated 9 months ago (2025-12-05 09:00 UTC)
1
-
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)
2
MIT
education-mcp
Education & Learning Tools Research & Data
mcp-tools-lab
A
license
Not graded
quality
C
maintenance
Generates educational content like quizzes, lesson plans, flashcards, and grading rubrics from any topic via the Model Context Protocol.
Updated 3 months ago (2026-06-05 21:46 UTC)
17
1
MIT

Appeared in Searches

A server for helping me learn

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/francis-rf/study-Tools-mcp-server'

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

Study Tools MCP 📚

🎯 Features

🛠️ Tech Stack

🚀 Quick Start

Prerequisites

Installation

🐳 Docker Deployment

Build and Run

☁️ AWS Deployment

Services Used

Setup

⚙️ GitHub Actions CI/CD

Workflow: Deploy to AWS EC2

Required GitHub Secrets

Workflow Status

📁 Project Structure

📡 API Endpoints

🔌 Claude Desktop Integration

📸 Screenshots

📄 License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Rember MCPofficial

Appeared in Searches

Latest Blog Posts

MCP directory API