A read-only MCP server for discovering, searching, and fetching problems and resources from the Luogu competitive programming platform, designed for AI tutoring and practice agents.
Search Problems (luogu_search_problems): Search by keyword, topic, title fragment, or problem ID, with optional tag ID filters.
Fetch Problem (luogu_fetch_problem): Retrieve a full problem statement, input/output formats, sample cases, tags, difficulty, and source URL by problem ID (e.g., P1305).
Resolve Problem (luogu_resolve_problem): Resolve a Luogu URL, problem ID, or title fragment and automatically fetch the corresponding problem details.
Find Related Problems (luogu_find_related_problems): Discover related practice problems by combining topic/pain-point recommendations with keyword search.
List Algorithm Topics (luogu_list_algorithm_topics): List all canonical algorithm topics, their aliases, and known Luogu tag IDs.
Find Topic Problems (luogu_find_topic_problems): Find practice problems for a specific algorithm topic (e.g., Treap, SPFA, 动态规划) using alias expansion and tag IDs.
Search Problem Sets (luogu_search_problem_sets): Search Luogu training/problem sets by keyword.
Fetch Problem Set (luogu_fetch_problem_set): Fetch a specific training/problem set and its problem summaries by set ID.
Recommend Problems (luogu_recommend_problems): Get seed problem recommendations based on an algorithm topic or student pain point.
Get User Profile (luogu_get_user_profile): Fetch public profile data for a Luogu user by their user ID.
Get Capabilities (luogu_get_capabilities): Report which route features are currently available, require authentication, or are planned.
Click on "Deploy 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., "@luogu-mcp-server search for problems about binary trees"
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.
A small MCP server for searching Luogu problems, reading statements and training sets, and finding related practice. It can run locally through npm or as a hosted Streamable HTTP server.
Use the hosted read-only server without installing anything:
{
"mcpServers": {
"luogu": {
"url": "https://luogu-mcp.ksrnyx.top/mcp"
}
}
}To keep the server on your machine, use the published luogu-mcp-server package:
{
"mcpServers": {
"luogu": {
"command": "npx",
"args": ["-y", "luogu-mcp-server"]
}
}
}Then ask:
Search Luogu for five beginner binary-tree problems.
Fetch Luogu P1305 with its statement and samples.
Find related practice for traversal-order confusion.Related MCP server: xhs-mcp
Tool | Purpose |
| Search Luogu problems by keyword, topic, title fragment, problem id, and optional Luogu tag ids. |
| Fetch one Luogu problem statement, formats, samples, tags, difficulty, and URL by |
| Resolve a Luogu URL, problem id, or title fragment, then fetch the problem. |
| Mix topic/pain-point recommendations with live keyword search to find related practice. |
| List canonical algorithm topics, aliases, and known tag ids. |
| Find topic practice problems using aliases, tag ids, deduplication, and match reasons. |
| Search Luogu training/problem sets by keyword. Supports `type: "all" |
| Fetch one Luogu training/problem set and problem summaries by id. |
| Return seed recommendations from a topic or student pain point. |
| Fetch public Luogu user profile data by uid. |
| Report which LeetCode-style route features are available, auth-required, or planned. |
All tools are read-only.
Hosted MCP: https://luogu-mcp.ksrnyx.top/mcp
Health: https://luogu-mcp.ksrnyx.top/health
Official MCP Registry: io.github.Kaiserunix/luogu-mcp-server, described by server.json
From source:
git clone https://github.com/kaiserunix/luogu-mcp-server.git
cd luogu-mcp-server
cmd /c npm install
cmd /c npm run buildUse node directly from a source checkout:
{
"mcpServers": {
"luogu": {
"command": "node",
"args": [
"C:\\path\\to\\luogu-mcp-server\\dist\\index.js"
],
"cwd": "C:\\path\\to\\luogu-mcp-server"
}
}
}Search problems:
{
"keyword": "二叉树",
"page": 1,
"limit": 5
}Search problems with a Luogu tag filter:
{
"keyword": "二叉树",
"tagIds": [11],
"limit": 5
}Fetch a problem:
{
"pid": "P1305",
"maxStatementChars": 5000
}Recommend from a pain point:
{
"topic": "binary_tree",
"painPoint": "traversal_order_confusion",
"limit": 3
}Resolve a pasted URL:
{
"query": "https://www.luogu.com.cn/problem/P1305",
"maxStatementChars": 5000
}Find related practice:
{
"topic": "binary_tree",
"painPoint": "traversal_order_confusion",
"query": "二叉树 遍历",
"limit": 5
}Find topic practice with alias expansion:
{
"topic": "Treap",
"limit": 5,
"excludeProblemIds": ["P3369"]
}Fetch a public user profile:
{
"uid": 1
}Search training/problem sets:
{
"keyword": "网络流",
"type": "select",
"limit": 5
}type: "all" is the default. It combines title-filtered official sets with selected user-shared set search. Use type: "official" for the public official index, or type: "select" for selected user-shared sets.
This project mirrors the useful shape of richer LeetCode MCP servers while respecting what Luogu exposes publicly:
Available now: problem search, problem fetch, URL/id/title resolution, related problem discovery, training set search/fetch, public user profile fetch.
Auth-required in live probes: recent submissions, public solution pages, and discussion pages.
Planned but intentionally not enabled: solution submission/run-code tools. Those require authenticated session handling and explicit write-tool safety gates.
cmd /c npm test
cmd /c npm run buildThis package also includes a stateless Streamable HTTP MCP entrypoint for Cloudflare Workers.
cmd /c npm test
cmd /c npm run smoke:cf
cmd /c npx wrangler login
cmd /c npm run deploy:cf:dry
cmd /c npm run deploy:cfThe Worker exposes the same read-only tools at /mcp, with a health endpoint at / or /health.
{
"mcpServers": {
"luogu": {
"url": "https://<your-worker-name>.<your-workers-subdomain>.workers.dev/mcp"
}
}
}Verify a deployed Worker:
cmd /c npm run smoke:cf -- https://<your-worker-name>.<your-workers-subdomain>.workers.devFor private deployments, set LUOGU_MCP_TOKEN with wrangler secret put and configure your MCP client to send an Authorization: Bearer <token> header where supported. Browser Origin requests are rejected by default; set LUOGU_MCP_ALLOWED_ORIGINS to a comma-separated origin list if browser access is needed.
See docs/cloudflare-deployment.md for the full release checklist.
Run broad live checks against Luogu's current website responses:
cmd /c npm run smoke:liveThe live smoke starts the MCP server through a real stdio client, then compares problem fetches, problem searches, training searches, training fetches, URL/id resolution, related recommendations, public user profiles, and route capabilities against Luogu content-only page responses. It is intentionally separate from unit tests because it depends on Luogu network availability and current site behavior.
Run the 100-topic algorithm coverage smoke:
cmd /c npm run smoke:topicsThe topic smoke starts the real MCP server and probes 100 algorithm categories across high-level topic search and training-set search. It fails if fewer than 98 topic searches return Luogu results.
Download one representative problem per catalog topic into a local ignored folder:
cmd /c npm run download:topicsTest a MiMo agent loop that asks the model to choose MCP tools, then executes those calls through the local stdio MCP server:
cmd /c npm run smoke:mimosmoke:mimo reads MIMO_API_KEY from the environment, or from C:\Users\qwerf\.continue\.env on this machine.
Luogu endpoints used here are content-only web endpoints, not a formal stability contract.
The server keeps outputs compact and structured for model context control.
Browser automation is intentionally not the default path. A Playwright fallback can be added later for pages that cannot be read through lightweight HTTP.
For broad topic discovery, Luogu training-set search is often cleaner than raw problem title search; raw keyword search follows Luogu's website ordering and can include title-level noise.
Fetch a Luogu problem statement, formats, samples, tags, difficulty, and source URL by pid.
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | Luogu problem id, such as P1305. | |
| maxStatementChars | No | Trim long statements for model context control. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. Description adds useful context about the returned fields (statement, formats, etc.). No contradictions. Could mention non-obvious behaviors like network dependency or speed, but not required.
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?
Single sentence, front-loaded with key action and result. No redundant words. Efficient and clear.
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?
No output schema, but description lists return components (statement, formats, samples, tags, difficulty, source URL) which is comprehensive for a fetch-by-pid tool. Missing details like error handling or result count, but acceptable.
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 description adds little beyond schema descriptions. It confirms 'by pid' and mentions trimming long statements, but schema already explains both parameters adequately.
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 the action (fetch), resource (Luogu problem), and what is returned (statement, formats, samples, tags, difficulty, source URL). It differentiates from sibling tools like search and list by specifying fetch by pid.
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?
Description implies usage when you have a specific pid and need detailed problem info, but does not explicitly state when to use vs alternatives like luogu_search_problems or luogu_find_related_problems. No exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a Luogu training/problem set and its problem summaries by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Luogu training id, such as 100. | |
| limit | No | Maximum returned problem summaries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it returns 'problem summaries', which is behavioral context beyond the annotations (readOnlyHint, openWorldHint). 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 a single 11-word sentence with no filler, efficiently conveying the purpose.
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 fetch tool with annotations and good schema coverage, the description adequately explains what it returns. However, lacking an output schema, some details about the return format would enhance 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?
Input schema has 100% coverage with clear descriptions for both parameters. The tool description adds no extra meaning beyond stating 'by id', which is already implied.
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 action ('Fetch'), the resource ('a Luogu training/problem set and its problem summaries'), and the required identifier ('by id'). This distinguishes it from sibling tools like luogu_fetch_problem (which fetches a single problem).
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 does not explicitly specify when to use this tool versus alternatives. It implies usage when the training set ID is known, but lacks guidance on when to prefer it over search or fetch individual problem tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Luogu practice problems for an algorithm topic using aliases, known Luogu tag ids, deduplication, and match reasons.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Algorithm topic or alias, such as SPFA, Prim, Treap, 二叉树, or 动态规划. | |
| limit | No | Maximum returned items. | |
| excludeProblemIds | No | Luogu problem ids to exclude from recommendations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is clear. The description adds valuable behavioral details—using aliases, tag ids, deduplication, and providing match reasons—that go beyond 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?
Single sentence that immediately conveys purpose and key features. Efficient and front-loaded, but could be slightly more structured with separate usage notes.
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?
With no output schema and 3 parameters, the description provides adequate context for topic and parameters, but lacks details on what the output (list of problems) contains—e.g., problem IDs, titles, or match reasons. Completeness is acceptable but not thorough.
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 little beyond schema: 'topic' is described similarly, and 'limit'/'excludeProblemIds' are not elaborated. The mention of aliases and tag ids gives some context but does not significantly enhance schema understanding.
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 finds practice problems for an algorithm topic, mentioning specific features like aliases, tag ids, deduplication, and match reasons. It distinguishes itself from siblings like 'luogu_search_problems' and 'luogu_recommend_problems' by focusing on topic-based retrieval with deduplication.
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 for topic-based problem finding but does not explicitly state when to use this tool versus alternatives like 'luogu_search_problems' or 'luogu_recommend_problems'. No guidance on when not to use or specific prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report which LeetCode-style route capabilities are available, auth-required, or planned for Luogu.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description adds value by mentioning 'auth-required' capabilities, providing behavioral context beyond what annotations offer. 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 a single concise sentence that front-loads the key information and contains no unnecessary words. Every word contributes to 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?
Given no parameters, no output schema, and simple functionality, the description fully covers what the tool does and its output categories. An agent can confidently select and invoke this tool based on the description alone.
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?
The input schema has zero parameters with 100% coverage, so the description need not add parameter details. Baseline for 0 params is 4, which 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?
The description explicitly states the action ('report'), the resource ('Luogu route capabilities'), and the scope ('available, auth-required, or planned'), clearly differentiating it from sibling tools which focus on problems and user profiles.
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 for understanding capabilities but lacks explicit guidance on when to use this tool versus alternatives. Sibling tool names provide context, but no direct mention of when not to use or specific prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch public Luogu user profile data by uid.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | Luogu user id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'public' and 'profile data', which is consistent but does not significantly extend beyond annotations. It does not discuss potential side effects or restrictions beyond what's obvious.
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 a single, clear sentence that efficiently conveys the tool's purpose. No filler or redundant information.
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 tool with one parameter and no output schema, the description is adequate. It could optionally list some profile fields, but the current level is sufficient for an AI agent to understand the tool's function.
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 merely reiterates 'by uid'. The parameter 'uid' is already well-described in the schema. No additional semantic value is provided.
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 action ('Fetch'), the resource ('public Luogu user profile data'), and the input ('by uid'). It distinguishes this tool from siblings like 'luogu_fetch_problem' which fetches problem data.
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 mentions 'public' implying no special authentication, but does not provide explicit guidance on when to use this tool versus alternatives. For a simple tool, this is minimally adequate but lacks depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List canonical algorithm topics, aliases, and known Luogu tag ids used by the high-level topic search route.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=true, openWorldHint=false) already indicate the tool is read-only and not open-world. The description adds value by specifying the content of the output (canonical topics, aliases, tag ids), providing behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the main action ('List canonical algorithm topics'). Every part of the sentence is informative, with no wasted words.
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 no parameters, no output schema, and the presence of sibling tools, the description is largely complete. It explains what the tool returns and its role. However, it could mention that the list is static or cached, but this is a minor gap.
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?
There are no parameters, so schema coverage is 100%. The description does not need to explain parameters, but it adds meaning by describing the output structure. For a parameterless tool, this is appropriate and provides useful context.
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 action ('List'), the resource ('canonical algorithm topics'), and specifies the output components ('aliases, and known Luogu tag ids'). It also distinguishes itself from sibling tools like luogu_find_topic_problems which find problems using topics, while this tool lists the topics themselves.
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 this tool is used to obtain the list of algorithm topics for subsequent searches ('used by the high-level topic search route'). However, it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. Usage context is implied but not fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend seed Luogu problems from a topic or student pain point, with search hints for further exploration.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic such as binary_tree, recursion, matrix, output_format, tree_distance. | |
| painPoint | No | Student pain point such as traversal_order_confusion or sentinel_input. | |
| currentProblemId | No | Exclude this current Luogu problem id. | |
| limit | No | Maximum returned recommendations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description does not contradict this. It adds value by specifying the tool returns 'seed' problems and includes 'search hints', which gives insight into the output beyond what annotations provide. However, it does not detail other behavioral traits like pagination or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the verb and resource. Every word contributes meaning, with no repetition or fluff.
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 lacks details about the return format (e.g., what a 'seed' problem looks like, how search hints are presented). Given the absence of an output schema, this information is missing, leaving the agent without a full picture of what to expect.
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 detailed parameter descriptions. The tool description only loosely maps to the 'topic' and 'painPoint' parameters without adding new information beyond the schema. Thus, it meets the baseline but does not exceed it.
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 verb 'recommend', the resource 'Luogu problems', and the context 'from a topic or student pain point'. It also adds 'with search hints for further exploration', which distinguishes it from related sibling tools like luogu_find_related_problems or luogu_find_topic_problems by implying a focus on generating starting points.
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 when a topic or pain point is identified, but lacks explicit guidance on when to use this tool versus alternatives like luogu_find_topic_problems. No exclusions or prerequisites are mentioned, making the guidance only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a Luogu problem from a URL, problem id, or title fragment, then fetch the problem details.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Luogu URL, pid such as P1305, or title/keyword fragment. | |
| maxStatementChars | No | Trim long statements for model context control. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that it 'resolves and fetches' but does not contradict annotations. It adds minimal behavioral detail beyond what annotations provide.
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?
Single sentence, front-loaded with action and inputs, no wasted words. Highly concise.
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?
No output schema, so return structure is unspecified. Description says 'fetch problem details' but not what fields are returned. Given the tool's simplicity and annotations, it is adequate but could benefit from mentioning typical output fields.
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 reiterates the query parameter types (URL, pid, title fragment). This adds slight context but largely overlaps with the schema description. No new semantics for maxStatementChars beyond what schema says.
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 resolves a problem from URL, problem ID, or title fragment and fetches details. It distinguishes itself from siblings like luogu_fetch_problem (which likely fetches by exact ID) and luogu_search_problems (which is for 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 implies usage for ambiguous or incomplete identifiers but does not explicitly state when to use this over alternatives like luogu_fetch_problem or luogu_search_problems. No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Luogu problems by keyword. Use this before fetching a problem when you only know a topic or partial title.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Keyword, topic, title fragment, or problem id. | |
| page | No | Luogu list page, starting from 1. | |
| limit | No | Maximum returned items. | |
| tagIds | No | Optional Luogu tag ids to narrow topic search, such as [11] for tree-related searches. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's 'Search' is consistent. No additional behaviors (e.g., pagination details, rate limits) are disclosed. The description adds minimal value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then usage guidance. No redundant or extraneous information. Highly efficient.
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 search tool with well-described parameters and annotations, the description is mostly complete. It lacks details about the output format, but that is often implicit for search tools. Given the complexity and sibling tools, it provides sufficient context for agent decision-making.
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 description coverage is 100%, with all parameters already described in the schema. The description does not add any new details about parameters beyond what is in 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?
Clearly states the verb 'Search', resource 'Luogu problems', and mechanism 'by keyword'. The description also distinguishes from fetching by specifying 'Use this before fetching a problem when you only know a topic or partial title.' This differentiates it from siblings like luogu_fetch_problem.
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?
Explicitly says when to use it ('when you only know a topic or partial title') and implies a sequence: search then fetch. It doesn't name specific sibling tools, but the sibling context is clear from the tool list. Provides good guidance without being overly prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Luogu training/problem sets by keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Training set keyword or title fragment. | |
| page | No | Luogu training list page, starting from 1. | |
| limit | No | Maximum returned items. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, which cover safety and completeness. The description adds no extra behavioral context (e.g., pagination behavior, result structure). It is adequate but does not enhance transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff or redundancy. It efficiently communicates the core action.
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 tool lacks an output schema, yet the description does not explain the return format (e.g., list of training sets with IDs/titles). Given the openWorldHint, additional context about result consistency would be beneficial. The description is too sparse for a search tool.
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 all three parameters already described in the input schema. The description adds no additional semantic detail beyond what the schema provides, so baseline of 3 applies.
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 training/problem sets by keyword, uniquely distinguishing it from sibling tools like luogu_search_problems (which searches individual problems) and luogu_fetch_problem_set (which fetches a specific set).
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 provides no guidance on when to use this tool versus alternatives. For example, it does not mention that this tool is for finding training sets while luogu_search_problems is for individual problems, leaving the agent without explicit selection criteria.
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.
v0.2.0luogu_fetch_problemluogu_fetch_problem_setluogu_find_related_problemsluogu_find_topic_problemsluogu_get_capabilitiesluogu_get_user_profileluogu_list_algorithm_topicsluogu_recommend_problemsluogu_resolve_problemluogu_search_problem_setsluogu_search_problemsScored across 11 tools
Most tools have distinct purposes, but luogu_find_related_problems and luogu_recommend_problems overlap in recommending problems, and luogu_fetch_problem vs luogu_resolve_problem serve similar fetching roles with different inputs, which may cause minor confusion.
All tools follow a consistent 'luogu_verb_noun' pattern using snake_case, with clear verb choices that describe the action (fetch, search, find, etc.). No mixing of conventions.
11 tools is within the ideal 3-15 range, covering problem retrieval, search, recommendation, problem sets, user profile, algorithm topics, and capabilities. The scope is well-balanced.
The tool set covers problem discovery, retrieval, and user profiles comprehensively, but lacks tools for submissions, authentication, or contest data. However, given the apparent focus on problem exploration, it is reasonably complete.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
