Skip to main content
Glama
gbatistuta0

AppFactory

by gbatistuta0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Run Options Save

run_options_save
Idempotent

Save and confirm all run option answers after questions, validating types, choices, and dependencies before writing settings to config.toml, app.spec.json, or the pending app scaffold file.

Instructions

Save the user's answers to the run options and mark options confirmed.

Use when: after asking every question from run_options. Validates types, choices and dependencies; services go to config.toml, the rest to app.spec.json (or a pending file that app_scaffold applies). Returns: {ok, saved, errors?}.

Input Schema

NameRequiredDescriptionDefault
answersYesMap {option id: value} covering every option id returned by run_options.
app_dirNoApp directory whose app.spec.json receives the answers; omit to save to the pending file used by app_scaffold.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.5
    • addedInput schema / properties / answers / description
      Added value: +"Map {option id: value} covering every option id returned by run_options."
    • addedInput schema / properties / app_dir / description
      Added value: +"App directory whose app.spec.json receives the answers; omit to save to the pending file used by app_scaffold."
  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 non-read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond that: it validates types, choices, and dependencies, and it explains the storage split between config.toml and app.spec.json or the pending file.

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?

The description is front-loaded with purpose, then usage, behavior, and return shape. Every sentence carries useful information and there is no redundant 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?

The tool is a mutation with a clear output schema and full annotation coverage. The description covers when to call it, what validation occurs, where data is written, and the return shape, leaving no significant gap for correct invocation.

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. The description still adds value by explaining that answers must cover every option id from run_options and by clarifying that services go to config.toml while the rest go to app.spec.json, which helps interpret how the answers parameter is applied.

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 gives a specific verb and resource: save the user's answers to run options and mark options confirmed. It also distinguishes this tool from run_options (which asks the questions) and app_scaffold (which applies the pending file), so an agent can route correctly without inspecting sibling schemas.

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 says to use this after asking every question from run_options, which is clear and actionable. It also references app_scaffold for the pending-file case, but it does not state when not to use the tool or provide explicit alternatives beyond those dependencies.

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