Luogu MCP Server
Server Details
Search Luogu problems, fetch statements, explore problem sets and get practice recommendations.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Kaiserunix/luogu-mcp-server
- GitHub Stars
- 2
- Server Listing
- luogu-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 11 of 11 tools scored.
Most tools have distinct purposes, but there is some overlap among problem-finding tools (find_related, find_topic, recommend, search). Descriptions help differentiate them, so ambiguity is low but not absent.
All tools follow a consistent 'luogu_verb_noun' pattern with lowercase underscores. Verbs are varied but the pattern is uniform, making naming predictable.
11 tools is well-scoped for a problem discovery and user profile server. It covers essential operations without being excessive or insufficient.
The tool surface covers problem browsing, searching, recommendations, and user profiles. Missing submission and contest features, but these may be intentionally excluded, leaving only minor gaps.
Available Tools
11 toolsluogu_fetch_problemFetch Luogu ProblemARead-onlyInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about the fetched content (statement, samples, etc.) beyond the annotations (readOnlyHint, openWorldHint). However, it does not disclose additional behavioral traits such as error handling on invalid pid, rate limits, or output format. With annotations already signaling safe read operations, the description provides moderate added value.
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, no wasted words, directly states action and content front-loaded. 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?
Given no output schema, the description does not explain return format or behavior on missing pid. Sibling tools exist for different use cases, but this description doesn't differentiate them. Adequate for a simple fetch with two parameters but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as both parameters have descriptions. The description adds no new meaning beyond the schema: it restates 'by pid' but the pid parameter already explains its purpose. The maxStatementChars parameter is similarly already described in the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'Luogu problem', and enumerates specific content (statement, formats, samples, tags, difficulty, source URL) and method 'by pid'. This distinguishes it from sibling tools like search or resolve.
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?
No explicit when-to-use or when-not-to-use guidance is given. The description implies usage when a pid is known, but does not mention alternatives (e.g., search for finding by keywords) or exclusions. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
luogu_fetch_problem_setFetch Luogu Training SetARead-onlyInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint (safe read) and openWorldHint (unstructured output). Description adds no behavioral context beyond fetching summaries. 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, front-loaded with verb and key resource. No extraneous words. Efficient and to the point.
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 low complexity, no output schema, and annotations covering safety, description is adequate. Could be improved by specifying what 'problem summaries' include (e.g., titles, difficulty), but not required.
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%, so baseline 3. Description does not add extra meaning beyond schema (e.g., id format, limit role). No additional elaboration on parameters.
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 action (Fetch), resource (training/problem set and its problem summaries), and scope (by id). Distinguishes from siblings like luogu_fetch_problem (single problem) and luogu_search_problem_sets (search).
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?
No explicit when-to-use or when-not-to-use guidance. Usage is implied by 'by id', but not contrasted with alternatives like luogu_fetch_problem or luogu_search_problem_sets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
luogu_find_topic_problemsFind Luogu Topic ProblemsARead-onlyInspect
Find Luogu practice problems for an algorithm topic using aliases, known Luogu tag ids, deduplication, and match reasons.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum returned items. | |
| topic | Yes | Algorithm topic or alias, such as SPFA, Prim, Treap, 二叉树, or 动态规划. | |
| excludeProblemIds | No | Luogu problem ids to exclude from recommendations. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint (safe read) and openWorldHint (results may vary). The description adds behavioral context: uses aliases, tag ids, deduplication, and match reasons. It could mention return format or limits, but overall adds value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Action is front-loaded. Every word adds value.
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 output schema, the description doesn't explain the return format or what 'deduplication' and 'match reasons' mean in practice. It covers input well but leaves output ambiguous. Moderate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds context that the topic parameter accepts aliases and tag ids, but this is already implied by the schema description. No significant additional meaning beyond 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?
Description clearly states the verb 'Find', resource 'practice problems for an algorithm topic', and includes distinctive features like aliases, tag ids, deduplication, and match reasons. Distinguishes from sibling tools like luogu_fetch_problem or luogu_search_problems.
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?
No explicit when-to-use or when-not-to-use guidance. While the purpose is clear, the description does not help an agent decide between this and similar tools like luogu_recommend_problems or luogu_search_problems. Agents must infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
luogu_get_capabilitiesGet Luogu Route CapabilitiesARead-onlyInspect
Report which LeetCode-style route capabilities are available, auth-required, or planned for Luogu.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only operation. The description adds valuable detail about the type of information reported (available, auth-required, or planned) beyond what annotations provide. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the purpose without unnecessary words. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameters and output schema, the description adequately explains the tool's purpose. However, it could be slightly more detailed about the output format or structure of the capabilities report.
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 description coverage is 100%. The description does not need to add parameter details, and a baseline score of 4 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 clearly specifies that the tool reports Luogu route capabilities, including their availability and auth requirements. This distinguishes it from sibling tools that focus on problems, users, or searches.
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 context implies that this tool should be used to discover available routes and their auth status, but there is no explicit guidance on when not to use it or alternatives. However, the uniqueness of the tool makes the usage reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
luogu_get_user_profileGet Luogu User ProfileARead-onlyInspect
Fetch public Luogu user profile data by uid.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | Luogu user id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. The description adds only that the data is 'public' and fetched 'by uid', which is already evident from the schema. It does not disclose additional behavioral traits such as rate limits or data freshness.
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 with no unnecessary words, front-loading the key action and resource efficiently.
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 get tool with one parameter and no output schema, the description is adequate but does not hint at the structure of the returned profile data. It is minimally complete but could be more informative.
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%, so baseline is 3. The description provides no extra meaning beyond the schema's description of 'uid' as 'Luogu user id.' No additional parameter context is added.
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 tool fetches public user profile data by uid, with a specific verb and resource. It is distinct from sibling tools which focus on problems and problem sets.
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 user profile is needed by uid, but does not explicitly state when to use or not use this tool, nor does it mention alternatives. It is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
luogu_list_algorithm_topicsList Luogu Algorithm TopicsARead-onlyInspect
List canonical algorithm topics, aliases, and known Luogu tag ids used by the high-level topic search route.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations' readOnlyHint. It confirms the tool lists data (read-only) but does not disclose any other behavioral traits such as result structure or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. Every part is informative, with no superfluous 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 and no output schema, the description is fairly complete. It states what the tool lists. However, it could specify the output format or provide more context about the tag IDs, but for a simple list tool, it is adequate.
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 no parameters, so schema coverage is 100%. The description does not need to add parameter information since there are none. According to guidelines, zero parameters baseline is 4.
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 lists canonical algorithm topics, aliases, and tag IDs. The verb 'List' and specific resource 'canonical algorithm topics' make the purpose unambiguous and distinct from sibling tools that fetch problems or perform searches.
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 provide guidance on when to use this tool versus alternatives. It only mentions it is used by a 'high-level topic search route' without explicit when-to-use or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
luogu_recommend_problemsRecommend Luogu ProblemsARead-onlyInspect
Recommend seed Luogu problems from a topic or student pain point, with search hints for further exploration.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum returned recommendations. | |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds that the tool provides 'search hints for further exploration,' which hints at additional output beyond just problem IDs, but does not elaborate on the behavior of the recommendation algorithm or the nature of the hints.
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, front-loaded sentence with no unnecessary words. Every part contributes meaning: the verb 'recommend', the resource 'seed Luogu problems', and the qualifiers 'from a topic or student pain point' and 'with search hints' are all relevant.
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 is adequate for a simple recommendation tool, but given the lack of an output schema and 4 parameters, it could be more complete. It does not explain how topic and painPoint interact, what 'search hints' mean, or what the return format looks like. Sibling tools provide alternatives but no guidance.
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 parameters are well-documented in schema. The description mentions 'topic or student pain point,' which aligns with the topic and painPoint parameters, but does not add new semantic details beyond what the schema descriptions already provide.
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 recommends Luogu problems based on a topic or student pain point, using the verb 'recommend' and specifying the resource 'seed Luogu problems'. It mentions 'search hints for further exploration,' which helps differentiate from sibling tools like luogu_search_problems that likely just search.
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 known, but it does not provide explicit guidance on when to use this tool versus siblings like luogu_search_problems or luogu_find_related_problems. No exclusions or alternative tool mentions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
luogu_resolve_problemResolve Luogu ProblemARead-onlyInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds context about trimming long statements (maxStatementChars), but does not disclose other behavioral traits like auth needs, rate limits, or behavior on multiple matches. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys the tool's purpose and parameters. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema) and annotations, description covers key aspects. However, could improve by mentioning output format or potential resolution ambiguity.
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%. Description adds value beyond schema by providing examples for 'query' (URL, pid like P1305) and explaining purpose of 'maxStatementChars' (trim for context control).
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 verb (resolve and fetch) and resource (Luogu problem), and specifies input methods (URL, id, title fragment). It distinguishes from siblings like luogu_fetch_problem by implying it handles ambiguous queries.
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 for resolving problems from various input forms, but lacks explicit guidance on when to use this vs. sibling tools like luogu_fetch_problem or luogu_search_problems. No mention of scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
luogu_search_problemsSearch Luogu ProblemsARead-onlyInspect
Search Luogu problems by keyword. Use this before fetching a problem when you only know a topic or partial title.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| keyword | Yes | Keyword, topic, title fragment, or problem id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds behavioral context by explaining the search scenario, which aligns with the annotations and provides additional value.
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 extremely concise (two sentences) and front-loaded with the core purpose and usage guidance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose and usage adequately. No output schema is provided, but for a search tool, the description is sufficient for correct invocation.
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% for all parameters. The description does not add new information beyond what the schema already provides for parameters, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search Luogu problems by keyword') and the resource. It distinguishes itself from sibling tools by specifying usage before fetching when only a topic or partial title is known.
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 explicit guidance on when to use this tool ('Use this before fetching a problem when you only know a topic or partial title'). It implies when not to use, but does not list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
luogu_search_problem_setsSearch Luogu Training SetsARead-onlyInspect
Search Luogu training/problem sets by keyword. By default, combines title-filtered official sets with selected user-shared sets.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Luogu training list page, starting from 1. | |
| type | No | Search scope: all combines official and selected sets; official filters Luogu official sets by title; select searches selected user-shared sets. | |
| limit | No | Maximum returned items. | |
| keyword | Yes | Training set keyword or title fragment. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that results combine official and user-shared sets, providing extra context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and contains 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 search tool with fully described parameters and annotations, the description provides key behavioral context (default combination of sources). Could mention default limit or pagination, but not essential given the schema.
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%, so the schema already explains all parameters. The tool description does not add new parameter information beyond what is in the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches training/problem sets by keyword, and specifies the default behavior of combining official and user-shared sets. This distinguishes it from sibling tools that search problems or fetch specific sets.
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 explains the default behavior and scope, giving the agent context. However, it lacks explicit guidance on when not to use the tool or mention of sibling alternatives like luogu_fetch_problem_set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.