Skip to main content
Glama
Sign In
OrangePro MCP

OrangePro MCP

Official
by OrangeproAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Install the post-merge GitHub Actions workflow

orangepro_install_github_action
Idempotent

Preview by default, then install an opt-in post-merge GitHub Actions workflow and the .orangepro/actions test profile it reads; write files only with explicit confirmation and never overwrite conflicts.

Instructions

Preview, by default, the opt-in post-merge workflow (.github/workflows/orangepro-proof.yml: contents: read, no secrets, pinned actions) and the .orangepro/actions/ folder it reads (the profile: target, oracle, fault, selected tests, the test to replay). Writes nothing unless dry_run is false and confirm is "install" (or "uninstall" with uninstall: true). Never commits, pushes, creates secrets, grants permissions or opens pull requests; a file changed since OrangePro wrote it is reported as a conflict and never overwritten or removed. Tested locally; a real Actions run is separate.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "orangepro_install_github_action"
  }
}

Input Schema

NameRequiredDescriptionDefault
baseNoBranch whose pushes start the workflow. Default: the remote's default branch, else main.
confirmNoRequired with dry_run: false; must match the action.
deliverNoOpt-in: add the separate deliver job that opens one draft test PR for a verified gap (the only job with write permissions; it runs no repository code).
dry_runNoDefault true: preview only.
uninstallNoRemove the files OrangePro wrote (only those still unchanged).
workspaceNoLocal workspace root. Defaults to the current directory.
build_sha256NoThat version's build stamp. Default: this build's.
opro_versionNoOrangePro version the workflow installs. Default: this one.
profile_fromNoFolder holding profile.json and the files it names. Needed to install.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnlyHint=false and destructiveHint=false, the description discloses the precise write gate, what is never done (commits, pushes, secrets, permission grants, PRs), and the conflict policy — a file modified since OrangePro wrote it is reported, never overwritten or removed. That conflict rule is exactly the kind of behavioral detail annotations cannot express.

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 default preview behavior is front-loaded and every clause carries information; nothing is filler. It is dense with nested parentheticals, though, which makes it slightly harder to scan than it needs to be for a nine-parameter tool.

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 nine-parameter, opt-in mutation tool with full schema coverage, annotations, and no output schema, the description covers what gets written, when, what is never touched, and how conflicts resolve. Nothing an agent needs in order to call it safely 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 schema already documents all nine parameters and the baseline is 3. The description adds real value by explaining the dry_run/confirm/uninstall interaction and by describing what profile_from's folder must contain (target, oracle, fault, selected tests, replay test), which the schema only gestures at.

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 names a specific verb and resource — previewing/installing the opt-in post-merge workflow at .github/workflows/orangepro-proof.yml plus the .orangepro/actions/ folder it reads. No sibling tool touches GitHub Actions workflow files, so the agent can distinguish it immediately without opening the schema.

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 states the default mode (preview), the exact condition for writing (dry_run false plus confirm "install", or "uninstall" with uninstall: true), and the opt-in nature of the deliver job. It also scopes expectations with "Tested locally; a real Actions run is separate." It does not point at any sibling alternative, but none exists for this task.

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