Skip to main content
Glama
thyn-ai

Algenta MCP

Official
by thyn-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

apply_repository

Destructive

Materialize a simulated repository plan as a diff, local commit, or pull request to implement the approved changes.

Instructions

Materialize a simulated repository decision in one of three modes. patch_only just returns the validated patch diff with applied=false and writes nothing. local_branch commits the patch to a new branch (default algenta/) in the engine-side checkout and returns commit_sha and local_checkout_path. remote_pr additionally pushes the branch and opens a pull request, returning pull_request_url. Both write modes are hard-gated: the simulation must satisfy policy thresholds (otherwise repository_apply_gate_failed) and write_permission=true must be passed explicitly (otherwise repository_write_permission_required). Use patch_only to review the diff before writing anything, and run_repository_fix to chain the whole flow. Requires decision_plan_id and simulation_id from simulate_repository.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYespatch_only returns the diff; local_branch commits it; remote_pr pushes and opens a PR.
base_branchNoBranch the patch applies onto and the PR targets; defaults to the connector's default branch.
branch_nameNoBranch to create; defaults to algenta/<plan-suffix>.
snapshot_idNoSnapshot id; resolved from the decision plan when omitted.
repository_idYesSaved repository connector id from list_connectors.
simulation_idYesSimulation id from simulate_repository.
commit_messageNoCommit message; a default naming the plan id is used otherwise.
decision_plan_idYesPlan id from create_repository_decision_plan.
write_permissionNoMust be true for local_branch and remote_pr; ignored for patch_only.
pull_request_bodyNoPR body for remote_pr mode.
pull_request_titleNoPR title for remote_pr mode.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.1.3
    • addedInput schema / properties / base_branch / description
      Added value: +"Branch the patch applies onto and the PR targets; defaults to the connector's default branch."
    • addedInput schema / properties / branch_name / description
      Added value: +"Branch to create; defaults to algenta/<plan-suffix>."
    • addedInput schema / properties / commit_message / description
      Added value: +"Commit message; a default naming the plan id is used otherwise."
    • addedInput schema / properties / decision_plan_id / description
      Added value: +"Plan id from create_repository_decision_plan."
    • addedInput schema / properties / mode / description
      Added value: +"patch_only returns the diff; local_branch commits it; remote_pr pushes and opens a PR."
    • addedInput schema / properties / pull_request_body / description
      Added value: +"PR body for remote_pr mode."
    • addedInput schema / properties / pull_request_title / description
      Added value: +"PR title for remote_pr mode."
    • addedInput schema / properties / repository_id / description
      Added value: +"Saved repository connector id from list_connectors."
    • addedInput schema / properties / simulation_id / description
      Added value: +"Simulation id from simulate_repository."
    • addedInput schema / properties / snapshot_id / description
      Added value: +"Snapshot id; resolved from the decision plan when omitted."
    • addedInput schema / properties / write_permission / description
      Added value: +"Must be true for local_branch and remote_pr; ignored for patch_only."
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses the hard gates (policy thresholds triggering repository_apply_gate_failed, explicit write_permission=true otherwise repository_write_permission_required) and side effects per mode (writes nothing, commits to engine-side checkout, pushes and opens a PR). This meaningfully exceeds the destructiveHint annotation and covers failure behavior an agent must know before calling.

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 carries operational value: modes, outputs, gates, guidance, prerequisites. Information is front-loaded with the core verb and mode overview, and there is no filler or repetition of schema descriptions beyond what is operationally relevant.

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?

Given 11 parametersications, no output schema, and three modes, the description provides expected return values per mode, failure codes, defaults, and dependencies, all of which an agent needs to call and interpret results. The schema fills in parameter formats, so nothing critical is missing.

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?

Schema coverage is 100%, so the baseline is 3 and the description does not need to re-document parameters. It adds useful meaning by clarifying that write_permission is ignored in patch_only, that decision_plan_id and simulation_id come from simulate_repository, and by restating mode-dependent defaults already in the schema.

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?

Opening with "Materialize a simulated repository decision" provides a specific verb and resource, then enumerates the three modes and what each returns (applied=false, commit_sha, local_checkout_path, pull_request_url). It also names run_repository_fix as the chained-flow alternative, distinguishing this tool from sibling simulation/planning tools.

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

Usage Guidelines4/5

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

It explicitly advises "Use patch_only to review the diff before writing anything" and points to "run_repository_fix to chain the whole flow," plus states the prerequisite simulate_repository. It does not, however, give explicit when-to-avoid guidance for choosing local_branch versus remote_pr beyond their mode descriptions.

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