Skip to main content
Glama
wiroai

Wiro MCP Server

Official
by wiroai

Manage custom skills and scheduled tasks

manage_agent_custom_skill
Destructive

Create and manage an agent's custom skills and scheduled tasks: upsert instructions or cron prompts, rename, delete, view history, and revert to prior versions.

Instructions

Create and manage a deployed agent's own skills. A custom skill (key cs-...) is standing instructions the agent follows, for example a tone or an approval policy. A scheduled task (key cs-cron-...) is a prompt the agent runs by itself on a cron schedule, for example a weekly report. Actions: upsert creates or updates one (a bare key such as "weekly-report" updates the agent's own entry of that name when there is one, and otherwise gets its prefix from kind or interval; the result gives the final key); rename changes the key of one you created; delete removes one you created together with its history (needs confirm: true); history shows the current text in full and lists earlier versions, the template default and ready-made templates (key "cs-my-custom-strategy" or "cs-cron-my-scheduled-task" gives starter templates); revert restores the template default or an earlier version (needs confirm: true). Schedules use the agent's time zone, which is UTC unless it was set with update_agent; a new task without interval runs Mondays at 10:00. Every scheduled run spends the agent's credits, so confirm the schedule with the user. Entries from the agent's template, cs-approval-policy and the scheduled tasks its skills brought cannot be deleted or renamed: set enabled false instead. The agent restarts when the text, schedule or on/off state changes. get_my_agent lists the current entries. Registry skills are switched with apply_agent_skills instead. On a team agent this needs a team admin or the person who deployed it; other team members read each entry in full with get_my_agent (entry). The agents playbook (get_playbook) covers custom skills and schedules.

Input Schema

NameRequiredDescriptionDefault
keyYesThe entry's key: a full key (cs-... or cs-cron-...) or a bare slug such as "weekly-report" (lowercase letters, digits, single dashes). A bare slug names the agent's existing entry of that name, whichever kind it is.
kindNoskill (instructions, cs-) or scheduled_task (runs on a schedule, cs-cron-). Decides the prefix of a bare key; without it a new bare key becomes a custom skill unless interval is given.
limitNohistory: how many versions to return, newest first (default 20).
valueNoupsert: the instructions (custom skill) or the prompt to run (scheduled task). Required when creating.
actionYesWhat to do.
sourceNorevert: preset (the template default) or history (an earlier version).
confirmNodelete and revert: true to do it after the user agreed. Without it they only describe what would happen.
enabledNoupsert: true to turn it on, false to turn it off. New entries start on.
new_keyNorename: the new key, of the same kind.
intervalNoupsert, scheduled tasks only: a 5-field cron expression such as "0 9 * * 1-5" (weekdays 09:00). Omit to keep the current schedule, or Mondays 10:00 for a new task.
agent_guidYesThe deployed agent's guid, from list_my_agents.
version_idNorevert with source history: a versionId from action history.
descriptionNoupsert or rename: a short summary the agent uses to pick the skill. Fixed for entries that come with the agent.

Output Schema

NameRequiredDescriptionDefault
keyYes
kindYes
entryNo
actionYes
statusYes
createdNo
historyNo
messageYes
restartNo
scheduleNo
warningsYes
agentGuidYes
renamedToNo
templatesNo
nextActionNo
revertResultNo
presetDefaultNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.1

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the destructive/openWorld annotations: delete removes history and needs confirm:true, revert needs confirm, scheduled runs spend credits, the agent restarts on text/schedule/state changes, and template-provided entries cannot be deleted or renamed (use enabled:false). This is exactly the operational context annotations cannot convey.

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?

Dense but front-loaded: type definitions first, then per-action semantics, then constraints and permissions. Every sentence carries information, though the single long paragraph could be broken up for faster scanning.

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?

For a 13-parameter, multi-action mutation tool with an output schema and rich annotations, the description covers action semantics, defaults, side effects, permissions, and sibling routing. Nothing an agent needs to invoke it correctly is missing.

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, but the description adds real meaning: bare-key resolution (updates existing entry of that name, otherwise prefix derived from kind or interval), the default Monday 10:00 schedule, and confirm's describe-only behavior. It stops short of covering every parameter (e.g. limit, version_id) in prose, but the schema handles those.

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 and resource and explicitly separates the two entry types (custom skill cs-... vs scheduled task cs-cron-...) with concrete examples. It also distinguishes itself from siblings apply_agent_skills (registry skills) and get_my_agent (listing), so an agent can route correctly without opening schemas.

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?

Names alternatives and the conditions that select them: registry skills go to apply_agent_skills, listing goes to get_my_agent, deeper docs go to get_playbook. It also states the permission prerequisite (team admin or deployer) and the read path for other team members.

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