Skip to main content
Glama
runwhen-contrib

RunWhen Platform MCP

render_codecollection_skill

Renders a tested tool-builder task as a private Custom Discovery CodeCollection, outputting files locally for GitOps workflows. Includes decoded script summaries for review.

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]. Requires a runwhen-local release with the runwhen platform indexer (RW-1355).

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. Use 'runwhen' for workspace-scoped tool-builder.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
Behavior5/5

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

With no annotations provided, the description fully carries the transparency burden. It details what files are emitted (codecollection layout, .runwhen files), side effects (writes SKILL_TEMPLATE.md and raw_script files), and clarifies it does not push to git or mutate the workspace. It also describes the default generation rule and the requirement for a specific platform indexer, providing comprehensive behavioral context.

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?

The description is front-loaded with the main purpose and is well-structured. It uses short paragraphs and bullet-like sections (Skills, Emits, Also writes) to convey information efficiently. Every sentence adds value, and there is no redundancy or 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?

Given the high parameter count (35), 100% schema coverage, and presence of an output schema, the description provides sufficient context. It explains the output (files returned inline or written), the prerequisite (runwhen platform indexer), and the default behavior. The description complements the schema and output schema well.

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?

The schema description coverage is 100%, so each parameter already has a description. The tool description does not add additional meaning beyond what the schema provides, but it does give high-level context (e.g., mentioning base64 decoding, stdio mode). Per the rubric, baseline is 3 for high coverage, and the description does not significantly enhance parameter understanding.

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 it renders a tested tool-builder task as a private Custom Discovery CodeCollection. It specifies the verb (render), resource (CodeCollection), and scope (private, tested). It differentiates from siblings by stating it does not push to git, which distinguishes it from commit_slx and other mutation tools.

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?

The description provides clear context for when to use: after testing a task, to render a CodeCollection. It lists prerequisites (runwhen platform indexer, RW-1355) and states it does not push to git, implying that commit_slx should be used afterward. However, it does not explicitly list when not to use or provide direct comparison with siblings beyond the git note.

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