How do I use cursor-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cursor-mcp check my spend summary" 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.

cursor-mcp

by sandraschi

Overview Schema Related Servers Score Discussions

Python

Remote

cursor-mcp

FastMCP 3.2 server for Cursor platform APIs — spend guardrails, cloud agent monitoring, and inter-agent inbox.

Complements cursor-app-control (IDE/Glass). Does not replace it.

Port	Role
11000	HTTP `/mcp` (Fritz `fleet_bridge`)
stdio	Cursor `mcp.json` / Claude Desktop

MCD: CHANGELOG_DIGEST_JUN_2026.md · CURSOR_MCP_PROPOSAL.md

Quick start

cd D:\Dev\repos\cursor-mcp
Copy-Item .env.example .env
# Edit .env — set CURSOR_API_KEY (and CURSOR_ADMIN_API_KEY for full spend API)

uv sync
.\start.ps1 -Serve

Cursor `mcp.json`

{
  "mcpServers": {
    "cursor-mcp": {
      "command": "D:\\Dev\\repos\\cursor-mcp\\.venv\\Scripts\\python.exe",
      "args": ["-m", "cursor_mcp", "--stdio"],
      "env": {
        "CURSOR_API_KEY": "cursor_...",
        "CURSOR_ADMIN_API_KEY": "crsr_..."
      }
    }
  }
}

Related MCP server: cursor-otel

Tools

`cursor_usage`

Operation	Purpose
`alert_check`	Main guardrail — hourly spend, on-demand, running cloud agents, cache delta
`summary`	One-shot dashboard replacement
`spend`	Admin API `/teams/spend` row
`events`	Last N hours usage events (sum `chargedCents`)
`limits`	Show configured thresholds
`me`	API key identity

`cursor_cloud`

Operation	Purpose
`list`	All cloud agents — spot runaway parallelism
`status`	Single agent
`runs`	Runs for agent
`cancel`	Cancel a run (use sparingly)

`cursor_inbox`

Structured message drop for Cursor agents. Any process posts; agent polls at task start.

Operation	Purpose
`post`	Drop a message (subject, body, priority, tags, optional payload dict)
`list`	Poll unread — call at agent task start
`read`	Full message by id
`ack`	Acknowledge (moves to `inbox/acked/`)
`ack_all`	Acknowledge all unread
`purge`	Delete acked messages older than N days

Drop dir: CURSOR_INBOX_DIR env (default ~/.cursor-mcp/inbox/). No daemon, no network — pure JSON files.

Who can write:

Claude Desktop: cursor_inbox post (add cursor-mcp to Claude Desktop MCP config)
meta_mcp / any fleet server: direct JSON file drop to CURSOR_INBOX_DIR
PowerShell / Python scripts: same
Sandra: cursor_inbox post from any MCP client

Cursor agent convention: add cursor_inbox list to AGENTS.md or Cursor rules so agents check for messages at the start of every session.

`cursor_docs`

Fleet snippets. Topics: cloud-agents, profiles, mcp-config, spend-guardrails, cursor-mcp, cursor-inbox, sdk-jun-2026, design-mode, auto-review, context-canvas, changelog-jun-2026.

`cursor_sdk`

Read-only SDK guidance (no agent spawn): capabilities, upgrade_notes, autoreview_template, custom_tools_guide, store_options.

Starter permissions: docs/permissions.fleet.example.json

`cursor_help`

Tool index and setup. Always current.

Auth notes

Key	Endpoints
`CURSOR_API_KEY`	`/v1/me`, `/v1/agents/*`
`CURSOR_ADMIN_API_KEY`	`/teams/spend`, `/teams/filtered-usage-events`

Individual Pro without Admin API: alert_check still works via cloud agent count + cache; spend/events show partial_errors until you add a team admin key.

Poll at most every 1–2 hours — Admin API aggregates hourly.

Env

Variable	Default	Purpose
`CURSOR_API_KEY`	—	User key, required
`CURSOR_ADMIN_API_KEY`	—	Team admin key, optional
`CURSOR_MCP_HOST`	`127.0.0.1`	HTTP bind
`CURSOR_MCP_PORT`	`11000`	HTTP port
`CURSOR_INBOX_DIR`	`~/.cursor-mcp/inbox/`	Message drop dir
`CURSOR_HOURLY_SPEND_WARN_CENTS`	`300`	~$3/h warn
`CURSOR_ON_DEMAND_WARN_CENTS`	`2000`	~$20 on-demand warn
`CURSOR_RUNNING_AGENTS_WARN`	`3`	Parallel agents warn
`CURSOR_USAGE_EMAIL`	—	Filter spend by email

Copy .env.example. Never commit real keys.

Fritz task

Scheduled coworker_cursor_spend_watch — every 2 hours, emails on warn or critical.

See docs/FRITZ_INTEGRATION.md.

MCPB (Claude Desktop)

uv sync
just mcpb-pack
# → dist/cursor-mcp-v0.2.0.mcpb — drag into Claude Desktop Extensions

Requires uv on PATH. Set CURSOR_API_KEY / CURSOR_ADMIN_API_KEY in the extension env.

Changelog

See CHANGELOG.md. Current: v0.2.0 (2026-06-07) — cursor_inbox + MCPB packaging.

Available Tools

6 tools

cursor_cloudA

List and inspect Cursor cloud agents (read-first; cancel is gated).

Runaway spend often correlates with many parallel cloud agents — list often.

ParametersJSON Schema

Name	Required	Description
`operation`	Yes	Cloud agent operation.
`agent_id`	No	Agent id (bc-...). Required for status/cancel/runs.
`run_id`	No	Run id for cancel.
`limit`	No	Page size for list/runs.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

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.

cursor_docsB

Return fleet-curated Cursor documentation snippets.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	Doc topic key.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

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.

cursor_helpA

List cursor-mcp tools and setup.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

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.

cursor_inboxA

Inter-agent message drop for Cursor agents.

Any process writes a message to the shared inbox dir (CURSOR_INBOX_DIR). The Cursor agent calls cursor_inbox to poll, read, and acknowledge.

Typical flow:

Claude Desktop / meta_mcp / a script calls 'post' to leave a heads-up.
Cursor agent calls 'list' at task start to check for waiting messages.
Cursor agent calls 'read' for detail, then 'ack' when handled.
Periodic 'purge' to clean old acked messages.

No daemon, no network — pure filesystem. Default dir: ~/.cursor-mcp/inbox/ Override with CURSOR_INBOX_DIR env var.

ParametersJSON Schema

Name	Required	Description	Default
`operation`	Yes	Inbox operation.
`sender`	No	Sender identity (e.g. 'claude-desktop', 'meta_mcp', 'sandra').	unknown
`subject`	No	One-line subject.
`body`	No	Message body — plain text or markdown.
`priority`	No	Message priority.	normal
`tags`	No	Optional tags e.g. ['meta_mcp', 'cold-install', 'heads-up'].
`payload`	No	Optional structured data attached to the message.
`msg_id`	No	Message id for read/ack.
`include_acked`	No	Include acknowledged messages in list.
`limit`	No	Max messages to return.
`older_than_days`	No	Purge acked messages older than N days.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.9/5.0

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.

cursor_sdkA

Fleet-curated @cursor/sdk / cursor-sdk guidance (read-only, no agent spawn).

Jun 2026 SDK release: custom tools, auto-review, JSONL stores, nested subagents. Use before writing new headless automation — complements cursor_docs topics.

ParametersJSON Schema

Name	Required	Description	Default
`operation`	Yes	SDK guidance operation.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

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.

cursor_usageA

Cursor billing and spend guardrails (read-only).

Requires CURSOR_API_KEY. Admin endpoints also accept CURSOR_ADMIN_API_KEY (crsr_ team key). Use alert_check on a schedule (e.g. Fritz every 2h) instead of manual dashboard checks.

ParametersJSON Schema

Name	Required	Description
`operation`	Yes	Usage operation to run.
`hours`	No	Lookback window for events/alert_check.
`email`	No	Filter spend row by email (Admin API).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.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.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

modern-treasury A
io.usefulapi
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
Finance Payments & Billing
172
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
codat A
io.usefulapi
MCP server for Codat — companies, connections, invoices, bills and financial statements.
Finance ERP Systems Data Platforms
282
ably A
io.usefulapi
MCP server for Ably — channel history, presence, occupancy, stats, publish, and app management.
Communication Developer Tools
152

Related MCP Servers

Slack MCP Server
teresjsiu
-
license
Not graded
quality
Not graded
maintenance
A FastMCP-based server that provides complete Slack integration for Cursor IDE, allowing users to interact with Slack API features using natural language.
Updated a year ago (2025-05-29 13:40 UTC)
cursor-otel
smith
A
license
Not graded
quality
D
maintenance
An MCP server that instruments Cursor AI agent interactions with OpenTelemetry traces and logs to monitor agent turns and performance. It enables tracking of user queries, assistant responses, and tool usage through GenAI-compliant telemetry spans.
Updated 6 months ago (2026-03-05 00:22 UTC)
MIT
mnemos
Knowledge & Memory Search AI & Machine Learning
ncz-os
A
license
Not graded
quality
B
maintenance
MCP server providing persistent memory, semantic search, versioned storage, webhook fanout, and unified LLM routing for AI agents via FastAPI runtime with multiple backend options.
Updated 5 days ago (2026-08-29 15:25 UTC)
31
Apache 2.0
cursor-usage
Monitoring Observability Finance
ofershap
A
license
A
quality
D
maintenance
MCP server that wraps Cursor Enterprise API to enable AI agents to answer questions about team spending, usage, and model adoption.
Updated 6 months ago (2026-02-20 08:21 UTC)
17
42
2
MIT

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

cursor-mcp

Quick start

Cursor mcp.json

Tools

cursor_usage

cursor_cloud

cursor_inbox

cursor_docs

cursor_sdk

cursor_help

Auth notes

Env

Fritz task

MCPB (Claude Desktop)

Changelog

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Cursor `mcp.json`

`cursor_usage`

`cursor_cloud`

`cursor_inbox`

`cursor_docs`

`cursor_sdk`

`cursor_help`