Skip to main content

Documentation Index

Fetch the complete documentation index at: https://agentvolumes.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

A component is a functional unit that an agent runtime loads and executes from a volume. Agent Volumes defines seven component types, each with distinct semantics, entrypoint formats, and execution models. When you publish a volume, you declare which components it exports in volume.toml, and any compatible runtime can discover and load them.

​
Component type summary

TypeInvoked byExecution modelStatePrimary format
AgentRuntimeAutonomous, long-runningStatefulMarkdown/YAML
SkillRuntime (contextual)Loaded into contextN/A (knowledge)Markdown (SKILL.md)
CommandUser (explicit)Trigger-based workflowPer-invocationMarkdown
ToolAgent (programmatic)Function callStatelessJSON/YAML/Script
HookRuntime (event)Event-drivenStatelessMarkdown/YAML/Script
MCP ServerRuntime (process)Long-running serviceStateful (server)JSON config
LSP ServerRuntime (process)Long-running serviceStateful (server)JSON config

​
Component types

Agent

An autonomous runtime actor that receives a goal and independently decides how to accomplish it using tools, skills, and other agents.

Skill

Reusable instructional knowledge loaded into agent context. The runtime interprets and applies it — skills are not executed as code.

Command

A user-invokable action triggered by a slash command pattern such as /review or /summarize.

Tool

A function or API endpoint that an agent calls programmatically during task execution. Has typed inputs and outputs.

Hook

A lifecycle event handler that fires automatically at defined points in the agent runtime — session start, tool use, compaction, and more.

MCP Server

A Model Context Protocol service packaged as a distributable volume component. Runs as a long-running process.

LSP Server

A Language Server Protocol service that provides code intelligence and editor integration when loaded by a compatible runtime.

​
Export model

A volume exports components by declaring them in volume.toml and placing their entrypoint files at the declared paths. Three rules govern every exported component:
  1. Every exported component must be listed in volume.toml under [[components]].
  2. Every declared component must have a valid entrypoint file at the specified path.
  3. Component names must be unique within a volume across all component types.
Each [[components]] entry requires three fields:
FieldTypeDescription
typestringOne of: agent, skill, command, tool, hook, mcp-server, lsp-server.
namestringLowercase alphanumeric + hyphens. Unique within the volume.
entrypointstringRelative path from the volume root to the component’s entry file.
Two optional fields are supported for all component types:
FieldTypeDescription
descriptionstringOne-line description.
providersarray of stringsExternal services integrated by the component.
[[components]]
type = "skill"
name = "summarize-paper"
entrypoint = "./skills/summarize-paper/SKILL.md"
description = "Summarize academic papers with structured extraction"

[[components]]
type = "tool"
name = "arxiv-search"
entrypoint = "./tools/arxiv-search.json"
description = "Search arXiv for papers by query, author, or category"
The spec recommends organizing your volume with a dedicated directory per component type. This layout is a convention, not a requirement — the entrypoint path in volume.toml is authoritative. 
volume-root/
├── volume.toml
├── README.md
├── LICENSE
├── agents/
├── skills/
├── commands/
├── tools/
├── hooks/
├── .mcp.json
├── .lsp.json
└── scripts/

​
Entrypoint resolution

When a runtime or validator loads a component, it follows a three-level precedence chain:
SourcePrecedence
volume.toml [[components]] entryHighest — authoritative for package-level metadata
Entrypoint frontmatter or descriptorSecond — authoritative for component-level content metadata
Inferred defaultsLowest
The minimum a portable validator checks before passing a component to a runtime adapter is type-specific. For Markdown-based types, the entrypoint must exist and have a supported extension. For JSON-based types (mcp-server, lsp-server), the file must exist, be valid JSON, and parse to an object. For command, the frontmatter must include a valid trigger. For hook, the descriptor must declare a canonical lifecycle event and a valid hook type.
Entrypoint paths must be relative to the volume root. Absolute paths, paths containing .. segments, and paths that resolve outside the volume root are all validation failures.