Skip to main content
Glama
Sign In

Valet

by io.github.valetdotdev
OverviewDiscussionsAdmin

Destroy a website, app, agent, or skill

destroy_service
DestructiveIdempotent

Permanently destroy a website, app, agent, or skill. This cannot be undone, so confirm with the user first. Pass kind to say which you mean; a name holding another kind is then refused rather than destroyed. Destroying a website or app stops serving it. Destroying an app stops it and removes its releases and source; its resources are detached and kept, because they belong to the organization and may serve other apps, and the answer names them for destroy_resource. Destroying an agent stops it and removes its channels, agent-scoped connectors, drains, mailboxes, releases, and source repository; none of those can be recovered. Its sessions and memories remain, and once the agent is gone no MCP tool can remove them, so call destroy_session and destroy_memory first if they should go. The architect agent cannot be destroyed. Destroying a skill removes it from list_skills and frees its name; it is refused while any agent has the skill attached, and the refusal names detach_skill, which frees each one. Destroying a skill under a well-known name, such as governance or design-system, brings back Valet's default for every agent in the organization. A name that no longer exists answers that nothing was destroyed. Identify the service by name, which requires connecting a Valet account, or a website published anonymously by the site_token returned when it was published — whoever published a site can always take it down.

Input Schema

NameRequiredDescriptionDefault
kindNoThe kind you mean. Omit to destroy whatever the name holds; give it to have a name holding another kind refused.
nameNoGive this or site_token. The website's, app's, agent's, or skill's name, which requires a connected Valet account.
org_nameNoThe Valet organization it belongs to. Omit to use the organization the account joined first.
site_tokenNoGive this or name. The token returned when a website was published anonymously; it identifies that one site.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "site",
-  "app",
-  "agent"
-]New value: +[
+  "site",
+  "app",
+  "agent",
+  "skill"
+]
    • changedInput schema / properties / name / description
      Previous value: -"Give this or site_token. The website's, app's, or agent's name, which requires a connected Valet account."New value: +"Give this or site_token. The website's, app's, agent's, or skill's name, which requires a connected Valet account."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true, but the description goes far beyond them: it discloses per-kind fallout (resources detached and kept, app releases/source removed), what survives (agent sessions/memories), that a well-known skill name restores Valet defaults org-wide, and that a missing name answers harmlessly. This is exactly the 'what gets destroyed vs. preserved' context a destructive tool needs.

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?

Front-loaded with the destructive warning and kind guidance before the per-kind details, and the identification rules are saved for last. It is long, but the four-kind complexity justifies most of the length; a few clauses could be tightened.

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?

With no output schema, the description covers return-relevant behavior ('the answer names them for destroy_resource', 'answers that nothing was destroyed') and all four kinds, org scoping, and both identifier paths. An agent can invoke this correctly without opening another tool.

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 semantics beyond the schema: it explains that kind causes a name of another kind to be refused rather than destroyed, and that site_token lets whoever published anonymously always take the site down — behavioral meaning the schema fields only hint at.

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?

Opens with a specific verb and resource: 'Permanently destroy a website, app, agent, or skill.' The four kinds are enumerated, immediately distinguishing it from sibling destroyers (destroy_channel, destroy_resource, destroy_session, destroy_connector) and from create/publish counterparts.

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?

Explicitly states prerequisites and ordering: call destroy_session and destroy_memory first for agent cleanup, and detach_skill frees a skill-blocked refusal. It names the alternatives (destroy_resource, detach_skill) and the hard exclusion ('The architect agent cannot be destroyed'), leaving little to inference.

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

All Valet 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