Sora Commander

Overview Schema Source Related Servers Discussions Admin

git_snapshot

Reads branch, HEAD, upstream ahead/behind, porcelain status and recent commits from a Git repository to provide a quick snapshot without running repository hooks.

Instructions

Read branch, HEAD, upstream ahead/behind, porcelain v2 status and last 10 commits. No approval window; runs in client Host even in Broker mode. Fixed Git never runs repository hooks/filters or configured programs. Maximum 3 processes, 15 seconds each, 64 KiB per output; errors are sanitized, never auto-retry.

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": {
      "path": "<path>"
    },
    "name": "git_snapshot"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes	Absolute repository directory within configured read roots, including read: folders; top must also be allowed.
`include_untracked`	No	Return untracked names as well as their count; default false returns only the count.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.5Nov 10, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations present the description carries the full burden and does so thoroughly: no approval window, client-Host execution even in Broker mode, no repository hooks/filters or configured programs, 3-process / 15s / 64 KiB limits, sanitized errors and no auto-retry. These are exactly the operational traits an agent needs for a subprocess-spawning tool.

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?

Four dense sentences, front-loaded with what is read before the operational constraints. Nothing is repeated from the schema or annotations, and every clause carries information an agent would otherwise lack.

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?

An output schema exists, so return shape need not be explained, and the description covers scope, execution environment, resource limits, error handling, and safety (no hooks). Nothing an agent needs to invoke this correctly is missing.

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 both the path read-root constraint and include_untracked's count-vs-names behavior are already fully documented in the schema. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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?

States a specific verb (Read) and enumerates exactly what the snapshot contains: branch, HEAD, upstream ahead/behind, porcelain v2 status, and last 10 commits. This distinguishes it from the sibling git_log/git_diff tools by making the aggregate, bounded nature of the snapshot explicit.

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?

Usage is implied by the content list - an agent can infer this is the broad read-only repository overview - but the description never says when to prefer it over git_diff, git_log, or status, nor does it state any exclusions. No explicit alternative routing.

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