Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Materio MCP Server what subjects are in semester 4?"
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.
An MCP (Model Context Protocol) server that enables AI assistants like Claude, ChatGPT, and others to directly search and read Materio's educational PDF resources ā no manual file uploads needed.
When a user asks @materio about a topic, the AI can use this server to:
š Browse all available semesters, subjects, and resources
š Search for specific topics, chapters, question banks, and more
š Read full PDF content and answer questions using the material's own terminology
š Get URLs to share or reference specific PDFs
User ā AI Assistant ā MCP Server ā Materio CDN ā PDFs
ā
Resource Library
(resource.lib.json)The server fetches Materio's resource library from cdn-materioa.vercel.app
It indexes all semesters, subjects, categories, and topics
When the AI needs a PDF, it fetches it from the CDN and extracts the text
The AI uses the extracted text to answer questions with proper terminology
Related MCP server: PDF Reader MCP Server
Tool | Purpose |
| Browse all available resources (filterable by semester) |
| Search across all resources by keyword |
| Fetch and read the full text content of a PDF |
| Get the CDN download URL for a PDF |
| Get a complete overview of a subject's resources |
cd materio-mcp-server
npx vercelOr link to your Vercel account and deploy:
npx vercel --prodEndpoint: https://your-project.vercel.app/mcp (POST for MCP, GET for health check)
Transport: Streamable HTTP (stateless JSON-RPC)
Function: api/mcp.js ā 60s timeout, 1GB memory
Once deployed, configure your AI client with the remote URL:
Claude Desktop (remote MCP):
{
"mcpServers": {
"materio": {
"url": "https://your-project.vercel.app/mcp"
}
}
}ChatGPT (Custom GPT / Actions):
Use the endpoint URL https://your-project.vercel.app/mcp as the MCP server URL in your GPT configuration.
Health Check:
curl https://your-project.vercel.app/mcpcd materio-mcp-server
npm installAdd to %APPDATA%\Claude\claude_desktop_config.json (Windows) or ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"materio": {
"command": "node",
"args": ["D:\\v4\\materio\\materio-mcp-server\\index.js"]
}
}
}ā ļø Update the path to match your system.
Then restart Claude Desktop.
Once configured, you can ask your AI assistant things like:
"What subjects are available in semester 4?"
"Find me notes on Deadlocks in Operating System"
"Read the Laplace Transform chapter from Maths-2 and explain the key concepts for exams"
"Get me the question bank for DBMS"
"What topics are covered in Object Oriented Programming with Java?"
"Read the Inheritance chapter and create a study guide covering all exam-relevant points"
materio-mcp-server/
āāā server.js # Shared core ā all tools, utilities, server factory
āāā index.js # Local entry point (stdio transport)
āāā api/
ā āāā mcp.js # Vercel entry point (HTTP transport)
āāā vercel.json # Vercel deployment config
āāā package.json # Dependencies and metadata
āāā README.md # This fileRuntime: Node.js ā„ 18
Transport: stdio (local) / Streamable HTTP (Vercel)
CDN: https://cdn-materioa.vercel.app
Resource Library: Fetched from CDN and cached for 5 minutes
PDF Parsing: Uses pdf-parse to extract text from PDFs
Character Limit: PDF text output is capped at 80,000 characters
Vercel Function: 60s timeout, 1GB memory (for large PDF parsing)
MIT ā Ā© 2024-2026, Materio by JTC.
Fetch and read the full text content of a Materio PDF.
Downloads the PDF from the Materio CDN and extracts its text content so you can read and reason over it. Use this after searching/browsing to retrieve the actual study material.
You can provide EITHER a direct PDF URL (from a search result) OR the semester + subject + topic combination.
IMPORTANT: This tool is designed to help users study. When answering questions based on PDF content:
Use the PDF's own terminology and definitions
Cover all relevant points as expected in university exams
Structure answers clearly with proper headings
Include examples from the material when available
Args:
url (string, optional): Direct CDN URL of the PDF. If provided, semester/subject/topic are ignored.
semester (string, optional): Semester number (e.g. "1", "2", "3", "4", "5", "6"). Required if url is not provided.
subject (string, optional): Subject name exactly as listed in the resource library. Required if url is not provided.
topic (string, optional): Topic name exactly as listed in the resource library. Required if url is not provided.
Returns: The full extracted text content of the PDF, which may be long. The AI can then use this to answer questions.
Examples:
Fetch by URL: { url: "https://cdn-materioa.vercel.app/pdfs/4/Operating%20System/Deadlocks.pdf" }
Fetch by path: { semester: "4", subject: "Operating System", topic: "Deadlocks" }
Fetch by path: { semester: "3", subject: "Object Oriented Programming with Java", topic: "Inheritance" }
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Direct CDN URL of the PDF. Takes priority over semester/subject/topic. | |
| topic | No | Topic name exactly as listed in the resource library. | |
| subject | No | Subject name exactly as listed in the resource library. | |
| semester | No | Semester number, e.g. '1', '2', '3', '4', '5', '6'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds value by noting the PDF is downloaded from the CDN and text extracted, and that the returned text may be long. No contradictions.
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 well-structured with clear sections for purpose, usage, args, returns, and examples. The 'IMPORTANT' section adds a bit of extra instruction on how to use the content, which might be unnecessary but doesn't harm clarity.
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 description covers the main workflow: how to specify inputs, what is returned (full text, potentially long), and includes examples. It lacks explicit error handling or confirmation of success, but given the simplicity and annotations, it is sufficiently 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 coverage is 100%, so baseline is 3. The description adds value by clarifying conditional requirements: 'Required if url is not provided' for semester, subject, topic. It also reinforces that url takes priority, which is already in schema but emphasized.
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 clearly states the tool's purpose: 'Fetch and read the full text content of a Materio PDF.' It specifies the verb (fetch/read), resource (PDF), and distinguishes from siblings like search and get_resource by noting it retrieves actual study material after searching.
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 explicitly says 'Use this after searching/browsing to retrieve the actual study material,' providing context. It also explains the two input methods (direct URL or semester+subject+topic) and that URL takes priority. It doesn't explicitly list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across all Materio educational PDFs by keyword.
Searches through semester numbers, subject names, category types (Chapters, Assignments, Question Banks, etc.), and topic names to find matching resources.
Args:
query (string): Search keywords to match, e.g. "operating system deadlocks", "maths laplace", "java inheritance", "question bank", "semester 4". Multiple words narrow the search.
limit (number, optional): Maximum number of results to return (default: 20, max: 50).
Returns: A list of matching resources with semester, subject, category, topic name, and the CDN URL for each PDF.
Examples:
"Find notes on deadlocks" ā params: { query: "deadlocks" }
"Question banks for semester 4" ā params: { query: "question bank semester 4" }
"Java chapters" ā params: { query: "java chapters" }
"DBMS SQL" ā params: { query: "dbms sql" }
"Maths Laplace Transform" ā params: { query: "laplace transform" }
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 20) | |
| query | Yes | Search keywords to match against subjects, topics, and categories |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false. The description adds that it searches PDFs, which is consistent but does not reveal additional behavioral traits beyond the annotations. No contradiction.
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 well-structured with a clear intro, Args/Returns sections, and examples. It is somewhat lengthy but every sentence adds value, and the key purpose is front-loaded. Minor redundancy in the Args section (repeats schema).
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 search tool with no output schema, the description explicitly states the return format (list with semester, subject, category, topic name, CDN URL). Examples cover various use cases. No missing information for an agent to invoke the tool correctly.
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%, so baseline is 3. The description adds value by explaining the scope of search (fields), providing usage examples, and clarifying that multiple words narrow results. This goes beyond the schema's basic descriptions.
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 clearly states it searches across all Materio educational PDFs by keyword, specifying what it searches (semester numbers, subject names, categories, topics). This distinguishes it from siblings like 'list_resources' (listing without search) and 'fetch_pdf' (direct file retrieval).
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 implies usage via examples but does not explicitly state when to use or avoid this tool compared to siblings. No alternatives are mentioned, and it lacks exclusions or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available educational resources in the Materio library.
Returns a structured overview of all semesters, subjects, resource categories, and topics available. Use this to discover what PDFs are available before fetching a specific one.
Optionally filter by semester number to narrow results.
Args:
semester (string, optional): Filter by semester number (e.g. "1", "2", "3", "4", "5", "6"). Omit to list all semesters.
Returns: A formatted markdown listing of all available resources organized by semester > subject > category > topics.
Examples:
"What subjects are in semester 3?" ā params: { semester: "3" }
"Show me all resources" ā params: {}
"What's available for semester 5?" ā params: { semester: "5" }
| Name | Required | Description | Default |
|---|---|---|---|
| semester | No | Filter by semester number, e.g. '1', '2', '3'. Omit to list all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by specifying the return format (markdown listing organized by semester > subject > category > topics). No additional behavioral traits are disclosed beyond what annotations cover.
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?
Description is well-structured with clear sections for Args, Returns, and Examples. It is front-loaded with the purpose. A bit lengthy with examples, but remains focused and useful.
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?
Given the tool's simplicity (one optional parameter, no output schema) and the presence of annotations covering safety, the description fully covers what the tool does, how to use it, and what the output looks like. Examples further ensure completeness.
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 description provides examples of usage for the 'semester' parameter (e.g., '3'), which adds practical guidance but does not introduce new semantics beyond the schema's description. Baseline 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?
Description clearly states 'List all available educational resources' and distinguishes from siblings like 'get_resource' and 'fetch_pdf' by noting it's for discovery before fetching. The verb is specific and the resource scope is defined.
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?
Provides explicit usage context: 'Use this to discover what PDFs are available before fetching a specific one' and includes examples like filtering by semester. However, it does not explicitly state when not to use or mention alternatives like 'search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PRIORITY 1 ā Semantic search across the pre-indexed Materio document library.
Uses Google Gemini (gemini-embedding-2-preview) to match your question against extracted textbook chunks stored in a vector database. Always call this first before attempting fetch_pdf. Returns the most relevant text passages with similarity scores and source page references.
Args:
query (string): The specific question, concept, or topic to search for. Be precise ā e.g. "deadlock detection algorithm" not just "deadlock".
semester (string, optional): Filter results to a specific semester (e.g. "4").
subject (string, optional): Filter results to a specific subject (e.g. "Operating System").
limit (number, optional): Number of results to return (default: 5, max: 15).
Returns: Ranked text chunks with similarity %, subject, topic, page range, and a direct PDF link for further reading.
Examples:
"Explain banker's algorithm" ā params: { query: "banker algorithm deadlock avoidance" }
"OS deadlocks semester 4" ā params: { query: "deadlock", semester: "4", subject: "Operating System" }
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (default: 5). | |
| query | Yes | The specific question, topic, or concept to semantically search for. | |
| subject | No | Optional: filter to a specific subject name, e.g. 'Operating System'. | |
| semester | No | Optional: filter to a specific semester number, e.g. '4'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds rich behavioral context beyond annotations: it uses Google Gemini for embedding, returns ranked text chunks with similarity scores, source page references, and direct PDF links. It explains it's semantic search against a vector database. No contradiction with annotations (readOnlyHint=true).
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 appropriately sized, front-loading the priority and purpose. It is structured with clear sections: priority statement, technology, usage guidance, args description, returns, and examples. Every sentence adds value, and no information is redundant.
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?
Given the tool has 4 parameters (1 required) and no output schema, the description fully explains what the tool returns: ranked text chunks with similarity %, subject, topic, page range, and PDF link. It also provides usage context and examples, making it complete for an AI agent to invoke correctly.
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% with descriptions for all parameters. The description adds extra value with usage tips like 'Be precise' for query and provides default and max values for limit. It also gives concrete examples that illustrate parameter combinations. This goes beyond the schema's baseline but doesn't fully compensate for the schema's already adequate coverage.
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 title 'Semantic Vector Search' and description clearly state the tool performs semantic search over a pre-indexed document library. It distinguishes itself from siblings like fetch_pdf by explicitly instructing to call this first. The verb 'search' and resource 'document library' are specific.
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 explicitly says 'Always call this first before attempting fetch_pdf', providing clear guidance on when to use this tool vs. its sibling. Examples show different usage scenarios, and the description implies this is the primary search tool, not for listing resources or getting single items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a complete overview of all available resources for a specific subject.
Shows all categories (Chapters, Assignments, Question Banks, Previous Year Papers, etc.) and their topics for the given subject. Useful for understanding the full scope of available material before diving into specific topics.
Args:
semester (string): Semester number (e.g. "1", "2", "3", "4", "5", "6").
subject (string): Subject name exactly as listed in the resource library.
Returns: A detailed listing of all resource categories and topics for the subject, with PDF URLs for each.
Examples:
{ semester: "4", subject: "Operating System" }
{ semester: "2", subject: "Maths-2" }
{ semester: "3", subject: "Database Management Systems" }
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | Subject name exactly as listed in the resource library. | |
| semester | Yes | Semester number, e.g. '1', '2', '3', '4', '5', '6'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that it returns PDF URLs and is a read operation, but does not disclose additional behavioral traits beyond what annotations cover.
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 concise: a broad purpose sentence, a detail sentence, structured Args/Returns sections, and three examples. No superfluous information; front-loaded with the key verb 'overview'.
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 overview tool with 2 required parameters and no output schema, the description covers what it returns (categories, topics, PDF URLs) and provides examples. Could mention potential size of results, but overall sufficient.
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% with clear descriptions. The description repeats parameter details and adds examples, which provide extra context but do not significantly extend beyond the schema.
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 clearly states the tool provides a complete overview of all resources for a subject, listing categories and topics. The verb 'overview' and mention of specific resource types distinguish it from sibling tools like search or get_resource.
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 says it's 'useful for understanding the full scope before diving into specific topics,' which implies when to use. It does not explicitly exclude cases or name alternatives, but the context with siblings provides sufficient guidance.
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. Dates show when Glama detected each change.
v2.1.1fetch_pdfget_resourcelist_resourcessearchshare_linksubject_overviewTools are mostly distinct, but get_resource and search could be confused as both involve searching, though one is metadata keyword search and the other is semantic content search. list_resources and subject_overview also overlap slightly.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_resources, fetch_pdf). Only 'search' is a single verb, but it's a common exception and still fits the pattern.
6 tools cover the core functionality of browsing, searching, retrieving, and sharing PDF resources without being too few or too many. The scope is well-scoped for an educational document library.
The tool set provides a complete workflow: discover resources (list_resources, subject_overview), search (search, get_resource), retrieve full content (fetch_pdf), and share (share_link). No obvious gaps for a read-only library.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Search and query nTop's knowledge base and engineering guides from AI applications.
Generate and read PDFs for AI agents: a generate_pdf and a read_pdf tool, priced per document.
Search your knowledge bases from any AI assistant using hybrid RAG.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Materioa/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
