Skip to main content
Glama

Ankra

by ai.ankra
OverviewDiscussionsAdmin

cicd_propose_application_pipeline

Read-only

Render the canonical Ankra CI/CD pipeline (Kubernetes manifests + application descriptor + the CI definition + optionally a Dockerfile) for a target repository. The CI definition and manifest YAML are rendered server-side from a fixed Ankra template - you DO NOT write them yourself; you only provide the tailoring fields and the Dockerfile string. Returns the rendered files plus a list of validator violations and a severity. If severity is 'warn' or 'fatal', revise the tailoring (or Dockerfile) and call again. When severity is 'ok', commit the returned files via github_create_pull_request. Read-only - no commits happen here.

Supports two shapes:

  1. Single-app (default): pass top-level app_name + tailoring (+ optional dockerfile). The manifests go to .ankra/manifests/, the application descriptor to .ankra/ankra.yaml, and the CI definition to .ankra/pipeline.yaml (or .github/workflows/build-and-publish.yml when target is 'github_actions').

  2. Monorepo (multi-app): pass the apps array with one entry per deployable app. Each app gets its own manifests under .ankra/manifests/-*.yaml, its own descriptor at .ankra/-ankra.yaml, and its own Dockerfile at <app_subdir>/Dockerfile. By default every app's stages are grouped into the one .ankra/pipeline.yaml a repository holds (with a paths: filter scoped to each app's subdir); pass target 'github_actions' for one workflow per app at .github/workflows/-build-and-publish.yml instead. Use the apps shape when the repo has signals like workspaces (in package.json), nx.json, turbo.json, lerna.json, multiple existing Dockerfiles, or multiple top-level app/service directories each with their own dependency manifests.

CI definition target: 'target' picks what the proposal's CI definition is. 'ankra_pipeline' renders .ankra/pipeline.yaml, which Ankra runs inside the cluster, and is the default for both shapes - a monorepo's several apps are grouped into the one file, each under its own component-suffixed stages. 'github_actions' renders the legacy generated workflow(s) instead, for a repository that must keep building on GitHub. Everything else in the proposal - the Dockerfile, the descriptor, the manifests - is identical either way.

Input Schema

NameRequiredDescriptionDefault
appsNoMONOREPO shape. List of apps in the repository, one entry per deployable app. When provided (and non-empty), the single-app fields (app_name, tailoring, dockerfile) are ignored. Every app must have a unique non-empty app_subdir.
repoYesRepository name (used as the container image repository path).
ownerYesRepository owner (e.g. 'octocat'). Prefer the exact owner from a prior github_list_repositories call.
branchYesBranch the workflow's 'on: push' trigger should fire for (typically the repo's default branch).
targetNoOPTIONAL. Which CI definition the proposal carries. 'ankra_pipeline' renders .ankra/pipeline.yaml, the definition Ankra's own pipeline engine runs inside the cluster - use it for every new repository, single-app or monorepo. 'github_actions' renders the legacy .github/workflows/build-and-publish.yml instead (one file per app in the monorepo shape), unchanged, for a repository that must keep building on GitHub. Omitted, both shapes default to 'ankra_pipeline': the monorepo (apps) shape groups every app's stages into the one .ankra/pipeline.yaml a repository holds, each under its own component-suffixed stage names.
app_nameNoSINGLE-APP shape only. Human-readable application name. Used in the manifest metadata; lowercased and dashed for the resource's safe name. Ignored when 'apps' is provided.
tailoringNoSINGLE-APP shape only. Per-repo customisation for the canonical Ankra workflow + Kubernetes manifests. Everything else (security scanning, multi-arch build, GHCR image publishing, package visibility) is locked in the canonical template and does NOT need to be specified. Ignored when 'apps' is provided.
dockerfileNoSINGLE-APP shape only. OPTIONAL full Dockerfile content. When provided, included verbatim in the returned files list as 'Dockerfile' (path). When the target repo already has a Dockerfile and you don't want to overwrite it, omit this field. Ignored when 'apps' is provided.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, which the description confirms ('Read-only - no commits happen here'), so there is no contradiction. It adds substantial behavioral context beyond annotations: server-side rendering, the returned violation list and severity, and the required retry behavior. It does not, however, describe pagination or limits, though those are largely irrelevant for a render operation.

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 opening paragraph is well front-loaded (purpose, read-only nature, next-step loop) and the shape/target paragraphs are logically ordered. It is long and repeats some detail already carried in the schema descriptions, which keeps it just short of a 5.

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?

Despite having no output schema, the description fully explains what is returned (rendered files plus validator violations and a severity) and what to do with each severity outcome. For a complex two-shape, multi-file rendering tool, the agent has everything needed to call it correctly and act on the result.

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 and the schema already documents each field in depth. The description still adds cross-parameter meaning the individual field docs do not: that the apps array overrides the top-level app_name/tailoring/dockerfile, and how target interacts with shape (one grouped .ankra/pipeline.yaml vs one workflow per app).

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 (render) and a precisely enumerated resource (Kubernetes manifests + application descriptor + CI definition + optional Dockerfile) for a target repo. It clearly differentiates from the cicd_validate_* siblings by noting it does not write files itself and that output is rendered server-side from a fixed template.

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 explicit when-to-use rules for both shapes (single-app vs monorepo, including the repo signals like nx.json/turbo.json/multiple Dockerfiles that select the apps shape) and for the two target values. It also names the escalation path via github_create_pull_request and the revise-and-retry loop on warn/fatal severity.

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

All Ankra toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources