get_project_statusRetrieve read-only Git branch, HEAD, short status, and diff stats for a project to assess repository state without reading source files or session logs.
Read-only Git branch, HEAD, short status and diff stat for the project. Does not read source files or session logs.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path of the workspace/project root |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes the safety profile, and the description usefully confirms and extends it by specifying 'Read-only' and enumerating the exact refs/fields inspected. It also discloses negative behavior (no source file or session log reads), which is real added context, though it omits failure modes such as behavior when the path is not a Git repository.
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 short sentences with zero filler: the primary behavior and the exclusions are both front-loaded. Every clause carries information an agent needs.
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 compensates by enumerating the return content (branch, HEAD, short status, diff stat), which is sufficient for an agent to know what it gets back. What is missing is edge-case behavior such as a non-Git directory or a path that does not exist.
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?
There is a single parameter with 100% schema description coverage, so the schema already fully documents projectPath as an absolute path to the workspace root. The description adds no format, resolution, or edge-case detail beyond that, so the baseline 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 names the exact data it returns (Git branch, HEAD, short status, diff stat) and scopes it to the project, which is a specific verb+resource statement. It further delineates itself by stating what it does NOT cover ('Does not read source files or session logs'), so an agent can distinguish its remit from the handoff/task siblings without opening schemas.
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?
Usage is only implied: an agent infers it should call this when it needs repository state, and the negative scoping ('does not read source files or session logs') hints at when not to use it. However, no sibling tool is named as an alternative and no explicit when-to-use condition is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.