Skip to main content
Glama
Sign In

Valet

by io.github.valetdotdev
OverviewDiscussionsAdmin

Create a website, app, agent, or skill

create_service

Create an empty website, app, agent, or skill in an organization, before publishing to it. This is the first step for anything new: publish_site, publish_app, publish_agent, and publish_skill change a service that exists and refuse a name that does not. Pass kind to say which you mean, and name to choose its name; omit name to have one generated, except for a skill, which needs one. A name another website, app, agent, or skill in the organization holds is refused, as is a create past the organization's limit for that kind. The result names the organization, kind, name, and URL; publish to the name next.

A skill is know-how the organization shares with every member's agent: use kind skill, then publish_skill, when the user wants to share a skill with their team, such as one they keep locally. Its repository starts from a starter SKILL.md, or, for a well-known name such as governance or design-system, from Valet's default, which the organization's skill then replaces. Nothing reaches an agent until it is published. A skill is private at its URL: only members of the organization can open it. With catalog, it instead installs that skill from Valet's curated catalog under name, as the organization's own copy published as its first version. An organization that installed it before gets that copy back, whatever its name, and nothing is installed. Requires connecting a Valet account.

Input Schema

NameRequiredDescriptionDefault
kindYesRequired. What to create: a static website, a Procfile app, an agent, or a skill.
nameNoThe service's name. For a website, app, or skill it becomes the first label of its URL. Omit to have one generated; a skill needs one, 3 to 63 lowercase letters, digits, and single hyphens.
catalogNoFor a skill only: the name of a catalog skill to install under name, such as premortem. Omit to create an empty skill.
org_nameNoThe Valet organization to create it in. Omit to use the organization the account joined first.
idempotency_keyNoAn opaque key of your choosing. Repeating a call with the same key returns the first call's result instead of creating a second service, which makes a retry safe.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous value: -"The service's name. For a website or app it becomes the first label of its URL. Omit to have one generated; a skill needs one, 3 to 63 lowercase letters, digits, and single hyphens."New value: +"The service's name. For a website, app, or skill it becomes the first label of its URL. Omit to have one generated; a skill needs one, 3 to 63 lowercase letters, digits, and single hyphens."
  2. Changed4 schema fields changed
    • addedInput schema / properties / catalog
      Added value: +{
+  "description": "For a skill only: the name of a catalog skill to install under name, such as premortem. Omit to create an empty skill.",
+  "type": "string"
+}
    • changedInput schema / properties / kind / description
      Previous value: -"Required. What to create: a static website, a Procfile app, or an agent."New value: +"Required. What to create: a static website, a Procfile app, an agent, or a skill."
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "site",
-  "app",
-  "agent"
-]New value: +[
+  "site",
+  "app",
+  "agent",
+  "skill"
+]
    • changedInput schema / properties / name / description
      Previous value: -"The service's name. For a website or app it becomes the first label of its URL. Omit to have one generated."New value: +"The service's name. For a website or app it becomes the first label of its URL. Omit to have one generated; a skill needs one, 3 to 63 lowercase letters, digits, and single hyphens."
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description adds substantial context beyond that: name collisions and per-kind org limits are refused, unpublishing state ('nothing reaches an agent until it is published'), skill URL privacy, catalog install returning the prior copy, and the Valet-account connection requirement.

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?

Front-loaded and information-dense, but markedly wordy and repetitive: the four-kind enumeration recurs several times and the skill/catalog paragraph restates points already implied earlier. Every sentence is relevant, yet the volume is greater than the operation warrants.

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 still tells the agent what comes back (organization, kind, name, URL) and what to do next (publish to that name). Auth prerequisites, refusal conditions, and the skill/catalog lifecycle are all covered.

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 baseline is 3, but the description adds meaning on top: kind semantics mapped to create targets, the omit-name fallback and its skill exception, and especially catalog behavior (install Valet's curated skill under name, published as the organization's first version, previously-installed orgs get their copy back).

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+resource and states the precise scope: creating an empty website, app, agent, or skill before publishing. It explicitly separates itself from the publish_* siblings by noting they 'change a service that exists and refuse a name that does not.'

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?

Gives explicit routing rules: this is the first step for anything new; publish_site/publish_app/publish_agent/publish_skill operate on existing services. It also names the condition for kind=skill (sharing know-how with a team) and the catalog variant.

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