Skip to main content
Glama
runwhen-contrib

RunWhen Platform MCP

render_codecollection_skill

Generates a private Custom Discovery CodeCollection from a tested tool-builder task, emitting file layout and script artifacts for git commit and push.

Instructions

Render a tested tool-builder task as a private Custom Discovery CodeCollection.

Skills:

  • runwhen-skill://commit-to-codecollection (GitOps workflow)

  • runwhen-skill://build-runwhen-task (authoring + testing first)

Emits the standard codecollection layout (generation rule + Jinja templates) for workspace-builder discovery. Templates delegate runtime to rw-generic-codecollection/codebundles/tool-builder with base64 GEN_CMD.

Also writes .runwhen/SKILL_TEMPLATE.md with the decoded script summary and .runwhen/raw_script.{py,sh} with the full decoded script so PR reviewers and automated systems never need to base64-decode TaskSet templates.

This tool does not push to git or mutate the workspace — it renders files locally (or returns them inline) for you to git add / commit / push.

Default generation rule uses platform: runwhen and resourceTypes: [workspace]. For cloud/Kubernetes discovery, set platform to kubernetes, azure, aws, or gcp and pass resource_types / match_rules / slx_qualifiers from the bundled indexer catalogs (list_indexed_resource_types). Discovery SLX templates include the platform tag/hierarchy includes (e.g. kubernetes-tags.yaml).

Requires runwhen-local with the matching platform indexer enabled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo'logs-bulk', 'config', or 'logs-stacktrace'.logs-bulk
tagsNoResource tags ({name, value} dicts).
aliasYesHuman-readable SLX display name.
accessNo'read-write' or 'read-only'.read-write
ownersNoOwner emails for the review file (defaults to current user).
scriptNoThe full script source code (not base64).
env_varsNoEnvironment variables baked into the TaskSet config.
platformNoGeneration rule platform: runwhen (one SLX per workspace), kubernetes, azure, aws, or gcp (per-resource discovery). Call list_discovery_platforms() before choosing — agents must confirm the user's target platform and scope.runwhen
base_nameNoShort SLX suffix in generation rule (<15 chars). Default: bundle_name.
hierarchyNoTag names for hierarchical grouping.
image_urlNoIcon URL for the SLX.
statementYesSLX statement describing what should be true.
output_dirNoWrite rendered files to this directory (stdio mode). When omitted, files are returned in the tool response only.
sli_scriptNoOptional separate SLI script (defaults to main script if include_sli).
task_titleNoHuman-readable task title (static literal).
bundle_nameYesCodebundle directory name (kebab-case, e.g. 'azure-function-cold-start').
include_sliNoAlso emit an SLI template (tool-builder SLI).
interpreterNo'python' or 'bash'.python
match_rulesNoMatch predicates forwarded into the generation rule YAML.
script_pathNoLocal file path for script. **stdio mode only.**
secret_varsNoSecret name → workspace secret key mappings.
runtime_varsNoPer-run runtime variables (task-only).
resource_pathNoResource path for search indexing.
script_base64NoUTF-8 script as standard base64.
resource_typesNoResource types for the generation rule (default: ['workspace']).
slx_qualifiersNoSLX name qualifiers (default: ['workspace']).
workspace_nameYesWorkspace used during tool-builder testing (provenance in review file).
sli_interpreterNoInterpreter for SLI script.
source_slx_nameNoOriginal inline SLX short name (provenance in review file).
timeout_secondsNoTask timeout passed to tool-builder runbook.
script_base64_pathNoLocal path to base64-encoded script file. **stdio mode only.**
script_gzip_base64NoUTF-8 script as base64(gzip(...)).
generic_runtime_refNoGit ref for rw-generic-codecollection pinned in templates.main
sli_interval_secondsNoSLI interval when include_sli is true.
generic_runtime_repo_urlNoOverride rw-generic-codecollection repo URL in templates.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It details what the tool emits (standard codecollection layout, .runwhen files), explains that it renders locally or returns inline, and specifies the default generation rule and platform options. It also explicitly negates side effects (no push/mutation). However, it does not mention error behavior or performance characteristics, which slightly reduces transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long (multiple paragraphs) and includes many details about specific files, skills, and defaults. While every sentence adds value, the length could be overwhelming. The main purpose is front-loaded, but the density of information makes it less concise.

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 high complexity (35 parameters, 4 required, has output schema), the description is remarkably complete. It covers output format, directory handling, platform choices, references to sibling tools like list_discovery_platforms, and the overall workflow. With an existing output schema, return values are already documented, so the description meets completeness needs.

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 coverage is 100%, so all 35 parameters have descriptions in the schema. The tool description adds some contextual meaning (e.g., platform parameter advises calling list_discovery_platforms, script parameters explain base64 options), but overall it does not significantly deepen understanding beyond the schema defaults and descriptions. Baseline 3 is appropriate.

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 clearly states the tool's primary function: 'Render a tested tool-builder task as a private Custom Discovery CodeCollection.' It uses a specific verb ('render') and a specific resource ('CodeCollection'), and distinguishes itself from sibling tools by focusing on this rendering task rather than listing workspaces, chat, or other operations.

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?

The description provides explicit guidance on when to use the tool: it renders a tested tool-builder task. It mentions related skills (commit-to-codecollection, build-runwhen-task) and clearly states what the tool does not do: 'This tool does not push to git or mutate the workspace.' It also advises calling list_discovery_platforms() before choosing a platform, giving the agent a clear workflow step.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/runwhen-contrib/runwhen-platform-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server