BotKelp

Apply changes to repo

apply_changes_to_repo

Syncs a project's local clone with its base branch (pulling if it has fallen behind), applies file changes on a new branch, validates the build when the repo is a Node project, and opens a Pull Request for human review. The agent never pushes to the base branch directly. Requires the BotKelp account key that registered the project — fails for a project id you don't own, the same as for an unknown one.

Input Schema

TableJSON Schema

Name	Required	Description
`files`	Yes
`prBody`	Yes
`prTitle`	Yes
`projectId`	Yes
`reviewers`	No
`botKelpKey`	Yes	BotKelp account key (starts with "bk_live_"). Required.
`branchName`	Yes	Name for the new branch, e.g. agent/add-supabase-auth
`githubToken`	Yes	GitHub PAT with repo write access, used for the clone/push and the PR.
`commitMessage`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals that the tool never pushes to the base branch directly, that it opens a PR for human review, that it validates Node builds, and that it fails for unowned or unknown project IDs. This is strong transparency, though it doesn't cover every edge behavior such as what happens if validation fails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the main workflow in the first sentence and essential failure/auth behavior in the second. There is no filler or repetition. The first sentence is long due to the enumerated steps, but each clause adds necessary information.

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

Completeness3/5

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

The description gives a solid overview of the workflow, safety behavior, and authentication constraints, which is valuable given the absence of annotations and output schema. However, it leaves parameter-level detail underspecified, offers no return-value hints, and doesn't cover what happens on build failure or how extensive the file content expectations are. It is adequate but not fully complete for a complex tool.

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

Parameters2/5

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

Schema description coverage is only 33%, so the description must compensate for the six undocumented parameters. It only adds ownership semantics for the BotKelp key and project ID, while saying nothing meaningful about files, commitMessage, prTitle, prBody, reviewers, or githubToken. The parameter behavior it does mention is valuable but far too limited for a 9-parameter tool.

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 identifies the tool's core purpose: syncing a clone, applying file changes, validating builds, and opening a PR. It distinguishes the operation from any less-specific 'apply changes' notion by describing the exact workflow. No similar sibling tool competes for this behavior, so no additional differentiation is needed.

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?

The usage context is implied through the described workflow: use this tool to propose changes to a repository via a pull request. However, the description never explicitly states when to use this tool versus an alternative, nor does it provide exclusion criteria. The conditional details (pulling if behind, validating if Node) describe behavior, not usage guidance.

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

All BotKelp tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

Most tools target clearly distinct actions: search/check are read-only registry operations, generate/get/buy are different scaffold delivery modes, and create/list/apply/verify handle project lifecycle. The main ambiguity is between get_scaffold_template and buy_scaffold_template, which share the same repo-handoff behavior and differ only in payment/account requirements; the descriptions are detailed enough to tell them apart, but an agent could still pick the wrong one without reading carefully.

Naming Consistency5/5

Every tool follows a consistent verb_noun snake_case pattern: search_components, create_project, generate_scaffold, verify_scaffold, apply_changes_to_repo, and so on. The verbs are specific and the nouns map cleanly to the resources being acted on, making the toolset predictable.

Tool Count5/5

Nine tools is well-scoped for a scaffolding and component-registry service. Each tool covers a meaningful part of the workflow—discovery, generation, delivery, verification, project registration, and repository updates—without redundancy or excessive granularity.

Completeness4/5

The core domain is well covered: component discovery, update checking, scaffold generation in three delivery modes, build verification, project registration, and applying changes to a repo. Minor gaps exist—there is no project deletion/unregistration, no way to fetch a single project's details beyond list_projects, and no direct update action after check_component_updates reports newer versions—but agents can work around these without major dead ends.

Resources

Need Help?