Skip to content

feat(operations,mcp): document scaffolding pre-conditions in deploy-service / grant-repo-access - #45

Merged
mashkovd merged 1 commit into
mainfrom
feat/document-scaffolding-prereqs
May 8, 2026
Merged

mashkovd merged 1 commit into
mainfrom
feat/document-scaffolding-prereqs

Conversation

@mashkovd

@mashkovd mashkovd commented May 8, 2026

Copy link
Copy Markdown
Member

Summary

Surface the implicit pre-conditions of mctl_deploy_service action=onboard directly in tool descriptions, instead of letting LLM/human consumers re-discover them via failed builds. Three text-only edits, no behaviour change:

  • internal/operations/registry.go (deploy-service Description): extend the short summary returned by GET /api/v1/operations to mention the Dockerfile requirement and link to the scaffolding guide.
  • internal/mcp/server.go (mctl_deploy_service): expand the MCP description with a Pre-conditions block, a four-step Order of operations for a brand-new repo, and the same docs link.
  • internal/mcp/server.go (mctl_grant_repo_access): append a paragraph pointing at scaffolding for first-time service setup — grant_repo_access is the natural entry point and the right place to flag what's coming next.

Why

Every fresh-service onboard currently re-discovers the same layout: Dockerfile shape, CI deploy job calling api.mctl.ai/api/v1/operations/deploy-service/execute, and the MCTL_GITHUB_TOKEN secret backing it. With these enriched descriptions, an LLM session reading mctl_deploy_service already knows the procedure (and where to find the templates) before it tries to call onboard against an empty repo.

Pairs with mctlhq/mctl-docs#15 (the /guides/scaffolding page that this PR links to). Merge that one first so the link resolves on docs.mctl.ai before this lands.

Test plan

  • go build ./... passes (verified locally before pushing)
  • After merge, curl https://api.mctl.ai/api/v1/operations returns the new deploy-service Description text
  • After MCP redeploy, opening a fresh Claude session and inspecting the mctl_deploy_service tool definition shows the new pre-conditions block
  • End-to-end: in a fresh repo with no Dockerfile, ask Claude to deploy to mctl — it should reach for the scaffolding URL based on the description rather than trying onboard blindly

🤖 Generated with Claude Code

…ervice / grant-repo-access

LLM consumers of the MCP server (and humans reading the REST
operation list) keep tripping on the implicit assumption that an
onboarded repo already has a Dockerfile and a CI deploy job. When
they don't, mctl_deploy_service action=onboard fails with a generic
build error and the user has to re-discover the canonical layout
each time.

Surface the pre-conditions directly in the tool descriptions, with
links to the new https://docs.mctl.ai/guides/scaffolding page that
ships copy-paste Dockerfile templates (Node, Python, Go, static)
and the canonical SemVer-bumping CI deploy job.

Three edits, no behaviour change:

- internal/operations/registry.go (deploy-service): extend the
  short Description seen by REST GET /api/v1/operations callers.
- internal/mcp/server.go (mctl_deploy_service): expand the MCP
  tool description with a Pre-conditions block, the four-step
  onboard order-of-operations, and the same docs link.
- internal/mcp/server.go (mctl_grant_repo_access): append a
  paragraph pointing at scaffolding for first-time service setup,
  since grant_repo_access is the typical entry point.
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant