Tools

Overview

Decopilot uses two types of tools: built-in tools for discovering capabilities and managing work, and scope tools from the current scope for domain-specific actions. Scope tools are available based on the connections in the current scope’s Virtual MCP — decopilot sees them listed in its system prompt.

Tool Reference

Built-in Tools

All built-in tools are available across all scopes. Availability varies between tasks and subtasks.

Scope Tools

Scope tools come from the current scope—domain-specific capabilities like Shopify, inventory systems, or shipping tools. These are available based on the connections configured in the scope’s Virtual MCP.

Example: A project with Shopify and ShipStation connections might expose:

• GET_ORDERS - Fetch customer orders
• UPDATE_INVENTORY - Update product stock levels
• CREATE_SHIPPING_LABEL - Generate shipping labels
• GET_PRODUCTS - List product catalog

Scope tool availability in tasks vs subtasks depends on the tool’s configuration.

Tool Annotations

All tools (both built-in and scope tools) use standard MCP annotations to declare their capabilities and restrictions:

• readOnlyHint - Tool does not modify its environment (default: false)
• destructiveHint - Tool may perform destructive updates vs. only additive updates (default: true, only meaningful when readOnlyHint is false)
• idempotentHint - Calling repeatedly with same arguments has no additional effect (default: false, only meaningful when readOnlyHint is false)
• openWorldHint - Tool may interact with external entities; false means closed domain (default: true)

These annotations allow decopilot to respect tool constraints automatically. For example, a read-only agent will only discover and enable tools marked as readOnlyHint: true , ensuring it never performs destructive actions.

Understanding Availability

Tasks vs Subtasks

Tasks are user-initiated and top-level. They have full access to all built-in tools, can spawn subtasks, and can ask user questions.

Subtasks are spawned by decopilot for parallel work, specialized execution, or isolated context. They have restricted access:

• Cannot spawn additional subtasks - Prevents infinite delegation
• Cannot ask user questions - Subtasks run autonomously without blocking
• Step limit of 15 (vs parent’s 30) - Ensures subtasks stay focused
• Must return a summary - Results flow back to the parent task

These restrictions ensure subtasks complete independently and don’t create blocking dependencies.

Tool Discovery Flow

Decopilot starts each task with only built-in tools, then discovers and enables capabilities as needed:

1. Explore - Scope tools are listed in the system prompt based on the current Virtual MCP
2. Execute - Use available tools to accomplish work
3. Delegate - Spawn subtasks via subtask for parallel or specialized work
4. Read context - Use read_resource and read_prompt to load domain knowledge

Common Workflows

Execute Scope Tools

The most common pattern for using scope tools:

1. Review available tools from the current scope
2. Use tools to accomplish the requested work
3. Read resources/prompts for domain context when needed

Delegate to Specialists

For work requiring specialized expertise:

1. Search for agents with agent_search
2. Spawn a subtask with subtask and specific agent
3. Continue main task while subtask runs in parallel

Context-Driven Execution

For tasks requiring domain knowledge:

1. Read relevant resources with read_resource
2. Read workflow templates with read_prompt
3. Use context to inform tool selection and execution

---

Next steps: Learn about Tasks and Spawning to understand how decopilot manages work, or explore Context to see how resources and prompts provide guidance.

For technical tool documentation, see Built-in Tools Reference.