Skip to main content
Glama
art22017

СДАМ ГИА MCP Server

by art22017
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

СДАМ ГИА MCP Server

MCP (Model Context Protocol) server for interacting with the СДАМ ГИА educational platform. This server enables LLMs to search and retrieve exam problems, solutions, and answers across multiple subjects.

Features

🔍 Smart Search

  • Text Search: Search problems by keywords

  • Fuzzy Text Matching: Find problems by condition text with approximate matching

  • Catalog Browsing: Explore problems by topics and categories

📚 Problem Retrieval

  • Single Problem: Get complete problem details including condition, solution, and answer

  • Batch Fetch: Retrieve multiple problems efficiently in one request

  • Analog Problems: Discover similar problems automatically

📊 Structured Data

  • Multiple Formats: Output in JSON or Markdown

  • Rich Metadata: Access images, topics, and problem relationships

  • Type Safety: Full TypeScript support with Zod validation

Related MCP server: Yandex Search MCP Server

Supported Subjects

  • math - Mathematics (профильная)

  • mathb - Mathematics (базовая)

  • rus - Russian Language

  • phys - Physics

  • chem - Chemistry

  • bio - Biology

  • geo - Geography

  • hist - History

  • soc - Social Studies

  • inf - Informatics

  • en - English

  • de - German

  • fr - French

  • sp - Spanish

  • lit - Literature

Installation

Prerequisites

  • Node.js 18+ or 20+

  • npm or yarn

Install

npm install
npm run build

Installation

Via npm (Recommended)

npm install -g sdamgia-mcp-server

Or use without installation via npx:

npx sdamgia-mcp-server

From Source

git clone https://github.com/art22017/sdamgia-mcp-server.git
cd sdamgia-mcp-server
npm install
npm run build

Configuration

The server can be configured with any MCP-compatible client. Below are instructions for popular platforms:

Claude Code

Config file locations:

  • User scope: ~/.claude.json (available across all projects)

  • Project scope: .mcp.json in project root (shared with team)

{
  "mcpServers": {
    "sdamgia": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "sdamgia-mcp-server"]
    }
  }
}

Alternative: Via CLI

claude mcp add sdamgia --scope user npx -y sdamgia-mcp-server

Cursor

Config file locations:

  • Project: .cursor/mcp.json (in project directory)

  • Global: ~/.cursor/mcp.json (home directory)

{
  "mcpServers": {
    "sdamgia": {
      "command": "npx",
      "args": ["-y", "sdamgia-mcp-server"]
    }
  }
}

Or via UI: Settings → Tools & Integrations → MCP Servers → Add New MCP Server

Kilocode

Config file locations:

  • Project: .kilocode/mcp.json

  • Global: Via Settings → MCP Servers → Edit Global MCP

{
  "mcpServers": {
    "sdamgia": {
      "command": "npx",
      "args": ["-y", "sdamgia-mcp-server"],
      "disabled": false
    }
  }
}

Note: VS Code and CLI configurations are separate in Kilocode.

Google Antigravity

Config file locations:

  • macOS/Linux: ~/.config/antigravity/mcp.json or ~/.gemini/antigravity/mcp_config.json

  • Windows: %APPDATA%\antigravity\mcp.json

{
  "mcpServers": {
    "sdamgia": {
      "command": "npx",
      "args": ["-y", "sdamgia-mcp-server"],
      "trust": false
    }
  }
}

Or via UI: Agent panel → Three-dot menu → MCP Servers → Manage MCP Servers

Gemini CLI

Config file location: ~/.gemini/settings.json

{
  "mcpServers": {
    "sdamgia": {
      "command": "npx",
      "args": ["-y", "sdamgia-mcp-server"]
    }
  }
}

MCP Inspector (for testing)

npx @modelcontextprotocol/inspector npx -y sdamgia-mcp-server

Usage

Once configured, restart your AI assistant and the server will be available. Use the tools described below.

Available Tools

1. sdamgia_get_problem

Retrieve a specific problem by ID.

Parameters:

  • subject (required): Subject code (e.g., "math", "phys")

  • problem_id (required): Problem ID (numeric string)

  • response_format (optional): "json" or "markdown" (default: "markdown")

Example:

{
  "subject": "math",
  "problem_id": "1001",
  "response_format": "markdown"
}

2. sdamgia_search_problems

Search for problems using text query.

Parameters:

  • subject (required): Subject code

  • query (required): Search query text (3-500 characters)

  • limit (optional): Max results (1-50, default: 20)

  • response_format (optional): Output format

Example:

{
  "subject": "math",
  "query": "вероятность",
  "limit": 10
}

3. sdamgia_search_by_text

Find problems by condition text with fuzzy matching.

Parameters:

  • subject (required): Subject code

  • condition_text (required): Problem text to search (10-1000 characters)

  • threshold (optional): Similarity threshold 0-1 (default: 0.6)

  • limit (optional): Max results (1-50, default: 20)

  • response_format (optional): Output format

Example:

{
  "subject": "phys",
  "condition_text": "Найдите силу тока в цепи если сопротивление",
  "threshold": 0.7,
  "limit": 5
}

Use Cases:

  • User has a photo/text of a problem but doesn't know the ID

  • Finding similar problems to a given condition

  • Matching slight variations in problem wording

4. sdamgia_batch_get_problems

Retrieve multiple problems at once.

Parameters:

  • subject (required): Subject code

  • problem_ids (required): Array of problem IDs (1-10 items)

  • response_format (optional): Output format

Example:

{
  "subject": "inf",
  "problem_ids": ["1001", "1002", "1003"]
}

5. sdamgia_get_catalog

Get complete catalog structure for a subject.

Parameters:

  • subject (required): Subject code

  • response_format (optional): Output format

Example:

{
  "subject": "math",
  "response_format": "json"
}

6. sdamgia_get_category_problems

Get all problems from a specific category.

Parameters:

  • subject (required): Subject code

  • category_id (required): Category ID (from catalog)

  • limit (optional): Max results (1-50, default: 20)

  • response_format (optional): Output format

Example:

{
  "subject": "math",
  "category_id": "174",
  "limit": 30
}

7. sdamgia_get_test

Get all problems from a test.

Parameters:

  • subject (required): Subject code

  • test_id (required): Test ID (numeric string)

  • response_format (optional): Output format

Example:

{
  "subject": "math",
  "test_id": "1770"
}

Architecture

sdamgia-mcp-server/
├── src/
│   ├── index.ts              # Main entry point
│   ├── types.ts              # TypeScript type definitions
│   ├── constants.ts          # Configuration constants
│   ├── services/
│   │   ├── sdamgia-client.ts # API client (web scraping)
│   │   ├── text-utils.ts     # Fuzzy text matching utilities
│   │   └── formatters.ts     # Output formatters
│   ├── schemas/
│   │   └── input-schemas.ts  # Zod validation schemas
│   └── tools/
│       ├── problem-tools.ts  # Problem-related tools
│       └── catalog-tools.ts  # Catalog-related tools
└── dist/                     # Compiled JavaScript

Design Decisions

1. Comprehensive API Coverage

All major endpoints are exposed as separate tools, giving LLMs maximum flexibility to compose complex workflows.

2. Fuzzy Text Matching

The sdamgia_search_by_text tool uses:

  • Levenshtein distance for character-level similarity

  • Keyword overlap for semantic matching

  • Combined scoring for robust results

This solves the problem of finding problems when text is slightly different (OCR errors, typos, reformatting).

3. Efficient Batch Operations

Batch tool reduces request overhead when multiple problems are needed, improving performance for LLM agents.

4. Response Format Flexibility

Both JSON and Markdown outputs:

  • JSON: For programmatic processing and data extraction

  • Markdown: For human-readable presentation

5. Request Economy

  • Caching: Client could cache frequently accessed data

  • Pagination: Limits prevent over-fetching

  • Smart Search: Fuzzy search does broad search first, then filters locally

6. Type Safety

Full TypeScript + Zod validation ensures:

  • Runtime input validation

  • Clear error messages

  • IDE autocomplete support

API Endpoints Used

Based on reverse-engineered СДАМ ГИА API:

  • GET /{subject}-ege.sdamgia.ru/problem?id={id} - Get problem

  • GET /{subject}-ege.sdamgia.ru/search?search={query} - Search

  • GET /{subject}-ege.sdamgia.ru/test - Get catalog

  • GET /{subject}-ege.sdamgia.ru/test?id={id} - Get test

  • GET /{subject}-ege.sdamgia.ru/prob_catalog?category={id} - Get category

Note: This is an unofficial API based on web scraping. No official API exists.

Limitations

  1. No Official API: Uses web scraping, may break if site structure changes

  2. Rate Limiting: No built-in rate limiting (could be added)

  3. No Caching: Each request hits the server (could add Redis/file cache)

  4. Russian Only: Platform is in Russian language

  5. Network Required: Requires internet connection to СДАМ ГИА servers

Future Enhancements

  • Add request caching layer

  • Implement rate limiting

  • Add support for PDF generation

  • Add image OCR for problem text extraction

  • Add test generation tool

  • Add progress tracking across problems

  • Add HTTP transport for remote deployment

Contributing

Contributions welcome! Please:

  1. Follow existing code style

  2. Add tests for new features

  3. Update documentation

  4. Keep tools focused and composable

License

MIT License - See LICENSE file for details

Credits

Based on research from:

  • sdamgia-api - Python implementation

  • СДАМ ГИА platform - Educational resources

Disclaimer

This is an unofficial tool for educational purposes. Not affiliated with СДАМ ГИА.

Available Tools

7 tools
sdamgia_batch_get_problemsBatch Retrieve Multiple ProblemsA
Read-onlyIdempotent

Efficiently retrieves multiple complete problems from the СДАМ ГИА database in a single request.

When to use:

  • You have multiple problem IDs and need all their details

  • You want to compare several problems side-by-side

  • You're building a problem set or practice collection

  • You need to fetch related problems after a search

  • You want to reduce API calls compared to individual get_problem requests

Parameters:

  • subject (required): Subject code for all problems (all IDs must belong to this subject)

  • problem_ids (required): Array of problem IDs to fetch. Must include 1-10 problem IDs as numeric strings (e.g., ["12345", "67890", "54321"])

  • response_format (optional): 'markdown' (default) or 'json'

Returns:

  • problems: Array of complete problem objects, each containing:

    • condition: Full problem statement with text and optional HTML/images

    • solution: Detailed step-by-step solution

    • answer: The correct answer

    • similar_problems: Related problem IDs

    • metadata: Problem ID, subject, difficulty level

  • total: Number of problems successfully fetched

Response format:

  • Markdown: Formatted text with each problem in a separate section, clearly delineated with problem IDs

  • JSON: Structured object with problems array and metadata

Example usage:

{
  "subject": "math",
  "problem_ids": ["12345", "67890", "54321", "11111", "22222"],
  "response_format": "markdown"
}

Typical workflow:

  1. Use sdamgia_search_problems to find relevant problem IDs

  2. Pass the IDs to this tool for batch retrieval

  3. Review all problems together for comparison or practice

Performance benefits:

  • Single API call instead of multiple individual calls

  • Faster than sequential sdamgia_get_problem requests

  • Ideal for fetching 2-10 problems at once

  • Reduces network overhead and latency

Constraints:

  • Maximum 10 problems per batch request

  • All problem IDs must be valid numeric strings

  • All problems must be from the same subject

  • Invalid IDs will cause the entire batch to fail

  • Fetching many problems may return large responses

Error handling:

  • If any problem ID is invalid or not found, the entire batch fails

  • Make sure all IDs exist in the subject before batching

  • Consider splitting into smaller batches if you encounter errors

Notes:

  • Batch size is limited to 10 to prevent excessive response sizes

  • Use when you need full problem details, not just IDs

  • For searching, use sdamgia_search_problems first

  • Each problem includes similar problems for extended practice

  • All problems in batch are fetched in parallel for speed

ParametersJSON Schema
NameRequiredDescriptionDefault
subjectYesSubject code
problem_idsYesArray of problem IDs to fetch
response_formatNomarkdown

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint and idempotentHint. Description adds that entire batch fails on invalid ID, parallel fetching, and return format details, providing good context beyond annotations.

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?

Well-structured with sections, bullet points, example usage, typical workflow, performance benefits, constraints, error handling. Content is front-loaded and every sentence adds value for a batch tool.

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?

No output schema, but description thoroughly explains return structure, usage, constraints, error handling, performance, and workflow with sibling tools. Complete for the tool's complexity.

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 has 67% description coverage. Description enriches parameters with usage details (numeric strings, max 10, must be same subject) and explains return structure (problems with condition, solution, etc.) not in 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 it retrieves multiple complete problems in a single request, which distinguishes it from sibling tools like sdamgia_get_problem (individual) and search tools.

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?

Provides explicit 'When to use' bullet points, mentions alternatives (individual get_problem for fewer, search for finding IDs), and includes constraints (max 10, same subject, batch fails on invalid IDs).

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

sdamgia_get_catalogGet Problem CatalogA
Read-onlyIdempotent

Retrieves the complete hierarchical catalog structure for a specified subject, including all topics, subtopics, and problem categories with their unique identifiers.

PURPOSE: This is the primary discovery tool for exploring what problem content is available on the platform. It returns the full taxonomy of problem categories organized by topics, enabling you to navigate and find specific types of problems.

WHEN TO USE:

  • Always use this FIRST when exploring a new subject to understand its structure

  • Use when you need to find category IDs for other tools (required prerequisite for sdamgia_get_category_problems)

  • Use when you need to understand the organization and topics available for a subject

  • Use when building problem sets and need to browse available content

  • Essential for discovering what problem types exist before querying specific categories

KEY PARAMETERS:

  • subject (required): The subject identifier (e.g., 'ege', 'oge', 'math')

  • response_format (optional): Output format - 'json' for structured data, 'markdown' for formatted text (default: 'json')

RESPONSE FORMAT: Returns an array of catalog entries, where each entry contains:

  • name: Human-readable topic/category name

  • id: Unique category identifier (required for other tools)

  • children: Optional array of subcategories (nested hierarchy)

The response is hierarchical - categories may contain subcategories, and leaf nodes represent actual problem categories you can query.

IMPORTANT NOTES:

  • This tool ONLY returns category structure and IDs, NOT actual problems

  • Must be called before using sdamgia_get_category_problems to obtain valid category_id values

  • Category IDs are specific to each subject - the same ID may mean different things across subjects

  • The catalog structure can change over time as new content is added

  • Response size can be large for comprehensive subjects

EXAMPLE WORKFLOW:

  1. Call sdamgia_get_catalog(subject='ege') to get all EGE categories

  2. Parse response to find desired category (e.g., "Quadratic Equations" with id='12345')

  3. Use category_id='12345' with sdamgia_get_category_problems to get actual problems

TYPICAL USE CASES:

  • "Show me all available topics for EGE mathematics"

  • "What categories exist under 'Algebra' for OGE?"

  • "Find the category ID for trigonometry problems"

  • "Browse the complete problem catalog structure"

ParametersJSON Schema
NameRequiredDescriptionDefault
subjectYesSubject code
response_formatNomarkdown

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already indicate read-only, non-destructive, and idempotent. The description adds details that the tool returns only structure, not problems, and that IDs are subject-specific and may change over time, which are useful beyond annotations.

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 well-structured with sections (PURPOSE, WHEN TO USE, KEY PARAMETERS, etc.), each sentence adds value, and it is front-loaded with the core purpose.

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 no output schema, the description explains the response format, provides an example workflow, and lists use cases. It is complete for a tool with two parameters and moderate complexity.

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 50%, but the description explains both parameters: subject (required, with context about its role) and response_format (optional, with default). It adds meaning beyond the enum values in 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 explicitly states the tool retrieves the hierarchical catalog structure for a subject, with verb 'retrieves' and resource 'catalog structure'. It distinguishes from siblings by noting it is a prerequisite for sdamgia_get_category_problems.

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 provides clear when-to-use scenarios, such as 'first when exploring a new subject' and 'when you need category IDs for other tools'. It lacks explicit when-not-to-use statements but effectively implies alternatives.

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

sdamgia_get_category_problemsGet Category ProblemsA
Read-onlyIdempotent

Retrieves all problem identifiers belonging to a specific problem category within a subject.

PURPOSE: Fetches the complete list of unique problem IDs for problems classified under a specific category. This enables you to identify exactly which problems exist in a category before retrieving their full details or solutions.

WHEN TO USE:

  • Use AFTER obtaining a category_id from sdamgia_get_catalog (required prerequisite)

  • Use when you need to see all available problems in a specific category

  • Use when building problem sets from particular topics

  • Use when you need to count how many problems exist in a category

  • Use when selecting specific problems before fetching their full content

  • Essential for batch operations on category-level problem sets

KEY PARAMETERS:

  • subject (required): The subject identifier (e.g., 'ege', 'oge', 'math')

  • category_id (required): Unique category identifier obtained from sdamgia_get_catalog

  • limit (optional): Maximum number of problem IDs to return (for pagination or sampling)

  • response_format (optional): Output format - 'json' for structured data, 'markdown' for formatted text (default: 'json')

PARAMETER CONSTRAINTS:

  • category_id MUST be a valid ID from the catalog - invalid IDs will return errors

  • If category has no problems, returns empty array

  • limit parameter truncates results if specified; otherwise returns all problems

  • Category IDs are subject-specific - same ID may exist in multiple subjects but refer to different content

RESPONSE FORMAT: Returns an array of problem ID strings/numbers:

  • Each ID represents a unique problem that can be fetched with other tools

  • IDs are typically numeric but returned as strings

  • Order of IDs may not be sequential or sorted

  • Array may be empty for new or unused categories

  • Total count of problems is included in response metadata

IMPORTANT NOTES:

  • This tool ONLY returns problem IDs, NOT problem content, statements, or solutions

  • You MUST call sdamgia_get_catalog first to obtain valid category_id values

  • category_id values are case-sensitive and must match exactly from catalog

  • Large categories may return hundreds or thousands of IDs

  • The same problem ID may appear in multiple categories (cross-categorized content)

  • Invalid or expired category IDs will cause the request to fail

EXAMPLE WORKFLOW:

  1. Call sdamgia_get_catalog(subject='ege') to browse categories

  2. Find desired category (e.g., id='12345' for "Derivatives")

  3. Call sdamgia_get_category_problems(subject='ege', category_id='12345')

  4. Receive array: [1001, 1002, 1005, 1102, ...]

  5. Use individual problem IDs with sdamgia_get_problem to get full content

TYPICAL USE CASES:

  • "Get all problems in the 'Quadratic Equations' category for EGE"

  • "List first 50 problems from category ID 54321"

  • "How many practice problems exist for this topic?"

  • "Collect all problem IDs for a specific category to analyze difficulty distribution"

  • "Build a randomized problem set from category 67890"

ParametersJSON Schema
NameRequiredDescriptionDefault
subjectYesSubject code
category_idYesCategory ID
limitNoMaximum number of results to return
response_formatNomarkdown

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already show readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds significant behavioral context: returns only IDs, not content; valid category required; large categories; cross-categorization; empty array for unused categories; response format metadata.

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?

Well-structured with sections like PURPOSE, WHEN TO USE, KEY PARAMETERS, etc. Front-loaded with purpose. However, it is verbose and repeats some information (e.g., 'only returns IDs' mentioned multiple times). Could be more concise but still clear.

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 no output schema, the description fully explains response format (array of IDs with metadata). Covers prerequisites, error conditions, example workflow, and use cases. All necessary information for an agent to use the tool correctly.

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 descriptions are minimal (subject, category_id, limit, response_format). Description adds detailed constraints, usage notes, and examples for each parameter. However, there is a contradiction: description says response_format default is 'json' while schema says 'markdown'. Also, description says limit returns all if unspecified, but schema default is 20. These inconsistencies reduce score.

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 it retrieves problem identifiers for a category within a subject. It distinguishes from siblings by noting it only returns IDs, not content, and that prerequisite catalog call is needed.

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?

Provides explicit WHEN TO USE conditions, prerequisites (call sdamgia_get_catalog first), and indicates it is for ID retrieval before full content fetch. Implicitly tells when not to use by stating it returns only IDs.

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

sdamgia_get_problemGet СДАМ ГИА Problem by IDA
Read-onlyIdempotent

Retrieves a complete problem from the СДАМ ГИА database by its unique identifier.

When to use:

  • You have a specific problem ID and need its full details

  • You need to see the problem statement, solution, answer, and similar problems

  • You want to reference an exact problem from the СДАМ ГИА database

Parameters:

  • subject (required): Subject code (e.g., 'math', 'phys', 'inf', 'rus', 'chem', 'bio', 'geo', 'hist', 'soc', 'en', 'de', 'fr', 'sp', 'lit')

  • problem_id (required): Numeric problem ID as a string (e.g., "12345")

  • response_format (optional): Output format - 'markdown' (default, human-readable) or 'json' (structured data)

Returns: A complete problem object containing:

  • condition: The problem statement (text and optional HTML/images)

  • solution: Step-by-step solution with explanations

  • answer: The correct answer

  • similar_problems: List of related problem IDs for further practice

  • metadata: Problem ID, subject, difficulty level where available

Response format:

  • Markdown: Formatted text with sections for condition, solution, answer, and similar problems

  • JSON: Structured object with all problem data as nested objects/arrays

Example: Getting a specific math problem:

{
  "subject": "math",
  "problem_id": "54321",
  "response_format": "markdown"
}

Notes:

  • Problem IDs must be numeric strings (digits only)

  • The problem_id must exist in the specified subject database

  • Some problems may not have solutions available

  • Similar problems are automatically included for practice

  • Use this tool when you need exact problem details, not for searching

ParametersJSON Schema
NameRequiredDescriptionDefault
subjectYesSubject code (e.g., 'math', 'phys', 'inf')
problem_idYesProblem ID (numeric string)
response_formatNoOutput format: 'markdown' for readable text or 'json' for structured datamarkdown

TDQS

A5/5.0
Behavior5/5

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

Adds constraints (numeric ID, existence prerequisite), content expectations (possible missing solutions), and behavior (similar problems included), going well beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Well-structured with clear headings and front-loaded purpose; every sentence adds value without redundancy.

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?

Compensates for missing output schema by detailing return object structure, and covers edge cases and metadata; sibling differentiation is clear.

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 coverage is 100%, but description adds examples, enum context, default explanation, and input example, enhancing understanding.

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 retrieves a complete problem by unique identifier, distinguishing it from sibling tools like batch retrieval or search.

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?

Provides explicit 'when to use' scenarios and an explicit exclusion ('not for searching'), with alternatives implied by sibling names.

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

sdamgia_get_testGet Test ProblemsA
Read-onlyIdempotent

Retrieves all problem identifiers that comprise a specific test or examination variant.

PURPOSE: Fetches the complete list of problem IDs that make up a predefined test or exam variant. Tests are curated collections of problems designed to simulate actual exam conditions or assess specific skill sets.

WHEN TO USE:

  • Use when you need to see all problems in a specific test variant or exam

  • Use when working with practice tests or mock exams

  • Use when you need the complete problem set for timed test simulations

  • Use when analyzing test composition or difficulty distribution

  • Use when preparing for real exams by reviewing official test variants

  • Essential for accessing complete, ready-made problem collections

KEY PARAMETERS:

  • subject (required): The subject identifier (e.g., 'ege', 'oge', 'math')

  • test_id (required): Unique identifier for the specific test/variant to retrieve

  • response_format (optional): Output format - 'json' for structured data, 'markdown' for formatted text (default: 'json')

PARAMETER CONSTRAINTS:

  • test_id must be a valid, existing test identifier for the specified subject

  • Invalid test IDs will result in errors or empty results

  • Test IDs are typically numeric but may include alphanumeric codes

  • Not all test IDs may be publicly accessible or available

  • Test availability may vary by subject and time period

RESPONSE FORMAT: Returns an array of problem ID strings/numbers:

  • Each ID represents a problem in the test sequence

  • IDs are returned in test order (first problem to last)

  • Tests typically contain 5-25 problems depending on exam type

  • Total count of problems is included in response metadata

  • Problems are already curated and balanced by difficulty/topic

IMPORTANT NOTES:

  • This tool ONLY returns problem IDs, NOT problem content, statements, or solutions

  • Test IDs are different from category IDs - they reference specific exam variants

  • Test composition is fixed and determined by test creators

  • The same problem may appear in multiple tests

  • Tests are designed to be completed within specific time limits

  • Some tests may include special instructions or sections not visible in ID list

  • Test availability may be limited by region, year, or exam board

DISTINCTION FROM CATEGORY QUERIES: Unlike sdamgia_get_category_problems which fetches all problems from a topic, this tool fetches problems from a specific, curated test variant. Tests are pre-assembled problem sets, while categories are thematic collections.

EXAMPLE WORKFLOW:

  1. Obtain test_id from external source (e.g., 'ege-2023-variant-123' or numeric ID)

  2. Call sdamgia_get_test(subject='ege', test_id='12345')

  3. Receive ordered array: [5001, 5002, 5003, 5004, 5005, ...]

  4. Use individual problem IDs with sdamgia_get_problem for full content

  5. Present problems in order to simulate actual exam experience

TYPICAL USE CASES:

  • "Get all problems from EGE 2023 variant 15"

  • "Show me the complete problem list for OGE practice test 7"

  • "Retrieve all problems in diagnostic test variant 42"

  • "What problems are included in the final exam simulation test?"

  • "Fetch the problem IDs for yesterday's practice test"

PRACTICAL APPLICATIONS:

  • Creating timed practice sessions with real exam variants

  • Analyzing difficulty patterns in official tests

  • Comparing problem distributions across different test years

  • Building test preparation schedules using official variants

  • Reviewing complete test content before exam day

ParametersJSON Schema
NameRequiredDescriptionDefault
subjectYesSubject code
test_idYesTest ID (numeric string)
response_formatNomarkdown

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses that it returns only problem IDs (not content), explains test composition, limitations on availability, and time limits. No contradiction with annotations.

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?

Well-structured with clear sections and bullet points, but excessively verbose. Many sentences could be condensed without losing clarity.

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 no output schema, the description explains the response format (array of IDs, order, count) and covers edge cases (invalid IDs, availability). All aspects needed for an agent to use the tool correctly are addressed.

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?

Adds meaning beyond the schema by explaining the response_format parameter (output format), constraints on test_id (valid, numeric, availability), and the difference between test_id and category IDs. Schema coverage is 67%, and description compensates thoroughly.

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 the tool retrieves all problem identifiers for a specific test variant. Distinguishes from sibling tools, especially sdamgia_get_category_problems, by emphasizing curated test sets vs thematic collections.

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?

Provides explicit when-to-use scenarios and a dedicated 'DISTINCTION FROM CATEGORY QUERIES' section explaining when not to use this tool, with clear alternatives.

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

sdamgia_search_by_textSearch Problems by Condition Text (Fuzzy Match)A
Read-onlyIdempotent

Finds problems by matching against their full condition text using fuzzy text similarity algorithms.

When to use:

  • You have a problem's exact condition text but don't know its ID

  • You're looking for problems similar to one you've seen before

  • You want to find problems with nearly identical wording

  • You need to detect duplicate or similar problems across the database

  • You have partial problem text and want to find the closest matches

How it works:

  1. Performs a broad search to find candidate problems

  2. Fetches the full condition text for each candidate

  3. Applies fuzzy text matching to calculate similarity scores

  4. Returns problems that exceed the similarity threshold

Parameters:

  • subject (required): Subject code to search within

  • condition_text (required): The problem condition text to match against (10-1000 characters). Provide as much of the original problem text as possible for best results.

  • threshold (optional): Similarity threshold from 0.0 to 1.0 (default: 0.6). Higher values = stricter matching. Recommended: 0.5-0.7 for approximate matches, 0.8+ for exact matches.

  • limit (optional): Maximum number of matches to return (1-50, default: 20)

  • response_format (optional): 'markdown' (default) or 'json'

Returns:

  • matches: Array of matching problems, each containing:

    • problem_id: The matched problem's ID

    • similarity: Score from 0-1 indicating how closely the text matches (higher = better match)

  • total: Number of matches found

Similarity scores:

  • 1.0: Exact match (identical text)

  • 0.8-0.99: Very close match (minor differences in wording)

  • 0.6-0.79: Similar problem (same concept, different phrasing)

  • 0.4-0.59: Somewhat related (loosely connected)

  • <0.4: Poor match (not recommended)

Example usage:

{
  "subject": "math",
  "condition_text": "Find the area of a triangle with sides 3, 4, and 5 units.",
  "threshold": 0.7,
  "limit": 5,
  "response_format": "markdown"
}

Best practices:

  • Include the complete problem condition for best matching

  • For exact duplicates, set threshold to 0.9 or higher

  • For similar problems, use threshold around 0.6-0.7

  • If you get too many results, increase the threshold

  • If you get no results, decrease the threshold

Notes:

  • Condition text must be at least 10 characters

  • Fuzzy matching is computationally intensive - results may take longer

  • Searches broader than the limit, then applies fuzzy filtering

  • Some results may have lower similarity than expected due to formatting differences

  • For keyword-based searches, use sdamgia_search_problems instead

  • Follow up with sdamgia_get_problem to see full problem details

ParametersJSON Schema
NameRequiredDescriptionDefault
subjectYesSubject code to search in
condition_textYesProblem condition text to search for (supports fuzzy matching)
thresholdNoSimilarity threshold for fuzzy matching (0-1, higher = stricter)
limitNoMaximum number of results to return
response_formatNomarkdown

TDQS

A4.8/5.0
Behavior5/5

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

Annotations (readOnlyHint, destructiveHint, idempotentHint) already declare non-destructive behavior. The description adds process details (broad search, fuzzy matching), mentions computational intensity, and notes potential lower similarity due to formatting—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.

Conciseness4/5

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

The description is well-structured with sections, bullet points, and an example. While thorough, it is not overly verbose; every section adds value, though slight trimming could improve conciseness.

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 no output schema, the description fully explains the return format (matches, similarity, total), similarity score ranges, best practices, notes, and process. It is complete for a complex search tool with 5 parameters.

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 description coverage is 80%, baseline 3. The description adds meaningful guidance: character range for condition_text, recommended threshold ranges, limit bounds, and response_format defaults, exceeding schema details.

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 finds problems by matching condition text using fuzzy similarity algorithms, distinguishing it from sibling tools like sdamgia_search_problems (keyword-based) and sdamgia_get_problem (fetch by ID).

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?

The 'When to use' section lists specific scenarios, and the notes explicitly mention using sdamgia_search_problems for keyword-based searches, providing clear guidance on when to use this tool vs alternatives.

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

sdamgia_search_problemsSearch СДАМ ГИА Problems by QueryA
Read-onlyIdempotent

Searches for problems in the СДАМ ГИА database using a text-based query.

When to use:

  • You want to find problems related to a specific topic (e.g., "quadratic equations", "Newton's laws")

  • You're exploring available problems in a subject area

  • You need to discover problem IDs before fetching full details

  • You want to browse problems by keywords or concepts

Parameters:

  • subject (required): Subject code to search within (e.g., 'math', 'phys', 'inf')

  • query (required): Search text - minimum 3 characters, maximum 500 characters. Use descriptive terms like "triangle area", "oxidation reactions", "grammar rules"

  • limit (optional): Maximum number of results (1-50, default: 20)

  • response_format (optional): 'markdown' (default) or 'json'

Returns: A list of matching problems with:

  • problem_ids: Array of problem IDs matching the search query

  • total: Count of results returned

  • In markdown format: numbered list with clickable links to each problem

Search behavior:

  • Performs text-based matching against problem descriptions and metadata

  • Results are ranked by relevance to your query

  • Search is optimized for subject-specific terminology

  • Broad search that returns problem IDs only (not full problem details)

Response format:

  • Markdown: Formatted list with problem IDs and subject context

  • JSON: Object with problem_ids array and total count

Example usage:

{
  "subject": "math",
  "query": "derivative of trigonometric functions",
  "limit": 10,
  "response_format": "markdown"
}

Follow-up workflow:

  1. Use this tool to find relevant problem IDs

  2. Use sdamgia_get_problem or sdamgia_batch_get_problems to fetch full details

Notes:

  • Query must be at least 3 characters for meaningful results

  • Maximum 50 results per search (use limit parameter)

  • Search returns IDs only - follow up with get_problem for details

  • For exact text matching with problem conditions, use sdamgia_search_by_text instead

  • Subject-specific terminology works best for quality results

ParametersJSON Schema
NameRequiredDescriptionDefault
subjectYesSubject code to search in
queryYesSearch query text
limitNoMaximum number of results to return
response_formatNomarkdown

TDQS

A4.8/5.0
Behavior5/5

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

The description adds search behavior details (text matching, relevance ranking, subject optimization) beyond the readOnly annotation, and discloses constraints like minimum query length and result limit.

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?

Well-structured with clear sections and front-loaded purpose. Slightly verbose with some repetition (e.g., 'Returns' section could be tightened).

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 tool's complexity and annotations, the description covers all necessary aspects: usage, parameters, behavior, output format, and relationships to siblings. Complete for a search 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 description explains each parameter with constraints and examples, adding value over the schema descriptions. Schema coverage is high (75%+), so a slight deduction for not fully compensating.

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 searches for problems using a text query, with a specific verb and resource. It distinguishes from siblings like sdamgia_search_by_text by noting exact matching.

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 provides explicit 'When to use' scenarios, a follow-up workflow, and mentions an alternative tool for exact matching, giving clear usage context.

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.

  1. 7 tool updatesv1.0.4
    • First observedsdamgia_batch_get_problems
    • First observedsdamgia_get_catalog
    • First observedsdamgia_get_category_problems
    • First observedsdamgia_get_problem
    • First observedsdamgia_get_test
    • First observedsdamgia_search_by_text
    • First observedsdamgia_search_problems
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: batch retrieval, catalog browsing, category listing, single problem retrieval, test listing, text-based search, and keyword search. No two tools overlap in functionality.

Naming Consistency5/5

All tools follow the consistent pattern 'sdamgia_<action>_<object>' or 'sdamgia_<action>_by_<method>'. The verbs are descriptive and maintain a uniform style.

Tool Count5/5

With 7 tools, the server covers discovery, search, and retrieval workflows without being overly numerous or sparse. Each tool serves a specific and necessary function for interacting with the problem database.

Completeness4/5

The tool set covers the main use cases: exploring catalog, searching by keyword or text, retrieving problems individually or in batches, and fetching by category or test. A minor gap is the lack of a tool to list all subjects or obtain test IDs, but the core retrieval workflow is fully supported.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Skolverket MCP Server

    isakskogstad
    A
    license
    A
    quality
    D
    maintenance
    Enables LLMs to access Swedish educational data through Skolverket's open APIs, allowing users to search curricula, courses, schools, adult education programs, and analyze educational requirements and standards. Provides comprehensive tools for teachers, students, guidance counselors, and educational researchers to interact with official Swedish education data.
    27
    10
    MIT
  • Yandex Search MCP Server by yandex

    Yandex Search MCP Serverofficial

    yandex
    F
    license
    Not graded
    quality
    F
    maintenance
    Enables AI assistants to perform real-time web searches and retrieve AI-generated answers using the Yandex Search API. It provides tools for accessing up-to-date internet information with support for both raw search results and summarized content via the Yazeka model.
    47
    -

  • SearchCAIE MCP Server

    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.
    7
    1
    -

Latest Blog Posts

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/art22017/sdamgia-mcp-server'

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