What can you do with this server?

This server provides structured access to FIPI exam task banks (EGE and OGE) via MCP tools. * List all available subjects for EGE (16) and OGE (14) * Browse codifier topic trees (KES themes) for a subject * List tasks with filters: subject, exam, page, page size, themes, answer types, task ID * Full-text search across task conditions (client-side) * Fetch a specific task by short qid (e.g., 40B442) * Check short/numeric answers against FIPI's solve.php, returning correct/wrong/not_found * Retrieve task metadata, conditions, and MathML converted to LaTeX

How do I use fipi-mcp?

1. Click on "Deploy 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., "@fipi-mcp Дай 5 задач по математике с кратким ответом" 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.

fipi-mcp

by MasterGiGiK

Overview Schema Source Related Servers Discussions Admin

Python

Remote

fipi-mcp

smoke python license MCP

MCP-сервер для открытого банка заданий ФИПИ (ЕГЭ и ОГЭ) — https://ege.fipi.ru/bank/ и https://oge.fipi.ru/bank/.

Даёт LLM/агенту структурированный доступ к заданиям 16 предметов ЕГЭ и 14 предметов ОГЭ: список с фильтрами по темам кодификатора, условие с MathML → LaTeX, метаданные (КЭС, тип ответа) и проверку ответа.

Что можно попросить у модели

«Дай 5 задач по профильной математике по теме 2.4 (показательные и логарифмические уравнения).»
«Покажи темы кодификатора по физике из fipi-bank.»
«Найди в fipi-bank задачи со словом треугольник по профильной математике.»
«Дай 3 задачи ОГЭ по физике по разделу 1 (Механика).»
«Найди задание 40B442 по профильной математике и объясни решение.»
«Проверь мой ответ 29 на задание с guid 006420F9E9A798DD4FF57BB34671C6AA по профильной математике.»

Related MCP server: СДАМ ГИА MCP Server

Инструменты (MCP tools)

Tool	Что делает
`list_subjects(exam='ege')`	Все предметы. `'ege'` — 16 предметов ЕГЭ, `'oge'` — 14 предметов ОГЭ.
`list_kes_topics(subject, exam='ege')`	Дерево кодификатора: разделы 1..N + подтемы. Код темы (`2.4`) идёт в `themes` ниже.
`list_tasks(subject, exam='ege', page=0, pagesize=10, themes=[], answer_types=[], task_id=?)`	Задачи с фильтрами. `themes=['2.4']` — тема КЭС; `answer_types=['short'\|'full'\|'select_one']` — тип ответа.
`search_tasks(subject, query, exam='ege', themes=[], max_pages=10)`	Клиентский полнотекстовый поиск в тексте условия. Серверного у ФИПИ нет. Дорого — сужай через `themes`.
`get_task(subject, qid, exam='ege')`	Ищет конкретное задание по короткому qid (`40B442`), перебирая страницы.
`check_answer(subject, guid, answer, exam='ege')`	POST на `solve.php`. Клиент сам прогревает сессию. Возвращает `correct` / `wrong` / `not_found`.

subject принимает три формата: ключ (physics), русское название (Физика) или полный proj_guid. exam — 'ege' (по умолчанию) или 'oge'.

С какими клиентами / нейронками работает

MCP — открытый протокол, к нашему серверу подключается любой MCP-совместимый клиент. Модель под капотом клиент выбирает сам (Claude, GPT-4/5, Gemini, локальная Llama через Ollama и т. д. — MCP-инструменты подаются им как обычные function calls).

Работает из коробки: Claude Desktop, Claude Code, Cursor, Windsurf, Zed, Continue.dev, Cline / Roo Code, LibreChat, OpenWebUI, Goose. Для ChatGPT и Gemini напрямую нельзя — нужен bridge (напр. mcp-openai-bridge).

⚠️ Сервер должен запускаться на машине, которая физически видит ege.fipi.ru / oge.fipi.ru. Из США/Европы сайт часто недоступен.

Установка

Нужен Python 3.10+. Три шага — склонировать, создать venv, поставить.

git clone https://github.com/MasterGiGiK/fipi-mcp.git
cd fipi-mcp
python3 -m venv .venv
.venv/bin/pip install -e .

Запомни абсолютный путь до venv-питона — он нужен для конфигов ниже:

echo "$(pwd)/.venv/bin/python"

(На Windows это .venv\Scripts\python.exe.)

Подключение

Ниже подставь свой путь вместо <PYTHON> — то, что вывела команда выше.

Claude Desktop

Settings → Developer → Edit Config (это откроет claude_desktop_config.json). Добавь блок mcpServers на верхний уровень:

{
  "mcpServers": {
    "fipi-bank": {
      "command": "<PYTHON>",
      "args": ["-m", "fipi_mcp"]
    }
  }
}

Сохрани, полностью закрой Claude (Cmd+Q, не крестик) и открой заново. У поля ввода появится иконка инструментов — там будет fipi-bank.

Claude Code

claude mcp add fipi-bank --scope user -- <PYTHON> -m fipi_mcp

Проверка: claude mcp list или /mcp внутри чата.

Cursor

Settings → MCP → Add new MCP server. Формат такой же, как у Claude Desktop:

{
  "mcpServers": {
    "fipi-bank": {
      "command": "<PYTHON>",
      "args": ["-m", "fipi_mcp"]
    }
  }
}

Файл лежит в ~/.cursor/mcp.json (глобально) или .cursor/mcp.json в корне проекта (локально).

Windsurf / Zed / Continue.dev / другие

Формат конфигурации у всех одинаковый (command + args), меняется только путь к файлу настроек. Загляни в документацию своего клиента по разделу «MCP» — вставь тот же блок mcpServers.

Проверка, что всё работает

Без MCP, локально:

.venv/bin/python -m examples.smoke_test

Должен напечатать 2 задачи по профильной математике и [OK] по всем пунктам, включая проверку ответа 29 через check_answer. Если работает — и MCP-подключение заведётся.

Внутри клиента после подключения задай простой промпт: «Через fipi-bank покажи 3 задания по профильной математике». Модель дёрнет list_tasks и вернёт задачи с формулами в LaTeX.

Как это устроено

fipi_mcp/client.py — httpx-клиент с verify=False (у ege.fipi.ru свой CA), декодированием cp1251, сессионными куками и прогревом PHPSESSID перед solve.php.
fipi_mcp/parser.py — BeautifulSoup + lxml. Ищет div.qblock (условие), div#i<qid> (метаданные), ul.dropdown-menu (дерево КЭС).
fipi_mcp/mathml.py — мини-компилятор MathML → LaTeX для читаемости формул.
fipi_mcp/subjects.py — реестр предметов ЕГЭ и ОГЭ с их proj_guid.
fipi_mcp/server.py — MCP-обвязка тулов на официальном Python SDK.

Ограничения

Задания копирайт ФИПИ. Массовая выкачка не приветствуется — используй для подготовки к экзамену или разработки.
Нет пагинации-cursor: серверу передаётся page и pagesize. get_task делает линейный перебор — дорого при глубоком поиске.
MathML → LaTeX покрывает основные примитивы, а не 100% спецификации.
search_tasks ищет только в тексте условия, не внутри формул MathML.
check_answer работает только для заданий с автоматической проверкой (краткий/числовой ответ). Развёрнутые ответы ФИПИ не проверяет.

Лицензия

MIT — см. LICENSE.

Available Tools

4 tools

check_answerA

Проверить ответ через solve.php ФИПИ. guid — полный 32-hex ID задания (не короткий qid). Клиент сам прогревает сессию перед POST-ом.

Коды ФИПИ (расшифрованы экспериментально): 3=correct, 2=wrong, 0=not_found.

ParametersJSON Schema

Name	Required	Description	Default
`guid`	Yes
`answer`	Yes
`subject`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does substantial work: it reveals the HTTP POST mechanism, the session-warming prerequisite, and experimentally decoded FIPI response codes (3=correct, 2=wrong, 0=not_found). It does not discuss side effects or authentication, but the most important runtime behaviors are disclosed.

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 compact and front-loaded with the core purpose. Every sentence carries useful information: the endpoint, the GUID requirement, the session prerequisite, and the response-code mapping. There is no filler or repetition.

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 that an output schema exists and sibling list_subjects likely provides subject values, the description covers the critical operational needs: endpoint, GUID format, session warming, and response semantics. A small gap remains in documenting the `subject` and `answer` parameters, but the tool is otherwise complete enough for correct invocation.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It meaningfully clarifies the non-obvious `guid` parameter (full 32-hex, not short qid), which is the main ambiguity. However, `subject` and `answer` are left entirely to their self-explanatory names and external context such as list_subjects, so not all parameters are enriched.

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 states a specific action ('Проверить ответ через solve.php ФИПИ') with a clear resource and mechanism. It also adds a critical scoping detail (full 32-hex GUID, not short qid) that distinguishes this tool from simpler lookups. The purpose is immediately understandable and distinct from the sibling tools.

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 gives clear operational context: it checks an answer via solve.php, requires the full 32-hex GUID, and requires the client to warm the session before POST. It does not explicitly name alternatives or when-not-to-use cases, but the context is strong enough that an agent can infer when this tool applies relative to the list/get siblings.

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

get_taskA

Найти задание по короткому 6-hex qid, перебирая страницы предмета.

Дороже, чем list_tasks — используй, если знаешь qid, но нет guid. max_pages — верхняя граница перебора.

ParametersJSON Schema

Name	Required	Description	Default
`qid`	Yes
`subject`	Yes
`max_pages`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries the burden and discloses that the lookup works by iterating subject pages, has a cost premium, and is bounded by max_pages. It does not detail auth or error behavior, but the output schema covers the return contract.

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 short sentences, front-loaded with the core lookup behavior, followed by cost guidance and parameter clarification. No filler.

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 read-style lookup with an output schema and a small parameter set, the description provides essential routing, qid format, and iteration bound. Remaining details are covered by schema defaults and the output schema.

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

Parameters4/5

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

Schema coverage is 0%, but the description compensates for qid by specifying the 6-hex format and for max_pages by calling it the upper bound of iteration. Subject is only implied through 'subject pages', but its meaning is inferable from the parameter name.

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 states a specific operation: finding a task by a short 6-hex qid through iterating subject pages. It also contrasts with list_tasks by qid-vs-guid, making its role distinct among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use this tool when you know the qid but lack guid, and warns that it is more expensive than list_tasks. This provides a clear routing rule and names the alternative.

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

list_subjectsA

Список предметов ЕГЭ, доступных в открытом банке ФИПИ.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description is the only behavioral signal. It indicates the tool returns a list and scopes it to subjects available in the FIPI open bank, which covers the core read-only nature. It does not mention output format or variations, but the output schema covers return structure.

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, front-loaded sentence with no filler. Every word contributes the essential meaning: what is listed and from which source.

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?

For a zero-parameter list tool with an output schema, the description is nearly complete: it names the resource and the source. It could add a hint that subject selection is a prerequisite for list_tasks, but that is not essential.

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

Parameters4/5

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

The tool has zero parameters, so the schema already fully describes the input contract. The description adds no parameter details, but none are needed; baseline 4 is appropriate.

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 a specific action and resource: it lists ЕГЭ subjects from the FIPI open bank. This distinguishes it from sibling tools like list_tasks and get_task, which operate on tasks rather than subjects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context is implied: use this tool when a caller needs the available subject list, likely before selecting a subject to fetch tasks. However, there is no explicit statement of when to use this tool versus list_tasks or any exclusions.

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

list_tasksA

Список заданий по предмету.

subject — ключ ('physics'), русское название или proj-GUID. page — номер страницы с нуля. pagesize — размер страницы (обычно 10 или 20).

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`subject`	Yes
`pagesize`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/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 usefully reveals pagination behavior (zero-based page, pagesize typically 10/20) and subject identifier forms, but does not state read-only safety, sorting, error behavior, or how results are ordered.

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 one purpose line plus three terse parameter lines. Every sentence carries information and there is no filler.

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

Completeness3/5

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

For a simple paginated list with an output schema, the description covers the core calling contract. It misses the relationship to list_subjects (where valid subject identifiers come from) and any behavior around empty results or invalid subjects, so it is minimally viable rather than complete.

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 description coverage is 0%, and the description fully compensates: it explains that subject accepts a key, Russian name, or proj-GUID, that page is zero-based, and that pagesize is usually 10 or 20. This adds meaning well beyond the bare schema types and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear resource and scope: 'Список заданий по предмету' (list of tasks by subject), which is distinct from get_task (single task) and list_subjects (subjects). However, it does not explicitly contrast with sibling tools, so it stops short of full differentiation.

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?

There is no guidance on when to choose list_tasks over list_subjects, get_task, or check_answer. The only context is the subject-filtered listing itself; no alternatives or exclusions are mentioned.

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.

4 tool updatesv0.1.0Sep 21, 2026
- First observedcheck_answer
- First observedget_task
- First observedlist_subjects
- First observedlist_tasks

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-09-21 15:45 across 4 tools

Disambiguation5/5

Each tool has a distinct purpose: listing subjects, listing tasks per subject, retrieving a specific task by qid, and checking an answer. No overlapping functionality; an agent can easily select the right tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: list_subjects, list_tasks, get_task, check_answer. The pattern is predictable and clear.

Tool Count5/5

With only 4 tools, the server is well-scoped for its purpose: browsing subjects, browsing tasks, finding a task by qid, and checking answers. Each tool earns its place.

Completeness5/5

The surface covers the essential workflows: discover subjects, list tasks, locate a task by qid, and validate answers. No obvious gaps for the domain of accessing FIPI exam tasks.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Chertov & Vorobyov physics problem solutions A
ua.org.chertov
Read-only search and lookup over the Chertov & Vorobyov physics problem solutions (chertov.org.ua).
Education & Learning Tools Search
51
Codeforces MCP Server B
io.github.ketherworks
Search Codeforces problems and inspect public problem metadata through the official Codeforces API.
Developer Tools Education & Learning Tools
2
срезAI — Search API for AI agents A
ru.srezai
Web search, page reading and structured extraction for AI agents, with strong RU coverage
Browser Automation Web Scraping Search
101
uNotesOAuth
net.unotes
Search university course materials, your flashcards, quizzes, streak and quota. All tools read-only.
Education & Learning Tools Search Note Taking
1

Related MCP Servers

MCP Server Learning
Education & Learning Tools Note Taking Developer Tools
xstraven
F
license
A
quality
D
maintenance
Enables educational and learning tasks including flashcard generation with Anki integration, Zotero library management, Obsidian vault interaction, and mathematical expression verification with LaTeX support.
Updated 6 months ago (2026-03-18 22:14 UTC)
8
-
СДАМ ГИА MCP Server
Education & Learning Tools Search Research & Data
art22017
A
license
A
quality
D
maintenance
Enables LLMs to search and retrieve exam problems, solutions, and answers from the СДАМ ГИА educational platform across multiple subjects. It supports fuzzy text matching, catalog browsing, and structured data retrieval to assist with academic study and test preparation.
Updated 7 months ago (2026-02-16 22:26 UTC)
7
7 npm
5
MIT
SearchCAIE MCP Server
Education & Learning Tools Search Research & Data
Pixel2075
F
license
A
quality
D
maintenance
Enables searching and retrieving CAIE past-paper questions with filters for subjects, years, and specific topics. It provides LLM-friendly responses including concise text previews and structured JSON data for single or multi-topic queries.
Updated 6 months ago (2026-03-10 03:19 UTC)
7
1
-
Khan Academy MCP Server
Education & Learning Tools Search Content Management Systems
aicoder2009
A
license
A
quality
C
maintenance
Enables AI assistants to search, browse, and read Khan Academy's educational content, including courses, articles, and video transcripts. It provides tools to navigate the subject hierarchy and retrieve detailed metadata without requiring an API key.
Updated 2 months ago (2026-07-09 04:11 UTC)
6
10 npm
3
MIT