cf-mcp-orange

by spr7a

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.6
Disambiguation5/5
Each tool has a clearly distinct purpose: user comparison, profile retrieval, submission history, problem details, problem search, and three distinct practice recommendation strategies (weakness-based, random, contest-upsolve). Descriptions are detailed enough to prevent confusion.
Naming Consistency4/5
All tools follow verb_noun pattern in snake_case, with seven starting with 'get_' and one starting with 'compare_'. This slight inconsistency is minor but noticeable.
Tool Count5/5
Eight tools cover the core needs for a Codeforces practice assistant without being overwhelming. Each tool serves a necessary function, and the count feels well-scoped.
Completeness4/5
The set covers user profiles, submissions, problem search, and multiple practice recommendations. Missing features like contest listing or editorial access are minor omissions given the focus on individual practice.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions the return type but not edge cases (e.g., non-existent users), permissions, rate limits, or potential side effects. The description lacks sufficient detail for an agent to fully anticipate tool behavior.
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 two sentences long, front-loading the purpose and then detailing what the comparison includes. Every sentence adds value without redundancy or fluff. Ideal conciseness for this tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema to document return values, so the description does not need to repeat that. However, the description lacks context about prerequisites (e.g., users must exist), error handling, or the scope of data used. Minimal but covers the core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters user_a and user_b. While the names suggest usernames, the description should confirm this and specify any constraints (e.g., must be valid Codeforces handles). With 0% coverage, the description fails to compensate, leaving ambiguity.
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 verb 'compare', the resource 'Codeforces users', and the scope 'side-by-side' with specific comparison aspects (ratings, titles, contest count, problem solving breakdown). It distinguishes itself from siblings like get_user which likely returns individual user data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for comparing two users, but does not explicitly state when to use it instead of alternatives (e.g., get_user for single user details). No when-not-to-use guidance is provided. The purpose is clear, but a more explicit usage context would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It describes the main behavior (analyzes last 10 contests, recommends up to 2 problems per contest under rating conditions), but does not disclose limits like contests fewer than 10, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, concise and front-loaded. Conditions are listed clearly. However, it could be slightly more structured (e.g., bullet points) for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description need not detail return values. However, it lacks explanation of what happens with fewer than 10 contests or error handling, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the 'username' parameter beyond its presence. No additional semantics are provided over the bare schema definition.
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 analyzes the last 10 rated Codeforces contests and recommends unsolved problems based on rating criteria. It uses a specific verb ('analyze', 'recommends') and distinguishes itself from sibling tools like get_problem or get_user, which do not provide this targeted upsolve suggestion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for targeted practice to improve rank, but it does not explicitly state when to use this tool versus alternatives like get_problemlist or get_random_practice. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data returned (last 1000 submissions, summary, 20 recent details) but does not mention read-only status, authentication needs, rate limits, or error handling (e.g., for missing users). The information is adequate but not exhaustive.
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 consists of two concise sentences. The first sentence states the primary action and key output, while the second adds context on usage. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the main outputs (counts, details) and use case (debugging). It is sufficiently complete for an AI agent to select and invoke correctly, though it could note if pagination exists for the 1000 submissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the 'username' parameter beyond its name. It fails to specify format, constraints, or clarify that it is the target user's username. Given the low coverage, the description does not compensate for missing 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 fetches the last 1000 submissions of a user and provides a summary of AC/WA/TLE counts plus details of the 20 most recent submissions. This specific verb+resource combination distinguishes it from siblings like get_user (basic info) or compare_user (comparisons).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is 'great for debugging how a user is performing on their current attempts,' implying a use case but does not explicitly state when to use this tool versus alternatives like compare_user or get_upsolve. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lists returned data but does not disclose side effects, rate limits, or authorization requirements. Suitable for a fetch tool but lacks behavioral depth.
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 concise, front-loaded, and uses bullet points for clarity. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and output schema presence, the description covers returned fields well. Could mention potential performance impacts or data limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'username' parameter beyond the type. It fails to compensate for the missing schema documentation.
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 'Fetches a complete Codeforces profile in one call' and lists specific data, distinguishing it from siblings like compare_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a user profile but does not provide explicit guidance on when to use vs alternative tools or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the analysis and recommendation behavior, including the rating constraint (+300). However, with no annotations provided, it carries full burden. It lacks details on authentication needs, error handling (e.g., no solved problems), potential side effects (none expected), or output format. It is adequate but not fully transparent.
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?
Two sentences: first describes the core analysis, second specifies the output and constraint. No wasted words, front-loaded with purpose. Very concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple input schema (one param, no annotations) and an output schema (though not shown), the description is largely complete: it explains what the tool does, the input's role, and the output's nature. It does not address edge cases (e.g., no weak topics), but the existence of an output schema reduces that burden. Siblings provide context for alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single parameter 'username'. The description adds meaning by stating it analyzes 'a user's solved problems', clarifying that username identifies the user. However, it does not describe the username format, constraints, or validate input. It compensates partially, but more detail would improve.
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 specifies 'Analyzes a user's solved problems to identify their weakest topics' and 'Recommends up to 3 practice problems', providing a specific verb (analyze, recommend) and resource (user's problems, practice problems). It distinguishes from siblings like get_random_practice (random) and get_problemlist (list) by focusing on weak topics and a rating range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for identifying weak topics and getting focused practice, but does not explicitly state when to use this tool over alternatives (e.g., get_random_practice for random problems) or mention any prerequisites (e.g., user must have solved problems). No exclusions or when-not-to conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns problem statement, rating, and topics, which is behavioral. However, it does not mention potential errors or auth requirements, but this is acceptable for a read operation.
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?
Two sentences with no redundancy: first sentence states purpose, second sentence gives usage guidance with an example. Every word earns its place.
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 only 2 parameters, an output schema exists, and the description covers the tool's purpose and parameter usage completely. No obvious gaps for a simple fetch tool.
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 0%, but the description adds significant semantic value by explaining that contest_id and index uniquely identify a problem and provides an explicit example (contest_id=4, index='A').
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 fetches 'the full problem statement, rating, and topics for a specific Codeforces problem,' using a specific verb 'Fetch' and resource. It distinguishes from siblings like get_problemlist and get_random_practice by emphasizing specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool (provide contest ID and index with an example) but does not explicitly state when not to use it or contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses randomness, rating range, and ignoring weaknesses, but doesn't confirm read-only behavior or side effects.
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?
Two sentences, front-loaded with key behavior and use case, no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return details aren't needed. The description covers input and behavior, but lacks error handling or prerequisites (e.g., user must exist).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description implicitly defines 'username' as the user whose rating is used, adding meaning beyond the bare schema type string.
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 recommends a random Codeforces problem based on user rating, distinguishing it from siblings like get_practiceproblems (likely lists) and get_upsolve (targeted).
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?
Implies use for fresh challenges, but lacks explicit when-to-use or exclusions compared to alternatives. Context signals show siblings, but no direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explains that results are a list of up to 10 problems with specific fields, and details the filtering parameters. It does not mention rate limits or authentication, but for a read-like search, this is sufficient.
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 concise: a one-sentence overview followed by a bullet list of parameters. Every sentence is informative, and the structure makes it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and an output schema, the description covers all input parameters and describes the return format (10 problems with names, ratings, tags, links), making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It provides clear explanations for all 5 parameters with examples (e.g., 'min_rating: Minimum difficulty rating (e.g., 800)'), adding critical meaning absent from 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 starts with a specific action ('Search') and resource ('Codeforces problemset'), and specifies an output limit of 10 problems. It clearly distinguishes from siblings like get_practiceproblems or get_random_practice by focusing on filtered search.
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 clearly states what the tool does but does not explicitly guide when to use it over siblings. However, the purpose is specific enough that an agent can infer appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cf-mcp MCP server](https://glama.ai/mcp/servers/spr7a/cf-mcp/badges/card.svg)](https://glama.ai/mcp/servers/spr7a/cf-mcp)

Score Badge

Copy to your README.md:

[![cf-mcp MCP server](https://glama.ai/mcp/servers/spr7a/cf-mcp/badges/score.svg)](https://glama.ai/mcp/servers/spr7a/cf-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/spr7a/cf-mcp'

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