Skip to main content
Glama
gbatistuta0

AppFactory

by gbatistuta0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

GitHub Create Repo

github_create_repo
Destructive

Create a private GitHub repo and push your app to track it on GitHub. Default dry_run returns command; set false for live action requiring approval.

Instructions

Create a PRIVATE GitHub repo under the configured account and push the app (needs human approval unless dry_run).

Use when: the app should be tracked on GitHub. dry_run=true (default) only returns the command. For later commits use github_push. Returns: {ok, command/url, dry_run} or an approval_required refusal.

Input Schema

NameRequiredDescriptionDefault
app_dirYesAbsolute path to the app project directory (contains app.spec.json), e.g. /Users/me/Apps/MyApp.
dry_runNoIf true (default) nothing is changed or sent and the exact plan/command is returned; false performs the live action.
repo_nameYesName of the new private repository, e.g. 'my-app'.
approval_idNoApproval id from a previous approval_required refusal; omit on the first call. The human approves out-of-band with `appfactory approve <id>`, then call again with the same arguments and this id.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.5
    • addedInput schema / properties / app_dir / description
      Added value: +"Absolute path to the app project directory (contains app.spec.json), e.g. /Users/me/Apps/MyApp."
    • addedInput schema / properties / approval_id / description
      Added value: +"Approval id from a previous approval_required refusal; omit on the first call. The human approves out-of-band with `appfactory approve <id>`, then call again with the same arguments and this id."
    • addedInput schema / properties / dry_run / description
      Added value: +"If true (default) nothing is changed or sent and the exact plan/command is returned; false performs the live action."
    • addedInput schema / properties / repo_name / description
      Added value: +"Name of the new private repository, e.g. 'my-app'."
  2. First observedv0.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotent, but the description adds the critical approval gate ('needs human approval unless dry_run') and the approval_required refusal path, which the annotations do not convey. It stops short of describing reversibility or rate limits, but the approval flow is the key trait and it is disclosed.

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?

Front-loads the action and its approval constraint, then compresses when-to-use, the dry_run default, the alternative tool, and the return shape into two tight sentences. No filler.

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 destructive, human-gated mutation with an output schema present, the description covers the approval workflow, the dry_run default, the sibling alternative, and the refusal outcome. Nothing an agent needs to call it correctly and handle the response is missing.

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?

Schema description coverage is 100%, so app_dir, repo_name, dry_run, and approval_id are all documented in the schema; the description only restates the dry_run default. This is the baseline-3 case where the schema does the heavy lifting.

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?

States a specific verb and resource ('Create a PRIVATE GitHub repo'), plus the side effect of pushing the app, and explicitly contrasts with the sibling github_push ('For later commits use github_push'). An agent can distinguish this from the other ~100 tools 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 Guidelines5/5

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

Gives an explicit trigger ('Use when: the app should be tracked on GitHub'), the default no-op behavior of dry_run, and routes later commits to github_push. When-to-use and the alternative are both stated, not implied.

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