cursor-mcp

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct domain: cloud agents, documentation, help, inter-agent inbox, SDK guidance, and billing. No overlap in purpose, clear boundaries.
Naming Consistency5/5
All tools follow a consistent 'cursor_<noun>' pattern with lowercase snake_case, making them easily predictable and grouped.
Tool Count5/5
Six tools is well-scoped for the server's purpose, covering key Cursor ecosystem areas without being too sparse or bloated.
Completeness4/5
Covers cloud agent inspection, documentation, help, inbox messaging, SDK guidance, and billing. Minor gap: cloud agent management lacks create/delete, but this is likely intentional.
Average 4.2/5 across 6 of 6 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on June 7, 2026
- 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?
With no annotations, the description carries full burden but only states the basic functionality. It does not disclose side effects, read-only nature, authorization needs, or any behavioral traits beyond returning snippets.
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 very concise at one sentence, efficiently communicating the tool's purpose. It is front-loaded and easy to parse, though it could be slightly more informative.
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's simplicity (single required parameter, output schema present), the description is minimally adequate but does not leverage existing context or mention output characteristics, leaving some gaps.
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 description coverage is 100% as the parameter 'topic' is described with 'Doc topic key.' and an enum list. The description adds no additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it returns fleet-curated Cursor documentation snippets, which is a clear verb+resource combination. It distinguishes itself from sibling tools like cursor_help and cursor_sdk by focusing on curated snippets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as cursor_help or cursor_sdk. The description does not mention context, prerequisites, or disclaimers.
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 must disclose behavioral traits. It notes 'cancel is gated', indicating limited availability. However, it does not describe behaviors for status, runs, or error states, nor any authentication or rate limits. The output schema exists but is not referenced.
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?
Extremely concise: two sentences with no filler. The first sentence states purpose and key caveat, the second reinforces usage. Every word 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 moderate complexity (4 parameters, output schema exists), the description covers the primary use case and a critical limitation (cancel gated). It could detail other operations (status, runs) but the schema provides parameter docs. Slightly improved with more behavioral context.
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 description coverage is 100%, so the schema already documents all parameters. The description adds no parameter-specific meaning beyond 'list and inspect'. Baseline at 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List and inspect Cursor cloud agents', providing a clear verb and resource. It distinguishes from sibling tools (cursor_docs, cursor_help, etc.) by focusing on cloud agents. The mention of 'read-first' and 'cancel is gated' further clarifies scope.
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 advises 'list often' to monitor runaway spend, implying proactive monitoring. It also warns that cancel is restricted. However, it does not explicitly state when not to use alternatives like status or runs, though sibling tools are distinct.
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 were provided, so the description must carry the behavioral burden. It declares the tool as 'read-only', which is correct and important. However, it does not disclose potential behaviors like error handling, rate limits, or scope of operations beyond the parameter descriptions.
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 concise sentences, front-loaded with purpose and read-only nature, plus authentication and usage advice. No unnecessary words.
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 tool's simplicity (3 parameters, 1 required, output schema exists), the description covers purpose, auth, and usage. It could be improved by briefly explaining the operations, but the parameter schema compensates.
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 100%, so the description does not need to redefine semantics. The description adds a usage hint for 'alert_check' but otherwise does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cursor billing and spend guardrails (read-only)', which identifies the resource and action. It distinguishes from sibling tools (cursor_cloud, cursor_docs, etc.) which cover different domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides prerequisites (CURSOR_API_KEY) and a usage pattern ('Use alert_check on a schedule...'). It does not explicitly state when not to use the tool, but the guidance is clear and actionable.
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?
No annotations are provided, so the description carries full burden. While 'List' implies a non-destructive read operation, the description could explicitly state that it is read-only or has no side effects. However, given the simple nature of a help command, the transparency is adequate.
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 a single sentence, front-loaded with the action and resource. Every word earns its place. It is perfectly concise with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no annotations, an output schema exists), the description completely covers its purpose. It tells the agent exactly what the tool does: list tools and setup. Nothing more is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The input schema is empty and fully covered (100%). The description adds no parameter info because none are needed. This is appropriate.
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 'List cursor-mcp tools and setup.' uses a specific verb ('List') and clearly identifies the resource ('cursor-mcp tools and setup'). It effectively distinguishes from sibling tools (like cursor_cloud, cursor_docs) which are specific tools, while this is a general overview tool.
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 when an agent needs an overview of available tools and setup, but it does not explicitly state when to use this tool versus alternatives (e.g., when you need documentation of a specific tool). No exclusion criteria or alternative suggestions 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?
No annotations are provided, so the description carries full burden. It explicitly states 'read-only, no agent spawn', clearly disclosing its behavioral safety. It also mentions 'Fleet-curated', indicating curation by a specific team. For a guidance tool, this level of transparency is sufficient and adds trust.
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 extremely concise: two sentences. The first sentence immediately states the tool's nature and key attributes (read-only, no agent spawn). The second sentence adds fresh context about the SDK release and usage. No redundant or vague text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations), the description covers all essential aspects: what it does, its safety, when to use it, and what content it provides. It also relates to sibling tools via 'complements cursor_docs topics'. The presence of an output schema (though not shown) further reduces the need to describe return values.
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 100% and the single parameter 'operation' is fully described in the schema with enum values and descriptions. The tool description adds extra context by listing specific topics like 'custom tools, auto-review, JSONL stores, nested subagents', which gives meaning to what guidance is available beyond the enum names.
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 provides 'Fleet-curated @cursor/sdk / cursor-sdk guidance', establishes itself as a read-only SDK reference, and distinguishes from sibling 'cursor_docs' by saying it complements rather than duplicates. Specific SDK release features are listed, giving concrete purpose.
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 explicitly advises 'Use before writing new headless automation' and notes that it 'complements cursor_docs topics', giving a clear use case and hinting at when to prefer cursor_docs instead. It does not explicitly list all alternatives but the context indicates this is the SDK-specific guidance tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: no network, pure filesystem, default directory ~/.cursor-mcp/inbox/, and the polling/read/ack cycle. It covers operational aspects like setting `CURSOR_INBOX_DIR` and purging old messages.
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?
Every sentence is purposeful: the first sentence states the purpose, then a summary of operations, a typical flow bullet list, and implementation details. No wasted words, front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, multiple operations, no annotations, output schema exists), the description covers setup, usage patterns, and operational boundaries. It explains when each operation is appropriate and the technical environment, leaving no major gaps.
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?
All 11 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds value by explaining the flow (e.g., using `msg_id` for read/ack, `older_than_days` for purge) and the purpose of `tags` and `payload`, but the schema already defines these well.
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 identifies the tool as an 'Inter-agent message drop for Cursor agents' and lists the specific operations (post, list, read, ack, purge). It distinguishes from sibling tools which cover cloud, docs, help, SDK, and usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a typical usage flow, specifying when to call each operation (e.g., 'post' for heads-up, 'list' at task start, 'read' for detail, 'ack' when handled, 'purge' for cleanup). It explains the context (filesystem-based, no daemon) and the environment variable override.
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:

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

Score Badge

Copy to your README.md:

[![cursor-mcp MCP server](https://glama.ai/mcp/servers/sandraschi/cursor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sandraschi/cursor-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/sandraschi/cursor-mcp'

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