Skip to main content
Glama

Preview Workflow setup

preview_workflow_setup
Read-only

Preview setting up a Workflow that translates a GitHub repository, from the App installation id (list_github_installations) and "owner/repo" alone. Detects the locale files on the first branch and proposes a definition: Translate, then QA, delivered by pull request; the detected source and target languages; named "owner/repo". Writes nothing and starts no run. Answers ready: true with the definition, the file groups left out as unlikely (excludedGroups) and a previewHash for set_up_workflow; or ready: false with needs (each names what was found and the argument to pass — a language is never guessed), or with alreadySetUp naming the Workflow that holds the repository, whatever any Project on it does. Only when no Workflow holds it is it refused with REPOSITORY_HELD_BY_PROJECT, when a Project has work on it: continue on that Project. Pass the optional arguments to apply what the user asks for. When referring to a project or language in your reply to the user, use its name and locale (e.g. "French (fr-FR)") — ids (UUIDs) are for tool calls only, never show them to the user.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "installationId": "<installationId>",
      "repository": "<repository>"
    },
    "name": "preview_workflow_setup"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoDefault: the repository’s `owner/repo`.
importNoWhat the first run does with translations already in the target files: `ignore` (default) translates every string afresh and writes over them; `reviewed` or `translated` imports them at that status.
branchesNoWatched branches, in order; detection reads the first. Default: the repository’s default branch.
patternsNoPatterns in place of detection’s. With them, no `patterns` need is answered: a setup may sit on a branch with no locale files yet.
repositoryYes`owner/repo`, any case. Its numeric id is resolved through the installation.
installationIdYesGitHub’s numeric App installation id (`installationId` of `GET /api/github/installations`); it must be this organisation’s
sourceLanguageNoIn place of the detected source; respelled to the language catalog’s spelling.
targetLanguagesNoDeclared targets in place of the detected ones, taken as given.
translationMemoryIdNoAn existing translation memory of the organisation (404 `TRANSLATION_MEMORY_NOT_FOUND` otherwise). Absent, confirm creates one named after the Workflow.

Output Schema

NameRequiredDescriptionDefault
nameNo
needsNoOne per field setup can’t fill
readyYestrue: confirm with set_up_workflow and `previewHash`. false: `alreadySetUp` names the Workflow holding the repository, or `needs` lists what to pass
warningsNo
takeoversNoIdle Projects’ Repository rows on the repository, which the Workflow takes over
definitionNoThe definition confirm publishes as version 1. While `newTranslationMemory`, its translate Action names the stand-in `00000000-0000-4000-8000-000000000000`, which confirm replaces with the memory it creates.
previewHashNoSend it with `POST /api/workflows/setup`: refused with 409 `WORKFLOW_PREVIEW_STALE` when the definition, excluded groups, claims or warnings changed since
alreadySetUpNoThe Workflow holding the repository: nothing to set up, whatever any Project on it does, and confirm is refused with 409 `WORKFLOW_REPOSITORY_CLAIMED`
excludedGroupsNo
newTranslationMemoryNoWhether confirm creates a translation memory, named after the Workflow

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly and non-destructive annotations, it discloses that no run is started, locale files on the first branch are detected, and the proposed definition is Translate then QA delivered by pull request. It also describes the ready:true and ready:false response shapes, including needs, alreadySetUp, and REPOSITORY_HELD_BY_PROJECT.

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 description is front-loaded with the core purpose and behavior, and most details earn their place for a complex preview tool. It is dense and somewhat long, especially the final user-facing UUID instruction, but it remains organized and useful.

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 the tool's complexity, annotations, full input-schema coverage, and output schema, the description is complete enough for an agent to understand purpose, behavior, and major response states. Nothing essential for correct invocation appears to be 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 the input schema already documents all nine parameters in detail. The description reinforces the minimal required inputs and that optional arguments are applied when the user asks, but adds little parameter-specific meaning beyond 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?

The description uses a precise verb and resource: preview setting up a Workflow that translates a GitHub repository. It clearly distinguishes this from set_up_workflow by explaining that it writes nothing, starts no run, and returns a previewHash for that sibling.

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 implicitly tells the agent to use this before set_up_workflow and names list_github_installations as the source of installationId. It also explains the ready/false outcomes and when a Project already holds the repository, though it does not explicitly state exclusions or all alternative paths.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.