Skip to main content
Glama

Publish an agent

publish_agent
Destructive

Publish source as an agent: a SOUL.md describing who it is, a valet.yaml declaring the skills, connectors, channels, and configuration it runs with, and any supporting files. Use it when the work is an agent that answers on a channel or runs on a schedule, not a website or an app. Apply the governance skill before calling.

files must include valet.yaml and SOUL.md at the root. Unlike a website's or an app's, an agent's valet.yaml is yours: Valet validates it rather than writing it, and refuses one the agent rules reject. An organization connector or channel the manifest names is attached for you. When the manifest names one the organization does not have, or a skill that does not resolve, nothing deploys and the answer lists what is pending and the tool that sets each up; do that and call again with the same files.

Publishing to a name that exists replaces its source with these files, so read get_source first when the agent is not yours. The first publish creates the agent. An agent deploy finishes before this call returns: the answer carries the release version, and get_service reports whether the agent is running and what it holds. Requires connecting a Valet account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesRequired. The agent's name. Naming an agent that exists republishes it.
filesYesRequired. The agent's files, [{path, content}], including valet.yaml and SOUL.md at the root.
org_nameNoThe Valet organization to publish into. Omit to use the organization the account joined first.
discard_draftNoSet true to discard an open draft on this agent that another session left. Omit to be told about it instead.
idempotency_keyNoAn opaque key of your choosing. Repeating a call with the same key returns the first call's result instead of deploying a second release. Use a new key for new files: a repeated key returns the earlier result even when the files changed. A call that deployed nothing gives its key back.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

With annotations supplying the safety profile, the description still adds substantial context beyond them: the manifest is validated rather than written, unnamed org connectors/channels are auto-attached, unresolved references cause nothing to deploy and return a pending list with the fixing tool, deploys finish before return, and a Valet account must be connected. The replacement-on-existing-name behavior aligns with destructiveHint=true, and the opt-in idempotency_key is consistent with idempotentHint=false.

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?

Purpose and the agent-vs-site distinction are front-loaded, and every paragraph carries actionable information (preconditions, failure handling, replacement, return behavior). The prose is dense and somewhat mannered, so it is longer than strictly necessary, but it is not padding.

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?

There is no output schema, so the description carries return-value burden and does so: the answer carries the release version and points to get_service for run status. Combined with the auth requirement, failure-mode explanation, and file prerequisites, an agent has everything it needs to call this correctly.

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 schema already documents all five parameters and the baseline is 3. The description adds cross-cutting meaning on top: files must contain valet.yaml and SOUL.md at the agent root, and publishing to an existing name replaces its source (clarifying the `name` parameter's republish semantics). This goes beyond restating the schema.

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 precise verb+resource ('Publish source as an agent') and immediately differentiates from siblings by describing the artifact shape: a SOUL.md, a valet.yaml with skills/connectors/channels/configuration. It explicitly rules out publish_site/publish_app with 'not a website or an app,' so the agent can route correctly without opening a schema.

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 an explicit when-to-use condition ('when the work is an agent that answers on a channel or runs on a schedule, not a website or an app'), a precondition ('Apply the governance skill before calling'), and a prerequisite read ('read get_source first when the agent is not yours'). Alternatives and exclusions are both named.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources