Skip to main content
Glama
Sign In
chatgpt-local-coding-agent

chatgpt-local-coding-agent

by everlastingQAQ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

workspace_diff

Read-onlyIdempotent

Get a redacted diff of managed files while listing Git-ignored runtime outputs without reviewing or applying them.

Instructions

Return a redacted managed-file diff; Git-ignored runtime outputs are listed but never reviewed or applied.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "workspace_diff"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive aspects. The description adds behavioral details such as redaction and that Git-ignored outputs are listed but not reviewed or applied, which goes beyond the annotations. It could be more specific about what 'redacted' entailed, but it's still informative.

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, concise sentence that conveys all essential information without redundancy. It is well-structured and direct.

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), the existing output schema, and comprehensive annotations, the description covers all required aspects. It explains the core functionality and key behaviors, making it complete for an agent to decide and invoke correctly.

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?

Since the tool has zero parameters, the schema fully covers them (100% coverage). Per the guidelines, when coverage is high, the baseline score is 3 even without parameter-specific descriptions. No additional parameter info is needed.

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 the tool returns a diff of managed files, and specifies the redaction and handling of Git-ignored outputs. This distinguishes it from sibling tools like workspace_apply (which applies changes) and workspace_status (which shows status).

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 by describing what the tool does and its limitations (lists but never applies Git-ignored outputs), but it does not explicitly contrast with alternatives or provide when-to-use scenarios. However, the conditions are reasonably clear from the context.

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

Deploy Server

Other Tools