This MCP server monitors and manages Cursor Pro subscription usage limits across AI services (Sonnet 4.5, Gemini, and GPT-5).
Key capabilities:
Track usage statistics: Get real-time monitoring with current usage, remaining requests, percentages, and limits for individual services or total combined usage
Alert system: Check for services approaching or exceeding monthly limits to prevent interruptions
Subscription management: Switch between Pro (1,275 requests/month), Pro+ (3,825 requests/month), and Ultra (25,500 requests/month) tiers
Manual updates: Update request counts for testing or custom tracking scenarios
Subscription information: View current tier details and associated limits for all services
MCP compatibility: Works with any MCP-compatible client through standardized tools and TypeScript classes for programmatic integration
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., "@Cursor Pro Limits MCP Server show me my current usage stats for all services"
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 Model Context Protocol (MCP) server for monitoring Cursor Pro usage limits and API quotas. This server helps you track your daily usage across different AI services and stay within your Cursor Pro limits.
📊 Real-time Usage Monitoring: Track Sonnet 4.5, Gemini, and GPT-5 request usage
🚨 Alert System: Get warnings when approaching limits
📈 Usage Statistics: Detailed breakdown of current usage vs. limits
🔧 Easy Integration: Works with any MCP-compatible client
🎯 TypeScript: Fully typed with strict TypeScript configuration
Related MCP server: cursor-usage
Based on Cursor Pro subscription limits:
Sonnet 4.5: 225 requests/month
Gemini: 550 requests/month
GPT-5: 500 requests/month
Total: 1,275 requests/month
Sonnet 4.5: 675 requests/month
Gemini: 1,650 requests/month
GPT-5: 1,500 requests/month
Total: 3,825 requests/month
Sonnet 4.5: 4,500 requests/month
Gemini: 11,000 requests/month
GPT-5: 10,000 requests/month
Total: 25,500 requests/month
npm install cursor-pro-limits-mcpConfigure your MCP client to use this server:
{
"mcpServers": {
"cursor-pro-limits": {
"command": "npx",
"args": ["cursor-pro-limits-mcp"]
}
}
}Available Tools:
get_usage_statsGet comprehensive usage statistics for all services.
// Returns current usage, limits, percentages, and remaining requestsget_service_usageGet detailed usage for a specific service.
Parameters:
service: "sonnet45" | "gemini" | "gpt5" | "total"
check_alertsCheck for services approaching or exceeding limits.
update_usageUpdate usage statistics (for testing or manual updates).
Parameters:
sonnet45Requests (optional): Number of Sonnet 4.5 requests
geminiRequests (optional): Number of Gemini requests
gpt5Requests (optional): Number of GPT-5 requests
totalRequests (optional): Total number of requests
set_subscription_tierSet the subscription tier (pro, pro-plus, ultra).
Parameters:
tier: Subscription tier ("pro", "pro-plus", or "ultra")
get_subscription_infoGet current subscription tier and limits information.
import { CursorLimitsMonitor } from 'cursor-pro-limits-mcp';
// Create monitor for Pro tier (default)
const monitor = new CursorLimitsMonitor('pro');
// Get current usage stats
const stats = monitor.getUsageStats();
console.log(`Sonnet 4.5: ${stats.limits.sonnet45Requests}/${stats.quotas.maxSonnet45Requests}`);
// Check for alerts
const alerts = monitor.checkAlerts();
if (alerts.length > 0) {
console.log('Warning: Approaching limits!');
}
// Update usage (e.g., from API response)
monitor.updateLimits({
sonnet45Requests: 150,
geminiRequests: 300,
gpt5Requests: 200,
totalRequests: 650
});
// Switch to Pro+ tier for higher limits
monitor.updateTier('pro-plus');
console.log(`Switched to ${monitor.getCurrentTier()} tier`);Node.js 18.0.0 or higher
npm or yarn
# Clone the repository
git clone <repository-url>
cd cursor-pro-limits-mcp
# Install dependencies
npm install
# Build the project
npm run build# Build TypeScript
npm run build
# Watch mode for development
npm run dev
# Start the server
npm start
# Lint code
npm run lint
# Fix linting issues
npm run lint:fix
# Format code
npm run format
# Check formatting
npm run format:check
# Clean build directory
npm run cleanThis project uses:
TypeScript with strict configuration
ESLint for code linting
Prettier for code formatting
No any types - fully typed codebase
interface CursorProLimits {
sonnet45Requests: number;
geminiRequests: number;
gpt5Requests: number;
totalRequests: number;
lastUpdated: Date;
}
interface UsageStats {
limits: CursorProLimits;
quotas: CursorProQuotas;
usagePercentages: {
sonnet45: number;
gemini: number;
gpt5: number;
total: number;
};
remaining: {
sonnet45: number;
gemini: number;
gpt5: number;
total: number;
};
}CursorLimitsMonitorgetUsageStats(): Get comprehensive usage statistics
getServiceUsage(service): Get usage for specific service
checkAlerts(): Check for services approaching limits
updateLimits(limits): Update usage statistics
onUpdate(callback): Subscribe to usage updates
Fork the repository
Create a feature branch: git checkout -b feature/amazing-feature
Make your changes
Run tests and linting: npm run lint && npm run format:check
Commit your changes: git commit -m 'Add amazing feature'
Push to the branch: git push origin feature/amazing-feature
Open a Pull Request
MIT License - see LICENSE file for details.
For issues and questions:
Open an issue on GitHub
Check the documentation
Review the TypeScript types for API reference
Check for services approaching or exceeding limits
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Check') but doesn't describe what 'approaching or exceeding limits' means operationally, whether this is a read-only operation, what permissions are needed, or how results are returned. This leaves significant gaps for a tool that likely interacts with system limits.
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 directly states the tool's purpose without any wasted words. It is appropriately sized for a zero-parameter tool and front-loaded with the essential 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 zero-parameter tool with no output schema, the description is minimally adequate but lacks detail on what 'check' entails (e.g., returns alerts, thresholds, or just status). Given the sibling tools suggest a usage/limits context, more specificity about behavioral aspects would improve 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description appropriately doesn't add parameter details, maintaining focus on the tool's purpose without redundancy. Baseline 4 is correct for zero-parameter tools.
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's purpose with a specific verb ('Check') and resource ('services approaching or exceeding limits'), making it immediately understandable. It doesn't explicitly distinguish from siblings like 'get_service_usage' or 'get_usage_stats', but the focus on 'limits' provides some differentiation.
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 guidance is provided on when to use this tool versus alternatives like 'get_service_usage' or 'get_usage_stats'. The description implies usage for monitoring limit thresholds but doesn't specify prerequisites, frequency, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get usage statistics for a specific service
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | Service to check usage for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't clarify authentication needs, rate limits, error conditions, or what the statistics include (e.g., time range, metrics). This leaves significant gaps for a tool that likely returns data.
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 directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 annotations and no output schema, the description is incomplete for a tool that returns usage statistics. It doesn't explain what the statistics include (e.g., counts, dates, units), potential limitations, or how to interpret results, leaving the agent with insufficient context for effective use.
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 100% description coverage, with the 'service' parameter fully documented via its enum and description. The tool description adds no additional parameter information beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
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 'Get' and the resource 'usage statistics for a specific service', making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'get_usage_stats', which appears to be a similar usage-related tool, preventing a perfect score.
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 like 'get_usage_stats' or 'check_alerts'. It lacks context about prerequisites, timing, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current subscription tier and limits
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information ('Get'), implying a read-only operation, but doesn't mention potential side effects, authentication requirements, rate limits, or error handling. This leaves significant gaps in understanding how the tool behaves in practice.
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 directly states the tool's purpose without any unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly.
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 (0 parameters, no output schema, no annotations), the description is adequate as a basic read operation. However, it lacks details on return values (e.g., format of subscription info), error cases, or dependencies, which could be important for an AI agent to use it correctly in a broader context.
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 tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, as there are none to explain. A baseline score of 4 is appropriate since the schema fully covers the lack of 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?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('current subscription tier and limits'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_service_usage' or 'get_usage_stats', which might also retrieve subscription-related information.
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 like 'get_service_usage' or 'get_usage_stats'. It lacks context about prerequisites, such as whether authentication is needed, or exclusions, such as when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current Cursor Pro usage statistics and limits
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't mention any constraints like authentication requirements, rate limits, or whether the data is real-time or cached. This leaves significant gaps for a tool that likely accesses sensitive usage information.
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 directly states the tool's function without any fluff. It's front-loaded with the core action and resource, making it easy for an agent to parse quickly.
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 annotations and output schema, the description is incomplete. It doesn't specify what 'usage statistics and limits' include (e.g., API calls, storage, user counts) or the format of the response, which is critical for an agent to use this tool effectively in a context with sibling tools that might overlap.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is applied since the schema fully handles the parameter aspect.
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 'Get' and the resource 'current Cursor Pro usage statistics and limits', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_service_usage' or 'get_subscription_info', which likely provide related but different information.
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 like 'get_service_usage' or 'get_subscription_info'. It lacks context about what specific statistics or limits are included, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the subscription tier (pro, pro-plus, ultra)
| Name | Required | Description | Default |
|---|---|---|---|
| tier | Yes | Subscription tier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose if this is a mutation requiring admin rights, if it's reversible, what side effects occur, or error conditions. For a write operation with zero annotation coverage, this is insufficient.
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 with zero waste. It's front-loaded with the core action and includes all necessary tier values without unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on permissions, side effects, return values, or error handling. Given the complexity of changing subscription tiers, more context is needed for safe and effective use.
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 the parameter 'tier' fully documented in the schema including its enum values. The description adds no additional parameter semantics beyond restating the tier options, so it meets the baseline of 3 where the schema does the heavy lifting.
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 ('Set') and the resource ('subscription tier'), with specific tier values listed. It distinguishes from siblings like 'get_subscription_info' (read vs write) but doesn't explicitly differentiate from other write operations like 'update_usage'.
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 guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites, permissions needed, or when not to use it (e.g., vs 'update_usage'). It's a basic functional statement without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update usage statistics (for testing or manual updates)
| Name | Required | Description | Default |
|---|---|---|---|
| sonnet45Requests | No | Number of Sonnet 4.5 requests | |
| geminiRequests | No | Number of Gemini requests | |
| gpt5Requests | No | Number of GPT-5 requests | |
| totalRequests | No | Total number of requests |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks critical behavioral details. 'Update' implies mutation, but it doesn't disclose permissions needed, whether changes are reversible, rate limits, or what the response looks like. The testing/manual context hints at caution but is insufficient for a mutation tool.
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 with zero waste—every word contributes to purpose and context. It's appropriately sized and front-loaded with 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, response format, and error handling, leaving significant gaps for an agent to use it safely and effectively.
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 parameters are fully documented in the schema. The description adds no parameter-specific information beyond the general purpose, meeting the baseline for high schema coverage without adding extra value.
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 ('Update') and resource ('usage statistics'), and specifies the context ('for testing or manual updates'). It distinguishes from sibling tools like 'get_usage_stats' (read) and 'set_subscription_tier' (different resource). However, it doesn't explicitly contrast with all siblings like 'check_alerts'.
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 context ('for testing or manual updates'), suggesting this is not for routine operations. However, it doesn't provide explicit when-to-use rules, alternatives (e.g., vs. 'set_subscription_tier'), or prerequisites, leaving some ambiguity.
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.
check_alertsget_service_usageget_subscription_infoget_usage_statsset_subscription_tierupdate_usageScored across 6 tools
Most tools have distinct purposes, but 'get_usage_stats' and 'get_service_usage' could be confused as both retrieve usage data. The descriptions clarify that one is for overall Cursor Pro usage and the other for specific services, but the naming overlap might cause misselection. Other tools like 'check_alerts' and 'set_subscription_tier' are clearly unique.
All tools follow a consistent verb_noun pattern using snake_case, such as 'check_alerts', 'get_service_usage', and 'set_subscription_tier'. There are no deviations in naming conventions, making the set predictable and easy to parse for an agent.
With 6 tools, this server is well-scoped for managing Cursor Pro limits and subscriptions. Each tool serves a clear function, such as monitoring usage, checking alerts, and handling subscription tiers, without unnecessary bloat or missing essentials for the domain.
The toolset covers key aspects like monitoring usage, checking limits, and managing subscriptions, but lacks operations for historical data or detailed analytics. Minor gaps exist, such as no tool for listing all services or viewing past alerts, but agents can work around these with the provided tools.
Live status, API pricing and rate limits for ChatGPT, Claude, Gemini, Cursor and 42+ AI tools.
Live status and health checks for AI coding providers: Claude, Cursor, Copilot, Codex and more.
Real-time status for 75+ AI services (OpenAI, Anthropic, Cursor). No auth, CORS-enabled.
Cookieless dashboard aggregates for Claude and Cursor. No visitor hashes. Starter and Growth.
