cursor-mcp

Cursor: get agent

cursor_get_agent

Read-onlyIdempotent

Retrieve a Cursor Cloud Agent's repositories, settings, web URL, and latest run ID by providing its agent ID for a complete status overview.

Instructions

Inspect one agent: repos, settings, web URL, and the id of its most recent run.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "agentId": "<agentId>"
    },
    "name": "cursor_get_agent"
  }
}

Input Schema

Name	Required	Description	Default
`agentId`	Yes	Agent id, in `bc-<uuid>` form.

Output Schema

Name	Required	Description	Default
`id`	Yes
`url`	Yes
`name`	No
`repos`	Yes
`status`	Yes
`followUp`	Yes
`metadata`	No
`environment`	No
`latestRunId`	No
`repoDetails`	Yes
`autoCreatePR`	No
`workOnCurrentBranch`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.0Sep 9, 2026

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context about what the inspection surfaces (repos, settings, web URL, recent run id) but discloses no additional behavioral traits such as error conditions, side effects, or prerequisites. It is consistent with annotations.

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, front-loaded sentence that states the verb, resource, and return fields without fluff. Every part earns its place, and there is no redundant or repetitive wording.

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 one parameter, a rich input schema description, full annotation coverage, and an output schema, this description is sufficient. An agent can correctly understand what the tool does, what input is required, what to expect in the return, and that it is safe to call.

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?

The input schema provides 100% documentation for the only parameter, agentId, including format ('bc-<uuid>') and constraints. The description adds no extra parameter meaning, so the baseline of 3 is appropriate since schema carries the full burden.

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 uses a specific verb ('Inspect'), a singular resource ('one agent'), and lists exactly what is returned: repos, settings, web URL, and most recent run id. This clearly differentiates it from sibling tools like cursor_list_agents, which enumerate multiple agents.

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 implies usage context: call this when you need detailed information about a specific agent, identified by agentId, rather than listing agents. It does not explicitly name cursor_list_agents or state when not to use it, but the singular phrasing provides clear contextual guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.