SassyMCP

Official

Overview Schema Source Related Servers Discussions Admin

sassy_ghq_push

Destructive

Create or update multiple files in a single atomic GitHub commit with the Git Data API, avoiding SHA/ETag conflicts. Requires owner, repo, branch, commit message, and file array.

Instructions

Mutating: creates or updates multiple files in one atomic commit via the Git Data API, avoiding the SHA/ETag problems of single-file writes. Required: owner, repo, branch (must be the target branch name, e.g. main or a feature branch), message (commit message), files as a JSON string: an array of {path, content} objects. Malformed files JSON returns an error instead of pushing. Each file write overwrites the existing content at that path, so get the current content with sassy_ghq_get first when editing existing files. Requires a GitHub token (GITHUB_TOKEN or GITHUB_PERSONAL_ACCESS_TOKEN). For single-file operations, branches, or repos the github_full tool sassy_gh_push_files is the fuller equivalent.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`repo`	Yes
`files`	Yes
`owner`	Yes
`branch`	Yes
`message`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Jul 31, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already mark the tool as destructive and non-idempotent. The description adds context consistent with those hints: atomic commit, overwriting of file contents, error on malformed JSON, and the requirement of a GitHub token. This goes well beyond the annotation data and prepares the agent for side effects.

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?

Every sentence adds value: core purpose, required parameters, format notes, error behavior, overwrite warning, auth requirement, and an alternative tool. The description is front-loaded with the most important information and stays focused without verbosity.

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?

For a mutating tool with no parameter descriptions and a destructive annotation, this description covers purpose, usage, side effects, authentication, and alternatives. The output schema exists to handle return values, so nothing critical is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain all parameters. It does so comprehensively: branch must be the target branch name (with examples), message is the commit message, and files must be a JSON string array of {path, content} objects. This adds meaning the schema cannot convey.

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 a specific verb and resource: 'creates or updates multiple files in one atomic commit via the Git Data API'. It also explains the benefit of avoiding SHA/ETag problems, and explicitly differentiates from a single-file equivalent, making it easy for an agent to distinguish this tool from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided: when editing existing files, the agent should first get content with sassy_ghq_get; for single-file operations, branches, or repos, the tool sassy_gh_push_files is named as the fuller alternative. This gives clear when-to-use and 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.

Deploy Server