Skip to main content
Glama
conan-io

Conan MCP Server

Official
by conan-io

install_conan_packages

Install package dependencies from a Conan recipe file, resolving the full dependency graph and fetching binaries from cache or remotes.

Instructions

Install Conan package dependencies from a recipe file (conanfile.py or conanfile.txt).

This tool uses the `conan install` command to install the dependencies of a Conan recipe.
It provides a complete, structured view of all nodes and relationships in the dependency graph.

If any requirement is not found in the local cache, it will iterate the remotes looking for it.
When the full dependency graph is computed and all dependency recipes have been found, it will look
for binary packages matching the current settings and options. If no binary package is found for
some dependencies, it will error unless the 'build_missing' argument is used to build from source.

Examples:
    - install_conan_packages(work_dir="/home/user/project", path="conanfile.txt")
    - install_conan_packages(work_dir="~/my_project", path="conanfile.py", remote="conancenter")
    - install_conan_packages(work_dir="/home/user/project", path="conanfile.py",
                            settings_host=["os=Windows", "arch=armv8"])

Args:
    path: Path to a folder containing a recipe or to a recipe file (conanfile.txt or conanfile.py).
          This path is ALWAYS relative to work_dir. For example, if work_dir is "/home/user/project" 
          and path is "conanfile.py", it will resolve to "/home/user/project/conanfile.py".
    work_dir: Working directory where the command should be executed. 
             This is the base directory from which all paths are resolved.
             Always required. If the user mentions they are in a specific directory, use that.
    remote: Optional remote name to search in (searches all remotes if not specified)
    search_in_cache: Do not use remote, resolve exclusively in the cache.
    build_profile: Profile to the build context.
    host_profile: Profile to the host context.
    settings_host: Substitute settings from the default host profile (architecture, OS, etc.)
        Omit to use the settings of the default host profile.
        e.g. ["arch=armv8", "os=Windows", "build_type=Release"] 
        - "arch=armv8": architecture,
        - "os=Windows": operating system, 
        - "build_type=Release": build type,
        - "compiler=gcc": compiler,
        - "compiler.version=11": compiler version,
        - "compiler.runtime=libstdc++11": compiler runtime,
        - "compiler.runtime_version=11": compiler runtime version
    options_host: Substitute options from the default host profile (fPIC, shared, etc.)
        Omit to use the options of the default host profile.
        e.g. ["fPIC=True", "shared=False"]
        - "Use "&:fPIC=True" to refer to the current package. "
        - "Use "*:fPIC=True" or other pattern if the intent was to apply to dependencies"
        - "*:fPIC=True": fPIC for all packages,
        - "&:shared=False": shared for the current package,
        - "*:with_boost=True": with boost option for all packages,
    build_missing: Build missing binary dependencies from source

Returns:
    JSON string with dependency graph metadata including installation status for each package.

    The "binary" and "recipe" fields on each node indicate the package status:
    - Missing: Recipe/binary not found, needs to be built
    - Invalid: Package invalid due to recipe restrictions
    - Build: Package has been built
    - Cache: Recipe/binary exists in local cache
    - Skip: Package skipped from installation
    - Download: Recipe/binary was downloaded
    - null: Binary unknown (e.g., consumer conanfile.txt)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the folder containing the recipe of the project or to a recipe file conanfile.txt/.py
work_dirYesWorking directory where the command should be executed. This is the base directory from which all paths are resolved. Always required.
remoteNoRemote name. Omit to search in all remotes.
search_in_cacheNoDo not use remote, resolve exclusively in the cache.
build_profileNoProfile to the build context.
host_profileNoProfile to the host context.
settings_hostNoApply different settings like architecture, operating system, build type, compiler,
options_hostNoApply options like fPIC, header_only, shared, with_*, without_*, etc. to the host context only.
build_missingNoBuild all the missing binary dependencies when they are not available in the cache or in the remotes for download.
Behavior4/5

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

With no annotations, the description carries full burden. It details the dependency graph computation, remote iteration, binary matching, error conditions, and the use of build_missing. It also explains status fields. Lacks explicit mention of side effects on cache but is thorough overall.

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?

The description is well-structured with sections for behavior, examples, arguments, and returns. It is slightly lengthy but every section adds value. The purpose is front-loaded, and the formatting aids readability.

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?

Given the complexity (9 parameters), no output schema, and no annotations, the description covers all needed aspects: behavior, parameter details, examples, return format with status codes, and edge cases like build_missing and search_in_cache. An agent can reliably select and invoke this tool.

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. The description adds value by clarifying path is relative to work_dir, work_dir is always required, and provides detailed examples and patterns for settings_host and options_host, going beyond the schema descriptions.

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?

The description clearly states it installs Conan package dependencies from a recipe file (conanfile.py or conanfile.txt), using the 'conan install' command. This specific verb+resource combination distinguishes it from sibling tools like list_conan_packages or scan_conan_dependencies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (installing dependencies from a recipe) and provides context on behavior like searching remotes and handling missing binaries. It does not explicitly state when not to use it or compare to alternatives, but the context is clear enough.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/conan-io/conan-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server