Skip to main content
Batch imports reduce repetition when importing several declarations from the same MCP server namespace. They are most useful when a workflow uses many capabilities from one server and you want consistent naming and shared bindings.

​
Tool-only imports

When the source path ends in .tool, every entry inside the block must be a tool. 
from mcp.tasks.tool {
    tool fetch_task
    tool update_task_status
    tool create_comment
}

​
Prompt-only imports

When the source path ends in .prompt, every entry inside the block must be a prompt. 
from mcp.tasks.prompt {
    prompt task_writer_instructions
    prompt task_review_checklist
    prompt escalation_template
}

​
Resource-only imports

When the source path ends in .resource, every entry inside the block must be a resource. 
from mcp.tasks.resource {
    resource project_readme
    resource task_template
}

​
Mixed imports

When importing from the broader MCP server namespace, the block may contain tools, prompts, and resources. 
from mcp.tasks {
    prompt task_writer_instructions
    tool update_task_status
    resource project_readme
}

​
Shared bindings

A batch import can apply the same bindings to multiple imported tools when those tools need the same trusted runtime values. 
from mcp.tasks.tool {
    bindings {
        workspace_id: input.workspace_id
        project_id: input.project_id
    }

    tool fetch_task
    tool update_task_status
    tool create_comment
}
bindings {} assigns runtime values. It is not a schema declaration.
  • Keep import blocks close to related mcp declarations.
  • Use clear local names for imported capabilities.
  • Apply shared bindings {} only when all imported tools truly need the same trusted values.
  • Prefer explicit individual imports when one tool needs different bindings or contract overrides.