Which integrations are available for this server?

Provides tools for creating Conan projects with dependencies, listing and searching Conan packages, installing dependencies, scanning for vulnerabilities, and collecting license information.

How do I use Conan MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Conan MCP Server Create a CMake library project with fmt and openssl dependencies." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Conan MCP Server

Official

by conan-io

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Conan MCP Server

A Model Context Protocol server for Conan package manager integration.

Usage Examples

"Create a CMake library project with Conan that has the latest version of fmt and openssl as requirements, install the dependencies and verify that the libraries I depend on don't have serious vulnerabilities and have a license that allows my application to be commercial."

Related MCP server: CodeAlive MCP

Installation

Requirements

Python >= 3.10
Conan installed

MCP Configuration

Add to your mcp.json:

{
  "mcpServers": {
    "conan": {
      "command": "uvx",
      "args": ["conan-mcp"]
    }
  }
}

Note: uvx is provided by uv. If you don't have uv installed, you can install it or use pip install conan-mcp and then use conan-mcp directly as the command.

Configuring Conan Binary Path

By default, the server uses conan from the system PATH (or the virtual environment where the MCP server is running). If you need to use a specific Conan installation or version, you can set the CONAN_MCP_CONAN_PATH environment variable in your MCP configuration:

{
  "mcpServers": {
    "conan": {
      "command": "uv",
      "args": ["--directory", "/path/to/conan-mcp", "run", "conan-mcp"],
      "env": {
        "CONAN_MCP_CONAN_PATH": "/home/user/venv/bin/conan"
      }
    }
  }
}

If CONAN_MCP_CONAN_PATH is not set, the server will use conan from PATH or the virtual environment where the MCP server is running.

Available Tools

get_conan_profile:

Get Conan profile configuration

Parameters:

profile (optional): If provided, show that specific profile; otherwise, default

Usage examples:

"What is my default Conan profile?"
"Show me the linux-debug profile configuration"

list_conan_profiles

List available Conan profiles

Parameters:

No parameters

Usage examples:

"What Conan profiles do I have available?"

create_conan_project

Create a new Conan project with specified dependencies

Parameters:

template (required): Template type for the project.
- Libraries: cmake_lib (default), header_lib, meson_lib, msbuild_lib, bazel_lib, autotools_lib
- Executables: cmake_exe (default), meson_exe, msbuild_exe, bazel_exe, autotools_exe
name (required): Name of the project
version (optional): Version of the project (default: "0.1")
requires (optional): List of dependencies with versions (e.g., ["fmt/12.0.0", "openssl/3.6.0"])
tool_requires (optional): List of tool dependencies (e.g., ["cmake/4.1.2", "ninja/1.13.1", "meson/1.9.1"])
work_dir (required): Working directory where the command should be executed. The project will be created directly in this directory.
force (optional): Overwrite existing files if they exist (default: False)

Usage examples:

"Create a new CMake executable project called 'myapp' with fmt and openssl dependencies"
"Create a header-only library project called 'mylib'"
"Create a Meson executable project with gtest and spdlog dependencies"
"Create a CMake library project with boost dependencies and cmake tool_requires"

list_conan_packages

List recipes and packages from the local cache or configurated remotes

Parameters:

name (required): Package name.
version (optional): Version or version range.
user (optional): User name to search.
channel (optional): Channel name to search.
recipe_revision (optional): Recipe revision (rrev). Use "*" for all, "latest" for latest.
package_id (optional): Package ID. Use "*" for all packages.
filter_settings (optional): List of setting filters. E.g. ["arch=armv8", "os=Windows"].
filter_options (optional): List of option filters. E.g. ["*:fPIC=True", "*:shared=False"].
remote (optional): Remote name to search in. Use "*"for all.
search_in_cache (optional): Whether to include the local cache in the search.

Usage examples:

"List all available versions for fmt in conancenter"
"List versions of zlib with architecture armv8 and shared=False"
"Show all zlib packages for Windows armv8 in my local cache"
"List all packages that contain boost in the name in conancenter"
"Search for fmt versions greater than or equal to 8.0 but less than 9.0 in conancenter"
"Search for zlib versions compatibles with 1.3.x in every remote"
"List versions of poco provided by user barbarian and channel stable in local cache"
"Provide all packages for zlib 1.3 that use the recipe at revision b3b71bfe8dd07abc7b82ff2bd0eac021 in conancenter"

install_conan_packages

Install all dependencies of a Conan recipe, producing a full dependency graph.

Parameters:

path (required): Path to the folder containing the recipe, or to a conanfile.txt or conanfile.py. This path is ALWAYS relative to work_dir.
work_dir (required): Working directory where the command should be executed. This is the base directory from which all paths are resolved.
remote (optional): Name of the remote to search for dependencies. If omitted, all remotes are searched.
search_in_cache (optional): Do not use remote, resolve exclusively in the cache.
settings_host (optional): List of settings (host context) to override. Example: ["arch=armv8", "os=Windows", "build_type=Release"]
options_host (optional): List of options (host context) to override. Example: ["fPIC=True", "shared=False"]
build_missing (optional): Boolean, build missing binary dependencies from source if not available (false by default).

Usage examples:

"Install dependencies in this project using conancenter"
"Install dependencies from ~/project for architecture armv8, and shared=False build the missing binaries"
"Install dependencies in this project use windows profile for host and linux profile for build"

get_conan_licenses

Collect license information for Conan package dependencies. This tool uses conan graph info to extract license information from the dependency graph for all packages.

Only packages in the "host" context are analyzed (build context packages are excluded as they are build-time tools and not included in the final product).

Parameters:

work_dir (required): Working directory where the command should be executed. This is the base directory from which all paths are resolved.
path (required): Path to the folder containing the recipe, or to a conanfile.txt or conanfile.py. This path is ALWAYS relative to work_dir.
remote (optional): Name of the remote to search for dependencies. If omitted, all remotes are searched.
build_profile (optional): Profile to the build context.
host_profile (optional): Profile to the host context.

Usage examples:

"Collect license information for dependencies in this project"
"Get all licenses from my project dependencies"
"Collect license information for conanfile.py in ~/my_project using the windows profile"

scan_conan_dependencies

Scan Conan packages and dependencies for security vulnerabilities

Parameters:

work_dir (required): Working directory where the command should be executed. This is the base directory from which all paths are resolved.
path (optional): Path to the folder containing the recipe or to a conanfile.txt/conanfile.py. This path is ALWAYS relative to work_dir.
reference (optional): Conan reference of a specific package to audit, e.g. "fmt/12.0.0". Use this instead of path to audit only a specific package and not its dependencies.

Note: path and reference are mutually exclusive. Only one of them should be provided at a time.

Usage examples:

"Scan dependencies in this project for known vulnerabilities"
"Scan the latest version of zlib for vulnerabilities"

Local Development

Clone and run

# Clone the repository
git clone https://github.com/conan-io/conan-mcp.git
cd conan-mcp

# Install dependencies
uv sync

# Run the server
uv run conan-mcp

Local MCP configuration

For local development, use the absolute path:

{
  "mcpServers": {
    "conan": {
      "command": "uv",
      "args": ["--directory", "/absolute/path/to/conan-mcp", "run", "conan-mcp"]
    }
  }
}

Testing with MCP Inspector

You can test the server using the MCP Inspector to verify it's working correctly:

uv run mcp dev main.py

Running Conan MCP Server tests

See test/README.md for detailed testing instructions.

License

MIT License

Available Tools

7 tools

create_conan_projectA

Create a new Conan project with specified dependencies.

This tool creates a new Conan project using templates and automatically adds
the specified dependencies. Useful for setting up new projects with common
libraries like fmt, openssl, boost, etc.

Note: The generated code contains placeholder examples. You need to review
and update: includes/imports, source code usage, and build system targets
(CMakeLists.txt, meson.build, etc.) to properly use your specified dependencies.

Args:
    template: Template type for the project.
              
              Libraries (produce libraries to be linked):
              - cmake_lib: CMake library (default for libraries)
              - header_lib: Header-only library
              - meson_lib: Meson build system
              - msbuild_lib: Visual Studio / MSBuild (Windows only)
              - bazel_lib: Bazel build system (experimental)
              - autotools_lib: Autotools (configure/make)
              
              Executables (programs that can be run):
              - cmake_exe: CMake executable (default for executables)
              - meson_exe: Meson build system
              - msbuild_exe: Visual Studio / MSBuild (Windows only)
              - bazel_exe: Bazel build system (experimental)
              - autotools_exe: Autotools (configure/make)
              
              Note: If the user doesn't specify build system, use cmake_lib
              for libraries or cmake_exe for executables as defaults.
    name: Name of the project
    version: Version of the project (default: "0.1")
    requires: List of dependencies with versions (e.g., ['fmt/12.0.0', 
              'openssl/3.6.0'])
    tool_requires: List of tool dependencies with versions. Common examples:
                  - ['cmake/4.1.2'] - CMake build tool
                  - ['ninja/1.13.1'] - Ninja build system
                  - ['meson/1.9.1'] - Meson build system
    work_dir: Working directory where the command should be executed. 
             The project will be created directly in this directory.
             Always required.
    force: Overwrite existing files if they exist (default: False)

Returns:
    Dictionary containing:
    - result: Success message with project details, dependency note, and 
              raw output from the conan new command

ParametersJSON Schema

Name	Required	Description	Default
`template`	Yes	Template type for the project. If not specified, use cmake_lib for libraries or cmake_exe for executables
`name`	Yes	Name of the project
`version`	No	Version of the project	0.1
`requires`	No	List of dependencies with versions
`tool_requires`	No	List of tool dependencies with versions. Common examples: ['cmake/4.1.2'], ['ninja/1.13.1'], ['meson/1.9.1']
`work_dir`	Yes	Working directory where the command should be executed. The project will be created directly in this directory. Always required.
`force`	No	Overwrite existing files if they exist

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It reveals that generated code contains placeholder examples requiring user review, and the force parameter controls overwriting. It also specifies where the project is created (work_dir). No contradictions.

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 front-loaded purpose, a note section, and clear 'Args' and 'Returns' sections. It is somewhat verbose but includes necessary details for template options and examples, earning its sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description documents the return dictionary. It covers all 7 parameters with detailed explanations, behavioral notes, and usage context. Minor omission: does not mention prerequisites like having Conan installed, but overall complete for a creation 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 beyond schema by categorizing template types (libraries vs executables) and providing default choices. It also gives common examples for tool_requires, enhancing understanding.

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 the tool creates a new Conan project with specified dependencies. It distinguishes itself from siblings by focusing on project creation, while siblings like install_conan_packages or list_conan_packages handle other lifecycle tasks.

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 it is useful for setting up new projects with common libraries and includes a note about placeholder examples requiring user updates. However, it does not explicitly state when not to use this tool or mention alternative siblings for specific scenarios.

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

get_conan_licensesA

Collect license information for Conan package dependencies.

This tool uses `conan graph info` to extract license information from the dependency
graph for all packages.

Only packages in the "host" context are analyzed (build context packages are excluded
as they are build-time tools and not included in the final product).

You can either provide a path to a conanfile OR a list of package references to check.
At least one of these must be provided.

Use this tool when you need to:
- Search for licenses of the project
- Extract license information
- Check license information 

Examples:
    - get_conan_licenses(work_dir="/home/user/project", path="conanfile.py")
    - get_conan_licenses(work_dir="~/my_project", path="conanfile.txt")
    - get_conan_licenses(work_dir="/tmp", requires=["zlib/1.2.11"])
    - get_conan_licenses(work_dir="/tmp", requires=["zlib/1.2.11", "fmt/10.0.0"])

Args:
    work_dir: Working directory where the command should be executed.
              This is the base directory from which all paths are resolved.
              Always required.
    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. Optional if requires is provided.
    requires: List of package references to check licenses for (e.g., ["zlib/1.2.11", "fmt/10.0.0"]).
              Each reference will be passed as a --requires flag to conan graph info.
              Optional if path is provided. At least one of path or requires must be provided.
    remote: Optional remote name to search in (searches all remotes if not specified)
    build_profile: Profile to the build context.
    host_profile: Profile to the host context.

Returns:
    List of dictionaries, each containing:
    - "ref": Package reference (string)
    - "licenses": List of license strings (always a list, empty if no license specified)

ParametersJSON Schema

Name	Required	Description
`work_dir`	Yes	Working directory where the command should be executed. This is the base directory from which all paths are resolved. Always required.
`path`	No	Path to the folder containing the recipe of the project or to a recipe file conanfile.txt/.py. Optional if requires is provided.
`requires`	No	List of package references to check licenses for (e.g., ['zlib/1.2.11', 'fmt/10.0.0']). Each reference will be passed as a --requires flag. Optional if path is provided.
`remote`	No	Remote name. Omit to search in all remotes.
`build_profile`	No	Profile to the build context.
`host_profile`	No	Profile to the host context.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that only host context packages are analyzed, that licenses are always returned as a list, and that the tool uses 'conan graph info'. It does not mention side effects, but as a read-only query tool, this is acceptable.

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 headings, examples, and a parameter list. While slightly verbose in places (e.g., repeating 'collect license information'), the information density is high and every sentence contributes to clarity.

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 tool's complexity (6 parameters with mutual exclusivity), the description is comprehensive: it explains usage, provides examples, and details the return value structure. The output schema is described textually, fulfilling completeness for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema coverage, the description adds significant value by explaining parameter relationships (e.g., mutual exclusivity of 'path' and 'requires'), clarifying relative path resolution, and providing concrete examples. The description goes well beyond the schema's attribute 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 the tool collects license information for Conan dependencies, specifies the use of 'conan graph info', and distinguishes by noting only host context packages are analyzed. It provides specific use cases like 'Search for licenses of the project' and 'Extract license information', leaving no ambiguity about its purpose.

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 explicitly states when to use the tool ('Use this tool when you need to: ...') and provides multiple examples. While it doesn't explicitly mention when not to use it or compare to siblings, the context is clear enough for an agent to infer appropriate usage.

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

get_conan_profileA

Get Conan profile configuration.

This tool should be called when the user mentions:
- Their platform (Windows, macOS, Linux)
- Their compiler (gcc, clang, msvc, etc.)
- Their architecture (x86_64, arm64, etc.)
- Build configurations
- When they want to list packages for their specific platform
- When they need context about their Conan environment
- When they want to check a specific profile configuration

This is typically a prerequisite step before listing packages or making 
platform-specific recommendations, as it provides essential context about
the user's build environment.

Args:
    profile: Optional profile name to retrieve. If not specified, retrieves the default profile.

Returns:
    Dictionary containing both host and build profile configurations.
    The dictionary structure includes:
    - "host": Host profile settings (compiler, arch, build_type, etc.)
    - "build": Build profile settings (compiler, arch, build_type, etc.)
    - Additional configuration like package_settings, options, tool_requires, etc.

ParametersJSON Schema

Name	Required	Description	Default
`profile`	No	Specific profile name to retrieve. If not provided, uses the default profile.

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so the description carries full burden. It discloses the return structure (dictionary with host/build configs) and that it retrieves a profile. However, it does not mention potential failure modes (e.g., profile not found) or side effects, but these are minor for a simple getter.

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 a lead sentence, use-case list, parameter doc, and return explanation. It is slightly verbose (the bullet list of triggers could be condensed) but still earns its content.

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 no output schema, the description fully explains the return dictionary structure. It also provides context on when and why to use the tool. The single optional parameter is well-documented, and the tool's role as a prerequisite is clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description in the schema is nearly identical to the one in the main description ('Optional profile name...'). The description adds no significant additional semantics beyond what the schema provides, so baseline 3 is appropriate.

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 'Get Conan profile configuration,' a specific verb+resource. It distinguishes from siblings like list_conan_profiles by explaining it retrieves a specific profile (or default) and is a prerequisite for platform-specific operations.

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?

Explicitly lists multiple trigger scenarios (platform, compiler, architecture, build configs, listing packages, environment context) and positions it as a prerequisite step. This provides clear guidance on when to use versus alternatives.

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

install_conan_packagesA

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)

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Path to the folder containing the recipe of the project or to a recipe file conanfile.txt/.py
`work_dir`	Yes	Working directory where the command should be executed. This is the base directory from which all paths are resolved. Always required.
`remote`	No	Remote name. Omit to search in all remotes.
`search_in_cache`	No	Do not use remote, resolve exclusively in the cache.
`build_profile`	No	Profile to the build context.
`host_profile`	No	Profile to the host context.
`settings_host`	No	Apply different settings like architecture, operating system, build type, compiler,
`options_host`	No	Apply options like fPIC, header_only, shared, with_, without_, etc. to the host context only.
`build_missing`	No	Build all the missing binary dependencies when they are not available in the cache or in the remotes for download.

TDQS

A4.4/5.0

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.

list_conan_packagesA

Search for Conan packages across remotes with fine-grained filtering.

Use this tool when you need to:
- Check available versions of dependencies
- Find the latest version of a package
- Search for packages by name
- Search for packages by version or version range
- Search for packages and filter them using filter settings or filter options
- Search for package specifying package ID, or recipe revision

 Examples:
 - list_conan_packages(name="fmt", version="1.0.0") - List all available versions for fmt/1.0.0 package.
 - list_conan_packages(name="fmt", filter_settings=["arch=armv8"]) - List all available versions for fmt package with architecture armv8
 - list_conan_packages(name="fmt", filter_options=["*:fPIC=True"]) - List all available versions for fmt package with fPIC

Args:
    name: Package name pattern (required). Supports wildcards:
        - "fmt" : exact name
        - "fmt*" : starts with "fmt"
        - "*fmt*" : contains "fmt"
        - "*fmt" : ends with "fmt"
    version: Version or version range (default: "*"). Supports Conan2 syntax:
        - "1.2.3" : exact version
        - "[>=1.0 <2.0]" : range >=1.0 and <2.0
        - "[~1.2]" : compatible with 1.2.x
        - "[^1.0]" : compatible up to next major
        - "[>1 <2.0 || ^3.2]" : multiple ranges
    user: User name (default: None). Use "*" for all users.
    channel: Channel name (default: None). Use "*" for all channels.
    recipe_revision: Recipe revision (rrev) (default: None). 
        Use "*" for all, "latest" for latest.
        Use it together with package_id to find all packages with the same recipe revision.
    package_id: Package ID (default: None). Use "*" for all packages.
        Use "*" when you are trying to find all packages.
        Use it together with include_all_package_revisions to include all package revisions.
    filter_settings: Filter by settings (default: None). List of strings:
        Pass as list of strings, 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
    filter_options: Filter by options (default: None). List of strings:
        Pass as list of strings, e.g. ["*:fPIC=True", "*:header_only=True", "*:shared=False", "*:with_boost=True"]
        - ["*:fPIC=True"] : fPIC option
        - ["*:header_only=True"] : header only
        - ["*:shared=False"] : shared library
        - ["*:with_boost=True"] : with boost option
    remote: Remote name (default: "*"). 
        - None: Search in local cache only
        - "conancenter": Search in ConanCenter remote
        - "*": Search in all remotes
        - Other remote names: Search in specific remote
    search_in_cache: Include local cache in search (default: False). 
        - True: Search in both remotes and local cache
        - False: Search only in remotes (default)
        Note: This parameter should be set consistently across requests.
    include_all_package_revisions: Include all package revisions (default: False). 
        - True: Include all package revisions.
        - False: Include only the latest package revision (default)

Returns:
    Dictionary containing available packages and their metadata.

 Examples:
     - list_conan_packages(name="fmt", version="1.0.0")
     - list_conan_packages(name="*boost*", filter_settings=["arch=armv8", "os=Windows"])
     - list_conan_packages(name="zlib", filter_options=["*:shared=True"])

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Package name pattern (supports wildcards)
`version`	No	Version or version range to search for.	*
`user`	No	User name. Use * to search all users.
`channel`	No	Channel name. Use * to search all channels.
`recipe_revision`	No	Recipe revision number also know as rrev. Use * to search all revisions. Use "latest" to search the latest revision.
`package_id`	No	Package ID. Use * to search all packages.
`filter_settings`	No	Filter settings like architecture, operating system, build type, compiler, compiler version, compiler runtime, compiler runtime version.
`filter_options`	No	Filter options like fPIC, header_only, shared, with_, without_, etc.
`remote`	No	Name of the remote to search in.	*
`search_in_cache`	No	Include local cache in search
`include_all_package_revisions`	No	Include all package revisions

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It describes the search scope (remotes, cache), the effect of parameters like 'search_in_cache' (should be consistent), and the return type (dictionary). However, it lacks disclosure of potential side effects (though likely none), authentication needs, or behavior on errors (e.g., remote unavailable), leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections (purpose, use cases, args, returns, examples) but is verbose, especially in listing every possible filter setting/option value and repeating examples at the end. It could be more concise without losing clarity, making it less ideal for quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high parameter count (11), no output schema, and no nested objects, the description provides rich parameter documentation and a vague but acceptable return description ('Dictionary containing available packages and their metadata'). The examples cover several parameter combinations, ensuring the agent can effectively use the tool. Minor gaps: return structure is unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, providing a baseline of 3. The description adds substantial value beyond the schema: it explains wildcard syntax for 'name', Conan2 version range syntax for 'version', examples for filter_settings and filter_options, and the nuanced behavior of 'remote' and 'search_in_cache'. This goes well beyond simply restating schema information.

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 starts with a clear verb-resource pair: 'Search for Conan packages across remotes with fine-grained filtering.' It lists specific use cases (check versions, find latest, search by name/version/filter) and provides examples, making the purpose unambiguous and distinguishing it from sibling tools like install_conan_packages.

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 explicitly states when to use the tool through a bulleted list of use cases ('Check available versions', 'Find the latest version', etc.) and provides numerous examples. However, it does not explicitly mention when not to use it or point to alternatives, which would be helpful given the sibling tools exist for installation or scanning.

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

list_conan_profilesA

List Conan profiles available.

Use this tool to see which profiles are available to select or inspect.

Returns:
    List of profile names.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description must carry the burden. It states the tool is for inspection and returns a list of profile names, implying no destructive actions. It could explicitly state it is read-only, but given the simplicity, it is adequately transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short but slightly repetitive (first sentence restates the title-like phrase, then repeats the purpose). The format is clear with a 'Returns:' section, but it could be more concise by merging the first two sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema exists (though not shown), the description provides the essential information: what it does and what it returns. For a simple list operation, it is sufficiently complete.

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?

There are no parameters (0 parameters, 100% schema coverage). The baseline for 0 parameters is 4. The description adds no parameter insight because none exist, which is appropriate.

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 the tool lists Conan profiles. It uses a specific verb-resource combination ('List Conan profiles') and distinguishes itself from sibling tools like 'get_conan_profile' by indicating it returns all available profiles or inspection.

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 explicitly says to use this tool to see which profiles are available for selection or inspection, giving clear guidance on when to use it. However, it does not explicitly mention when not to use it or compare to alternatives like 'get_conan_profile'.

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

scan_conan_dependenciesA

⚠️ WARNING: This tool makes an API call to audit.conan.io service. Only use when explicitly requested by the user.

Requires provider authentication. If you dont have any yet you can get a token by signing up for a free at https://audit.conan.io/register

Audit a Conan project or a specific package for security vulnerabilities using the audit.conan.io service.
When using path: Scans the conanfile and all its transitive dependencies for vulnerabilities.
When using reference: Scans only the vulnerabilities of that specific package reference, but NOT its dependencies.

There is a limit of 100 API calls per day. If the limit is reached, the tool will return an error.
Use path to scan the complete graph of dependencies. Use reference to audit a specific package.
Do not use both path and reference at the same time.

Args:
    work_dir: Working directory where the command should be executed. Always required.
    path: This path is ALWAYS relative to work_dir. For example, if work_dir is "/home/user/project" and path is "conanfile.txt", it will resolve to "/home/user/project/conanfile.txt". When using path, all transitive dependencies will be scanned for vulnerabilities.

    reference: Conan reference to audit. For example, "fmt/12.0.0". Use it in case the user provides a specific reference to audit. Use it instead of path. When using reference, only the vulnerabilities of that specific package reference will be scanned, but NOT its dependencies.
Returns:
    Dictionary containing the result of the audit scan.

ParametersJSON Schema

Name	Required	Description
`work_dir`	Yes	Working directory where the command should be executed. Always required.
`path`	No	Path to the folder relative to working directory containing the recipe of the project or to a recipe file conanfile.txt/.py
`reference`	No	Conan reference to audit. For example, 'fmt/12.0.0'.

TDQS

A4.6/5.0

Behavior4/5

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

Describes external API call to audit.conan.io, requires authentication, and has a 100-call-per-day limit. Missing explicit statement that the tool is read-only (non-destructive), but the scanning action implies it. Good disclosure for a tool with no annotations.

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?

Well-structured with a prominent warning, then authentication info, then usage guidance and parameter details. Slightly verbose but every part adds context. Front-loading the warning is effective. Could trim some redundancy (e.g., parameter descriptions partly duplicate schema) but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, parameters, external dependencies, rate limits, and return type (dictionary). Lacks specifics about the dictionary contents and error handling. For a tool with no output schema, this is fairly complete but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema already describes parameters (100% coverage), the description adds significant value: explains mutual exclusivity of path and reference, how path resolves relative to work_dir, and gives example for reference. This goes well beyond the schema's basic 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?

Clearly states the tool audits Conan projects or packages for vulnerabilities using audit.conan.io. Distinguishes two modes (path vs reference) and explains what each does. Siblings are unrelated (create, install, list, etc.), so the tool stands out as the scanning tool.

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?

Explicitly tells when to use path vs reference, and warns not to use both simultaneously. Also includes authentication requirement and API rate limit, guiding the agent on constraints. This is exemplary usage guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jun 21, 2026
- First observedcreate_conan_project
- First observedget_conan_licenses
- First observedget_conan_profile
- First observedinstall_conan_packages
- First observedlist_conan_packages
- First observedlist_conan_profiles
- First observedscan_conan_dependencies

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Scored 2026-06-21 09:00 across 7 tools

Disambiguation5/5

Each tool targets a distinct operation: project creation, dependency installation, package search, profile listing, profile details, license extraction, and security scanning. There is no functional overlap; the descriptions clearly differentiate their purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase snake_case (e.g., create_conan_project, list_conan_packages). The pattern is uniformly applied across all seven tools.

Tool Count5/5

With seven tools, the server covers the essential workflows for Conan package management without being excessive or insufficient. The scope is well-defined and each tool earns its place.

Completeness4/5

The tool surface covers project creation, dependency installation, package search, profile management, license information, and security auditing. Missing are build/export operations, but the core lifecycle is addressed, and the gaps are minor.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
ChiR24-unreal_mcp_serverOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
Developer Tools App Automation Software Architecture
2859
Sentry AOAuth
dev.sentry.mcp
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Monitoring Developer Tools Observability
3

Related MCP Servers

CodeAnalysis MCP Server
Code Analysis Developer Tools Documentation Access
0xjcf
F
license
D
quality
D
maintenance
A comprehensive Model Context Protocol server for advanced code analysis that provides tools for syntax analysis, dependency visualization, and AI-assisted development workflow support.
Updated 8 months ago (2026-01-20 23:07 UTC)
28
7
-
CodeAlive MCPofficial
Code Analysis RAG Systems Developer Tools
CodeAlive-AI
A
license
Not graded
quality
A
maintenance
A Model Context Protocol server that enhances AI agents by providing deep semantic understanding of codebases, enabling more intelligent interactions through advanced code search and contextual awareness.
Updated 24 days ago (2026-08-16 13:58 UTC)
89
MIT
MCP Python Interpreter
PortPro-Technologies-Inc
-
license
A
quality
Not graded
maintenance
A Model Context Protocol server that allows LLMs to interact with Python environments, enabling code execution, file operations, package management, and development workflows.
Updated a year ago (2025-06-14 11:15 UTC)
9
-
MCP Dev Standards
Developer Tools Documentation Access
han0420
A
license
A
quality
D
maintenance
A Model Context Protocol server that provides development standards and best practices context to AI coding assistants, ensuring generated code adheres to team/project conventions.
Updated 9 months ago (2025-12-23 12:05 UTC)
3
18
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

Conan MCP Server

Usage Examples

Installation

Requirements

MCP Configuration

Configuring Conan Binary Path

Available Tools

Local Development

Clone and run

Local MCP configuration

Testing with MCP Inspector

Running Conan MCP Server tests

License

Available Tools

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

CodeAlive MCPofficial

Latest Blog Posts

MCP directory API