Skip to main content
Glama
conan-io

Conan MCP Server

Official
by conan-io

list_conan_packages

Find Conan packages across remotes using name patterns, version ranges, and filters for settings and options.

Instructions

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"])

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesPackage name pattern (supports wildcards)
versionNoVersion or version range to search for.*
userNoUser name. Use * to search all users.
channelNoChannel name. Use * to search all channels.
recipe_revisionNoRecipe revision number also know as rrev. Use * to search all revisions. Use "latest" to search the latest revision.
package_idNoPackage ID. Use * to search all packages.
filter_settingsNoFilter settings like architecture, operating system, build type, compiler, compiler version, compiler runtime, compiler runtime version.
filter_optionsNoFilter options like fPIC, header_only, shared, with_*, without_*, etc.
remoteNoName of the remote to search in.*
search_in_cacheNoInclude local cache in search
include_all_package_revisionsNoInclude all package revisions
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.

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