Skip to main content
Glama

Config Set

config_set
Idempotent

Write multiple non-secret App Store Connect and identity settings to the config file. Use for batch updates; empty fields remain unchanged.

Instructions

Write several NON-secret settings (ASC key id/issuer/path, team id, copyright, support email, ...) to ~/.appfactory/config.toml.

Use when: setting multiple ASC/identity fields together; fields left empty are unchanged. Not for: secrets (use setup_credentials) or one key (use setup_set). Returns: the config_doctor result after the update, or {ok: false, error} if a secret key was passed.

Input Schema

NameRequiredDescriptionDefault
team_idNoApple Developer Team id (10 characters).
apple_idNoApple ID email of the developer account (used by fastlane produce only).
copyrightNoCopyright line for the store listing, e.g. '2026 Example Ltd'; falls back to the config 'copyright' key.
asc_key_idNoApp Store Connect API key id (10 characters).
asc_issuer_idNoApp Store Connect API issuer id (UUID).
support_emailNoPublic support email address.
asc_key_filepathNoPath to the App Store Connect .p8 private key file.
legal_controllerNoLegal entity name shown as data controller in the privacy policy.
asc_vendor_numberNoApp Store Connect vendor number (sales reports).
asc_finance_key_idNoKey id of a Finance-role App Store Connect API key (for sales reports).
asc_finance_key_filepathNoPath to the Finance-role .p8 key file.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.1.5
    • addedInput schema / properties / apple_id / description
      Added value: +"Apple ID email of the developer account (used by fastlane produce only)."
    • addedInput schema / properties / asc_finance_key_filepath / description
      Added value: +"Path to the Finance-role .p8 key file."
    • addedInput schema / properties / asc_finance_key_id / description
      Added value: +"Key id of a Finance-role App Store Connect API key (for sales reports)."
    • addedInput schema / properties / asc_issuer_id / description
      Added value: +"App Store Connect API issuer id (UUID)."
    • addedInput schema / properties / asc_key_filepath / description
      Added value: +"Path to the App Store Connect .p8 private key file."
    • addedInput schema / properties / asc_key_id / description
      Added value: +"App Store Connect API key id (10 characters)."
    • addedInput schema / properties / asc_vendor_number / description
      Added value: +"App Store Connect vendor number (sales reports)."
    • addedInput schema / properties / copyright / description
      Added value: +"Copyright line for the store listing, e.g. '2026 Example Ltd'; falls back to the config 'copyright' key."
    • addedInput schema / properties / legal_controller / description
      Added value: +"Legal entity name shown as data controller in the privacy policy."
    • addedInput schema / properties / support_email / description
      Added value: +"Public support email address."
    • addedInput schema / properties / team_id / description
      Added value: +"Apple Developer Team id (10 characters)."
  2. First observedv0.1.1

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already cover safety (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds real context on top: empty fields are left unchanged, and a secret key passed yields {ok:false, error}. It does not mention whether the file is created if missing or permissions required, but the key mutation semantics are 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?

Three short lines: what it writes, when/when-not, and return behavior. Front-loaded with the action and target path, zero 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 multi-field config mutation with an output schema present, the description supplies usage routing, partial-update semantics, and the error case. Nothing an agent needs to invoke it correctly 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 parameter meaning is already carried by the schema; the description still adds the non-obvious patch semantics that null/empty fields are unchanged rather than cleared, which the schema's default:null does not make explicit. It names a few representative fields but does not enumerate all 11, which is acceptable given the schema does.

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 (write settings to ~/.appfactory/config.toml), scopes it to NON-secret fields, and names the two sibling tools it is not (setup_credentials, setup_set). An agent can place it correctly without reading any 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?

Explicit 'Use when' (setting multiple ASC/identity fields together) and 'Not for' clauses route to the alternatives setup_credentials and setup_set by name. The empty-field behavior is also stated, leaving nothing to inference.

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