Click on "Install 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-usage How much did my team spend this week?"
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.
Demo animation created with remotion-readme-kit
You manage a Cursor Enterprise team. You want to know who's spending what, which models are being used, and whether you're getting value from AI. Instead of logging into a dashboard, you ask your AI agent:
"How much did my team spend this week?"
"Who's using the most expensive models?"
"Give me a full usage report for the current billing cycle."
This MCP server plugin wraps the full Cursor Enterprise Admin and Analytics APIs, giving your agent the tools and knowledge to answer those questions directly. Works with Cursor, Claude Code, and any MCP-compatible client.
Part of the cursor-usage-tracker ecosystem. This plugin handles quick questions in the IDE. The tracker is the full open-source dashboard with charts, three-layer anomaly detection, Slack/email alerts, and incident lifecycle tracking. Use them together or separately.
Related MCP server: cursor-otel
Component | What it does |
MCP Server | 15 tools wrapping the full Cursor Enterprise Admin + Analytics API |
Skills | Data interpretation guide + cost optimization framework |
Rules | Always-on cost-awareness guidance for model selection |
Commands | Quick-access: |
Agent | Specialized usage analyst persona |
/add-plugin cursor-usageThen set your API key in Cursor settings:
Open Settings → MCP
Find cursor-usage and set CURSOR_API_KEY to your Cursor Enterprise Admin API key
/plugin install cursor-usageAdd to your MCP configuration:
{
"mcpServers": {
"cursor-usage": {
"command": "npx",
"args": ["-y", "cursor-usage-mcp"],
"env": {
"CURSOR_API_KEY": "your-api-key-here"
}
}
}
}Copy the skills/ directory into your project's .cursor/skills/ or .claude/skills/ folder. The skills work standalone as reference material even without the MCP server.
Go to your Cursor team settings (Settings → Team → API Keys)
Generate an Admin API key
For analytics endpoints, you may also need an Analytics API key
The API key gives read access to your team's usage data. The only write operation is set_spend_limit.
Tool | Description |
| List all team members with roles and status |
| Current billing cycle spend per member |
| Daily usage data: lines, requests, models, modes |
| Billing groups with member lists and spend |
| Per-request events with model, tokens, and costs |
| Set a hard spending limit for a user |
Tool | Description |
| Daily active users (includes CLI, cloud agent, Bugbot) |
| Model usage breakdown per day |
| Agent edit acceptance/rejection rates |
| Tab autocomplete effectiveness |
| MCP tool adoption |
| Top file types being edited with AI |
| Cursor version distribution |
| Command usage analytics |
| Plan mode adoption |
Tool | Description |
| One-call summary: members, spend, DAU, top models |
| Deep dive into a specific user's usage patterns |
Quick spend check:
You: "How much has my team spent this billing cycle?" Agent: calls get_team_overview → "Your team of 47 active members has spent $3,842 this cycle. Top spender is Alice at $412, followed by Bob at $287..."
User investigation:
You: "Why is Bob's spend so high?" Agent: calls get_user_deep_dive → "Bob has made 847 requests this week, 73% using claude-opus-4.5. His daily average is $41 vs the team median of $12. Switching his chat requests to Sonnet would save approximately $180/month..."
Model audit:
You: "/model-audit" Agent: calls get_model_usage + get_spending + get_agent_edits → "62% of your team's messages use Sonnet (good). However, 5 users account for 78% of all Opus usage. Their acceptance rate on Opus is 44% vs 51% on Sonnet, suggesting Opus isn't providing measurably better results for most of their tasks..."
This plugin answers quick questions in the IDE. For teams that need:
Historical trends over months (API is limited to 30 days)
Automated anomaly detection with statistical outlier detection
Slack/email alerts when spend spikes
Incident tracking with MTTD/MTTI/MTTR lifecycle
Web dashboard with charts and visualizations
See cursor-usage-tracker, the open-source Cursor Enterprise dashboard this plugin is part of.
# Install dependencies
npm install
# Run in development
npm run dev
# Build
npm run build
# Type check
npm run typecheck
# Run tests
npm test
# Validate plugin structure
npm run validateNode.js 20+
A Cursor Enterprise team with API access
Admin API key (and optionally Analytics API key)
Ofer Shapira
MIT © Ofer Shapira
Get agent edit metrics: suggested vs accepted vs rejected diffs and lines. Shows how effectively the team is using AI-generated code.
| Name | Required | Description | Default |
|---|---|---|---|
| users | No | Comma-separated emails to filter by specific users | |
| endDate | No | End date. Formats: "YYYY-MM-DD", "today", "yesterday". Default: "today" | |
| startDate | No | Start date. Formats: "YYYY-MM-DD", "7d", "30d", "today", "yesterday". Default: "30d" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'gets metrics' but does not explain aggregation level (per user or team), data freshness, whether it's read-only, or how date ranges interact. For a tool with 3 parameters, critical behaviors like default aggregation (e.g., last 30 days, all users) are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with a clear subject-action-result structure. It front-loads the key information (what metrics) and adds context (why it matters). It could be slightly tighter by removing redundancy (e.g., 'shows how effectively' is implied by 'metrics'), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should fully explain behavior and return values. It partially does for output (mentions diffs and lines) but lacks details on format (e.g., per user, totals), pagination, or error cases. Completeness is adequate for a simple metric tool but leaves notable gaps for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description (e.g., date formats, defaults). The description adds no extra meaning beyond the schema, so it meets the baseline of 3. It does not explain how parameters filter results or combine (e.g., users filter applies to all dates).
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 retrieves agent edit metrics (suggested, accepted, rejected diffs and lines) and explains its purpose (showing team effectiveness with AI-generated code). This verb-specific resource definition distinguishes it from sibling tools like get_usage_events or get_daily_usage, which focus on different metrics.
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 search or other get_* tools. It does not specify prerequisites, exclusions, or context like 'use this for aggregated metrics, use search for detailed breakdowns' – leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get billing groups with member lists, group-level spend, and daily spend breakdown. Also returns billing cycle dates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies a read-only operation but does not disclose authentication needs, rate limits, or behavior when data is empty. For a simple retrieval, it is adequate but not detailed.
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?
Two sentences, no redundant information. The purpose and content are front-loaded efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema or annotations, the description explains all returned data. It could mention authentication or data scope, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description's mention of returned data fulfills the baseline. With zero parameters, the description adds value by specifying what is returned.
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 retrieves billing groups with member lists, group-level spend, daily spend breakdown, and billing cycle dates. It uses specific verbs and resources, distinguishing it from sibling tools that focus on other entities.
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 (e.g., get_spending, get_daily_usage). The description does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Cursor client version distribution across the team: which versions are in use and what percentage of users are on each.
| Name | Required | Description | Default |
|---|---|---|---|
| users | No | Comma-separated emails to filter by specific users | |
| endDate | No | End date. Formats: "YYYY-MM-DD", "today", "yesterday". Default: "today" | |
| startDate | No | Start date. Formats: "YYYY-MM-DD", "7d", "30d", "today", "yesterday". Default: "30d" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates the tool returns version usage and percentages, which is fairly transparent for a read operation, but it does not disclose potential rate limits, data freshness, or whether the data is aggregated in real-time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the tool's core functionality without any extraneous words, demonstrating excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks detail about the output format (e.g., whether results are returned as a list, object, or with pagination) and does not explain how the time range parameters affect the distribution. Given no output schema, the description should provide more 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?
All three parameters have descriptions in the schema, achieving 100% coverage. The tool description adds no additional meaning beyond the schema, so it does not improve parameter understanding.
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 retrieves Cursor client version distribution across the team, including percentages. This distinguishes it from sibling tools that focus on other metrics like model usage or daily active users.
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 for team-level version distribution but does not explicitly provide guidance on when to use this versus alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get command usage analytics: which Cursor commands are being used and how often.
| Name | Required | Description | Default |
|---|---|---|---|
| users | No | Comma-separated emails to filter by specific users | |
| endDate | No | End date. Formats: "YYYY-MM-DD", "today", "yesterday". Default: "today" | |
| startDate | No | Start date. Formats: "YYYY-MM-DD", "7d", "30d", "today", "yesterday". Default: "30d" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Get', implying a read operation, but does not explicitly confirm non-destructiveness, mention authentication needs, or describe any side effects. The agent cannot infer safety or behavior beyond the vague verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. Every word earns its place; there is no redundancy or irrelevant 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?
With no output schema, the description should explain the response format. It vaguely mentions 'which commands are used and how often' but lacks specifics like data structure, aggregation level, or default behavior (e.g., date range defaults). The tool has optional parameters requiring default behavior clarification, which is missing.
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 provides 100% description coverage for all three parameters, so the schema itself is informative. The description adds no further meaning; it does not explain how filtering works or what the 'usage analytics' include. Given high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves command usage analytics, specifying the resource ('command usage') and the metrics ('which Cursor commands are being used and how often'). It distinguishes itself from more general analytics tools like get_daily_usage, but could be more explicit about its unique scope.
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_daily_usage or get_mcp_usage. There is no mention of prerequisites, typical use cases, or when not to use it. This leaves the agent without context to choose correctly among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get daily usage data per user: lines added/deleted, applies, accepts, rejects, tabs, requests by mode (composer/chat/agent), models used, and client versions.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| endDate | No | End date as Unix timestamp in milliseconds | |
| allPages | No | Fetch all pages automatically (default: false) | |
| pageSize | No | Results per page (default: 100) | |
| startDate | No | Start date as Unix timestamp in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as pagination behavior, rate limits, authentication requirements, or data freshness. It only states 'per user', which is a minimal behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence listing key data points, which is concise. However, it could be structured with bullet points for readability. Every word adds value, but the list is dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema. The description hints at the returned fields but does not specify the structure of the response (e.g., is it an array? are dates included?). Given the complexity, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description lists the data fields returned but does not add meaning beyond the parameter names and descriptions already in the schema. It does not explain parameter constraints or relationships.
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 uses a specific verb 'Get' and resource 'daily usage data per user', listing concrete metrics (lines, applies, accepts, etc.). It clearly distinguishes from siblings like get_dau (daily active users) by specifying per-user granularity and data types.
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 for retrieving daily usage data but provides no explicit guidance on when to use this tool vs alternatives (e.g., get_model_usage, get_usage_events). No when-not-to-use 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.
Get daily active users over time, including breakdowns for CLI, cloud agent, and Bugbot usage.
| Name | Required | Description | Default |
|---|---|---|---|
| users | No | Comma-separated emails to filter by specific users | |
| endDate | No | End date. Formats: "YYYY-MM-DD", "today", "yesterday". Default: "today" | |
| startDate | No | Start date. Formats: "YYYY-MM-DD", "7d", "30d", "today", "yesterday". Default: "30d" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does not disclose whether the call is read-only, destructive, requires authentication, or any other behavioral traits such as rate limits or data freshness. The mention of 'breakdowns' is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the core functionality without extraneous words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool with good schema coverage, but lacks details about the output format (e.g., time series, aggregated counts). Since there is no output schema, the description could be more explicit about what the breakdowns entail.
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 already provides 100% coverage for parameter descriptions. The tool description adds value by explaining the 'breakdowns' for CLI, cloud agent, and Bugbot, which are not explicit in the schema parameters, enhancing understanding of the data returned.
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 'daily active users over time', with specific breakdowns for CLI, cloud agent, and Bugbot usage. However, it does not differentiate from the sibling tool 'get_daily_usage', which may overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_daily_usage' or other get tools. The description implies it is for daily active users with breakdowns, but lacks context on scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top file extensions being edited with AI: which file types get the most AI suggestions, accepts, and rejects.
| Name | Required | Description | Default |
|---|---|---|---|
| users | No | Comma-separated emails to filter by specific users | |
| endDate | No | End date. Formats: "YYYY-MM-DD", "today", "yesterday". Default: "today" | |
| startDate | No | Start date. Formats: "YYYY-MM-DD", "7d", "30d", "today", "yesterday". Default: "30d" |
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 only states the purpose and does not mention if the tool is read-only, whether it requires authentication, rate limits, or pagination behavior. The agent cannot infer how the tool behaves beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely conveys the purpose. It is front-loaded with the core function. However, it could be slightly more efficient by removing the colon and second clause, but it remains clear and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 simple optional parameters and no output schema, the description is minimally adequate. However, it lacks any indication of the output format or structure, and no annotations provide further context. For a data retrieval tool, this is a gap that limits 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 input schema has 100% coverage with descriptions for all 3 parameters (users, endDate, startDate) including formats and defaults. The overall description adds no additional meaning beyond the schema. Therefore, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves top file extensions edited with AI, specifying the metrics (suggestions, accepts, rejects). The tool is distinct from its siblings, which cover other analytics like agent edits, billing, usage, etc. The verb 'get' and resource 'file extensions' are specific.
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. The description does not mention any prerequisites, contextual constraints, or exclusions. For example, it doesn't clarify that this only shows top extensions, not a full list, or that it might be limited to a certain scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get MCP (Model Context Protocol) tool usage: which MCP servers and tools are being used, and how often.
| Name | Required | Description | Default |
|---|---|---|---|
| users | No | Comma-separated emails to filter by specific users | |
| endDate | No | End date. Formats: "YYYY-MM-DD", "today", "yesterday". Default: "today" | |
| startDate | No | Start date. Formats: "YYYY-MM-DD", "7d", "30d", "today", "yesterday". Default: "30d" |
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 only states it retrieves usage data but does not mention read-only nature, side effects, authorization needs, or rate 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 sentence with the key action front-loaded. Very concise, but could be slightly more structured to include parameter context.
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?
While the description explains the output, it does not mention the available filter parameters (users, date range) nor provide any hint about the response structure, which is missing an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no parameter-specific information beyond what the schema already provides.
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 'MCP tool usage', specifying the exact information returned (which servers, tools, and frequency). This effectively distinguishes it from sibling tools like get_model_usage or get_daily_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?
The description provides no guidance on when to use this tool versus alternatives such as get_model_usage or get_daily_usage. There are no exclusions, contexts, or comparisons given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get model usage breakdown per day: which models are being used, how many messages, and by how many users. Essential for understanding model adoption and cost drivers.
| Name | Required | Description | Default |
|---|---|---|---|
| users | No | Comma-separated emails to filter by specific users | |
| endDate | No | End date. Formats: "YYYY-MM-DD", "today", "yesterday". Default: "today" | |
| startDate | No | Start date. Formats: "YYYY-MM-DD", "7d", "30d", "today", "yesterday". Default: "30d" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses the output breakdown but lacks details on rate limits, authentication, or side effects. No contradictions.
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?
Two sentences, front-loaded, no unnecessary words. Efficiently communicates purpose and value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 optional params and no output schema, the description covers the output sufficiently but could explicitly state the return format (e.g., array of objects).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra parameter meaning beyond what the schema already provides.
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 retrieves daily model usage breakdown, including models, messages, and users. It distinguishes from siblings like get_daily_usage and get_mcp_usage by specifying model focus.
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 use for understanding model adoption and cost drivers but does not provide explicit when-to-use/when-not-to-use guidance or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get plan mode adoption: which models are being used in plan mode and how often.
| Name | Required | Description | Default |
|---|---|---|---|
| users | No | Comma-separated emails to filter by specific users | |
| endDate | No | End date. Formats: "YYYY-MM-DD", "today", "yesterday". Default: "today" | |
| startDate | No | Start date. Formats: "YYYY-MM-DD", "7d", "30d", "today", "yesterday". Default: "30d" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's purpose but does not mention any behavioral traits such as read-only nature, required permissions, rate limits, or side effects. The description is minimal in this regard.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 13 words, directly stating the purpose without any fluff. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the return format. It only says 'which models are being used and how often' but does not specify the structure (e.g., list of objects, fields). With 3 parameters but no output details, the description is incomplete for a reporting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema provides for the parameters. It does not explain their use cases or format constraints beyond the schema's own descriptions.
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', the resource 'plan mode adoption', and specifies what information is returned: which models are used in plan mode and how often. This distinguishes it from siblings like get_model_usage, which likely covers all model usage, and get_daily_usage, which is broader.
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 vs alternatives. There are no prerequisites, limitations, or explicit context for when to prefer this over sibling tools like get_model_usage or get_daily_usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current billing cycle spending for all team members. Shows spend in dollars, included vs overage, fast premium requests, and spend limits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| allPages | No | Fetch all pages automatically (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not mention that the tool is read-only, any authentication requirements, rate limits, or side effects. The word 'Get' implies reading, but explicit statement is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first sentence states purpose, second lists output details. Every word adds value, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does and what data it returns, but given no output schema, it could provide more detail on the structure of the response. Also, with no annotations, it lacks behavioral 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?
Schema coverage is 100% with descriptions for both parameters (page, allPages). The tool description adds no additional meaning beyond the schema, so baseline score 3 applies.
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 uses a clear verb 'Get' and resource 'spending' (billing cycle). It specifies scope ('for all team members') and lists the types of data shown, distinguishing it from sibling tools like get_daily_usage or get_model_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?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it specify prerequisites or conditions. It simply states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tab autocomplete usage: suggestions shown vs accepted vs rejected, with line-level detail.
| Name | Required | Description | Default |
|---|---|---|---|
| users | No | Comma-separated emails to filter by specific users | |
| endDate | No | End date. Formats: "YYYY-MM-DD", "today", "yesterday". Default: "today" | |
| startDate | No | Start date. Formats: "YYYY-MM-DD", "7d", "30d", "today", "yesterday". Default: "30d" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the basic purpose and mentions 'line-level detail', but does not disclose behavioral traits like whether the data is aggregated, if sensitive information is exposed, or any authorization requirements. The term 'line-level' is ambiguous without further explanation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key action: 'Get tab autocomplete usage'. It is concise and avoids unnecessary words, but it omits important details, such as the meaning of 'line-level detail' and the structure of the response.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should compensate by explaining the return format. It mentions metrics but does not specify whether the result is a list of events, aggregated counts, or per-user breakdown. With 3 parameters and no annotations, the description is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters (users, startDate, endDate) with descriptions. The tool description adds no additional semantic value beyond what the schema provides, earning a baseline score of 3.
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 retrieves 'tab autocomplete usage' and specifies the metrics: suggestions shown, accepted, rejected. It also mentions 'line-level detail', distinguishing it from sibling tools like get_commands or get_mcp_usage, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool over alternatives, nor does it specify prerequisites or limitations such as date range constraints or user filtering behavior beyond what is in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all team members with their roles and status. Returns name, email, role, and whether they've been removed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool returns removed members (a behavioral trait), but omits information about read-only nature, pagination, rate limits, or authentication requirements. While better than a tautology, it leaves gaps.
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 exceptionally concise: two short sentences that convey the tool's core purpose and return values without any fluff. Every word earns its place.
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 low complexity (no params, simple list), the description is fairly complete. It states the output fields and that all members are included. However, it could mention whether results are paginated or limited, but this is a minor gap.
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 zero parameters, so the baseline is 4. The description adds no param-specific detail, but none is needed as the schema already covers 100% of (nonexistent) 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 lists team members with their roles and status, specifying the exact fields returned (name, email, role, removed status). This verb+resource combination is distinct from sibling tools like get_team_overview or get_user_deep_dive.
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. For example, it doesn't mention that get_team_overview might be better for summary stats, or that get_user_deep_dive would be for individual details. The agent must infer the context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive team overview: member count, total spend, top spenders, DAU, and most-used models. This is the best starting point for understanding your team's Cursor usage.
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | No | Analytics date range end (default: "today") | |
| startDate | No | Analytics date range start (default: "7d") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as read-only nature, required permissions, or any side effects. The name implies read-only, but the description should explicitly state safety characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the key info (what it returns) and then usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple overview with two optional parameters and no output schema, the description lists the five categories of data returned. It is mostly complete but could mention the output structure or any default date range behavior beyond '7d' and 'today'.
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%; both parameters (startDate, endDate) are described in the schema. The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'team overview', listing specific metrics (member count, spend, DAU, models). It distinguishes itself from sibling tools like get_dau or get_spending by positioning itself as a comprehensive starting point.
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 explicitly says 'This is the best starting point for understanding your team's Cursor usage', which provides clear context for when to use it. However, it does not mention when not to use it or suggest alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get granular per-request usage events with model, token counts, costs, and whether the request was chargeable. Supports filtering by user email and date range.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| No | Filter by user email | ||
| endDate | No | End date as Unix timestamp in milliseconds | |
| pageSize | No | Results per page (default: 500, max: 500) | |
| startDate | No | Start date as Unix timestamp in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the returned data (model, token counts, costs, chargeable) and filtering, but does not explicitly declare read-only nature, pagination behavior, or any side effects. The word 'Get' implies read but not explicitly.
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?
Two focused sentences: first defines the resource and data fields, second adds filtering options. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count (5) and schema descriptions, the description covers core purpose and filtering. It could mention pagination or ordering but schema provides page/pageSize defaults. Output format is not described but no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; each parameter has a description. The description adds context for email and date filtering but does not significantly enhance understanding of page or pageSize beyond schema defaults.
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 retrieves granular per-request usage events with specific data fields (model, token counts, costs, chargeability). This distinguishes it from sibling tools like get_daily_usage or get_model_usage that aggregate data differently.
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 mentions filtering by user email and date range, implying use cases. However, it does not explicitly state when to use this tool over siblings (e.g., daily vs per-request) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep dive into a specific user's usage: their spending, daily usage patterns, recent requests, and model preferences.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email to analyze | ||
| startDate | No | Analytics date range start (default: "7d") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It outlines the type of analysis (spending, patterns, requests, preferences) but does not clarify if it is read-only or if there are any restrictions. This 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by listing the areas covered. However, it does not provide structure for the return data. With two simple parameters, this is mostly complete but could be more detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both parameters. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'deep dive' into a specific user's usage, listing specific aspects like spending, daily patterns, recent requests, and model preferences. This distinguishes it from sibling tools that might cover aggregate data or different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like get_spending or get_daily_usage. It implies focus on a single user but lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a hard spending limit (in dollars) for a specific team member. Use with caution — this will block the user from making requests once the limit is reached.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email to set the limit for | ||
| limitDollars | Yes | Hard spending limit in dollars (0 to remove limit) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that setting a limit 'will block the user from making requests once the limit is reached', which is the key behavioral trait. It also hints at removal via the parameter description (0 to remove limit), but does not elaborate on side effects or reversibility beyond that.
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?
Two sentences with no waste: first sentence states the core purpose, second provides a critical warning. The structure is front-loaded and efficient.
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 missing important context: what the response is, whether the tool is idempotent, authentication requirements, and how it interacts with existing spending. The caution about blocking is good, but overall completeness is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with straightforward parameters. The description adds no new semantic information beyond what the schema provides (e.g., 'in dollars' is already in the schema). It restates the concept of a hard limit but does not clarify edge cases like what happens if limit is below current spend.
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 'set', the resource 'hard spending limit', and the target 'for a specific team member'. It distinguishes well from all sibling tools, which are read-only 'get_' operations, so the agent can easily tell this is a mutation tool.
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 includes a cautionary note about blocking users, which helps the agent understand when to exercise care. However, it does not explicitly state when to use this tool versus alternatives or provide conditions for use (e.g., admin privileges). Given siblings are all read-only, the context is clear but not fully explicit.
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. Dates show when Glama detected each change.
v0.1.2get_agent_editsget_billing_groupsget_client_versionsget_commandsget_daily_usageget_dauget_file_extensionsget_mcp_usageget_model_usageget_plansget_spendingget_tabsget_team_membersget_team_overviewget_usage_eventsget_user_deep_diveset_spend_limitMost tools have distinct purposes (e.g., get_agent_edits vs get_tabs vs get_model_usage). However, get_daily_usage and get_usage_events may overlap slightly, and get_spending/get_billing_groups both deal with costs, but descriptions clarify differences.
All tools follow a consistent get_noun pattern in snake_case (e.g., get_daily_usage, get_team_members). The only outlier is set_spend_limit which uses 'set', which is appropriate for a mutation.
17 tools is slightly high but well-justified for a comprehensive analytics server. Each tool covers a distinct metric, and the count is within reasonable bounds.
Covers most key areas: user activity, model usage, spending, team members, and even includes a mutation (set_spend_limit). However, lacks tools for inviting/removing team members or managing billing settings.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
MCP server for building and testing AI agents with multi-model experimentation and insights.
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ofershap/cursor-usage-plugin'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
