Skip to main content
Glama
ariekogan

ateam-mcp

by ariekogan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

ateam_github_patch

Edit files in a GitHub repository and commit changes. Supports full file replacement or surgical search/replace edits. Defaults to dev branch; use main only for hotfixes.

Instructions

Edit a file in the solution's GitHub repo and commit. Two modes:

  1. FULL FILE: provide content — replaces entire file (good for new files or small files)

  2. SEARCH/REPLACE: provide search + replace — surgical edit without sending full file (preferred for large files like server.js) Always use search/replace for large files (>5KB). Always read the file first with ateam_github_read to get the exact text to search for.

DEFAULTS TO dev BRANCH — writes don't touch prod. Use ateam_github_promote to ship dev→main when ready. Pass ref:'main' only for emergency hotfixes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
solution_idYesThe solution ID
pathYesFile path to create/update (e.g. 'connectors/home-assistant-mcp/server.js')
contentNoThe full file content to write (mode 1 — full file replacement)
searchNoExact text to find in the file (mode 2 — search/replace). Must match exactly including whitespace.
replaceNoText to replace the search string with (mode 2 — required with search)
messageNoOptional commit message (default: 'Update <path>')
refNoTarget branch. Default: 'dev' (safe — won't touch prod). Use 'main' only for emergency hotfixes.dev

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.52

TDQS

A4.6/5.0
Behavior4/5

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

Without annotations, the description carries the full burden. It explains the two modes, default branch, and the need for exact text in search. It could mention required permissions or what a commit returns, but overall it is transparent about the tool's behavior.

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 concise yet comprehensive, using bullet points for clarity. Every sentence adds value: modes, best practices, branch safety, and alternatives. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers modes, branch safety, prerequisites, and sibling differentiation. Missing output details (e.g., commit info), but there is no output schema. For a mutation tool, a note on what is returned would be helpful, but the description is still quite complete.

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

Parameters4/5

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

The input schema already describes each parameter (100% coverage), so baseline is 3. The description adds value by explaining the two modes and when to use content vs search+replace, providing context beyond the schema's individual descriptions.

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 edits a file in a GitHub repo and commits, with two modes (full file and search/replace). It distinguishes itself from sibling tools like ateam_github_read (which reads) and ateam_github_promote (which promotes branches).

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?

Provides explicit guidance: use search/replace for large files >5KB, always read the file first with ateam_github_read, defaults to dev branch, use ateam_github_promote to ship to main, and pass ref='main' only for emergency hotfixes. This helps the agent choose the correct mode and avoid mistakes.

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