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.

Changed2 schema fields changedSep 7, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / files / items / additionalProperties
```
Removed value: -false
```
First observedSep 6, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Discloses important behaviors: pulls if behind, works on a new branch, skips build for non-Node, never pushes to base, and fails for unowned projects. No annotations, so description carries this fully.

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?

Concise yet comprehensive single description with a clear second sentence for the base-branch constraint.

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?

Covers behavioral edge cases and prerequisites, but does not mention return value or success output since no output schema is provided.

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?

Adds meaning for botKelpKey and projectId through context, but does not cover the other six parameters beyond their schema 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?

Clearly describes a multi-step operation: syncs, applies changes, validates build for Node, opens PR, and never pushes to base. Distinct from sibling scaffolding tools.

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?

Provides context on conditions (Node validation, ownership requirement) but no explicit guidance on when to use versus alternatives beyond that.

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

Disambiguation5/5

Each tool has a clearly distinct purpose (e.g., apply vs. generate vs. verify vs. search), and the detailed descriptions remove ambiguity even for similar actions like generating, getting, and buying a scaffold.

Naming Consistency5/5

All tool names follow a consistent verb_object or verb_phrase pattern (e.g., create_project, search_components, verify_scaffold), making the API predictable and easy to navigate.

Tool Count5/5

With 11 tools, the set is well-scoped for a scaffold management service—covering project creation, component resolution, scaffold generation/retrieval/purchase, verification, updates, and issue reporting without feeling bloated or sparse.

Completeness4/5

The surface covers the core lifecycle (create, generate, apply, verify, update, report) well, but lacks explicit project deletion or update operations, which are common but not strictly required for the stated purpose.

Resources

Need Help?