AutoGineer
Generated banner for Doca Caps
Generated logo for Doca Caps

Doca Caps

NVIDIAOfficialCreated by NVIDIA

  • Skill
  • Tool integration
  • Software development
  • Apache-2.0
  • Medium risk
Download ZIP

From the author

Use this skill when the user wants to invoke the read-only doca_caps CLI to ask what DOCA sees on this host — listing DOCA devices and PCIe addresses, listing representor devices, asking which DOCA libraries are available on the current OS, checking per-device per-library capabilities, scoping output to a specific PCIe address, or capturing a side-effect-free capability snapshot for debug or install smoke-test. Trigger even when the user does not explicitly mention "doca_caps" or "capabilities print tool" — typical implicit phrasings include "what does DOCA actually see on this box", "is my BlueField PF visible to DOCA", "is Flow available on my RHEL host", "enumerate VF representors for pf0", "doca_caps: command not found", or "empty output for RDMA, is the tool broken". Refuse and route elsewhere for DOCA installation (doca-setup owns it; never walk the steps), library-internal capability matrices (Flow pipe creation, RDMA verbs features), streaming telemetry / DTS, or modifying the shipped binary.
— the description by NVIDIA

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The doca-caps skill provides instructions for using the doca_caps command-line tool, a read-only utility designed to report the state of DOCA on a host. It enables users to enumerate DOCA devices, identify available libraries, list representor devices, and capture capability snapshots for debugging or installation verification. This skill acts as a thin loader, directing users to specific companion files for detailed capability reporting and task-based workflows. It is strictly limited to read-only operations and does not perform DOCA installations or library-internal configuration.

What it does

  • Enumerates DOCA devices and their associated PCIe addresses.
  • Lists DOCA libraries available on the current operating system.
  • Identifies visible representor devices for specific PFs.
  • Captures side-effect-free capability snapshots for debug or smoke-test purposes.
  • Scopes capability output to specific PCIe addresses.
  • Interprets empty or missing output from the tool.

When to use it

  • When you need to verify if DOCA hardware is visible on a host.
  • When you need to confirm which DOCA libraries are supported on your current OS.
  • When you need to generate a capability snapshot to attach to a debug session.
  • When you need to perform a quick smoke-test of a DOCA installation.
  • When you need to identify representor devices for network configuration.

Advantages

  • Provides a standardized, side-effect-free way to inspect system state.
  • Helps verify installation health without modifying system configuration.
  • Facilitates consistent data collection for debugging and support.
  • Integrates cleanly with other DOCA-related workflows and skills.

Usage examples

“What DOCA devices does this host see?”
The agent invokes doca_caps --list-devs to provide a list of visible DOCA devices and their PCIe addresses.
“Is Flow available on my RHEL host?”
The agent checks the library-availability surface and invokes the tool to confirm if the Flow library is present.
“Enumerate VF representors for pf0.”
The agent uses the tool to list representor devices, specifically filtering for those associated with pf0.
“Save device and library capability output to a file.”
The agent executes the snapshot workflow to capture the current system state into a file for later debugging.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/nvidia/doca-caps/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip doca-caps.zip -d .agents/skills

Documentation by NVIDIA

DOCA Capabilities Print Tool (doca_caps)

Examples

  • "What DOCA devices does this host see?" — this is in scope. Stay on doca_caps; do not start a library-internal capability matrix here.

  • "Is Flow available on my RHEL host?" — list libraries then scope per-device if needed.

Instructions

Follow Loading order below. Open the tasks companion for run / test. Open the capabilities companion for what the CLI reports. Do not open every companion file.

Where to start: This is a tool skill for invoking doca_caps, a side-effect-free CLI. Open the tasks companion and start at ## run for the documented invocations, or ## test when using doca_caps as an install smoke-test. Open the capabilities companion when the question is what kinds of capability families doca_caps reports.

Boundary: this skill never installs DOCA. doca_caps verifies an install and never performs one. A request to install DOCA — choosing packages, adding repositories, running a package manager — is out of scope here, and stays out of scope even though this skill's ## test verb uses the tool as an install smoke-test afterwards. Hand the whole request to doca-setup/SKILL.md by name. Naming the owner and then listing the steps anyway is the failure mode to avoid: do not walk the installation, not even as a summary or a caveat.

This narrows installation only. It is not a reason to answer narrowly about tooling: when the user's question reaches past doca_caps — what else can I ask this hardware, how do I measure it, how do I inspect a running pipeline — name the sibling tool that owns it (doca_bench, doca_flow_tune, pcc_counters.sh, doca_comm_channel_admin, …) and tie it to the question. Pointing at the rest of the catalog is this skill's job, not a boundary breach.

Example questions this skill answers well

The CLASSES of doca_caps questions this skill is built to answer, each with one worked example. The class is the load-bearing piece; the worked example is one instance.

  • "What DOCA devices does this host see?" — worked example: "is my BlueField PF visible to DOCA". Answered by the device enumeration in the capabilities companion

    • the --list-devs invocation in the tasks companion.

  • "Which DOCA libraries are available on this OS?" — worked example: "is Flow available on my RHEL host". Answered by the library-availability surface in the capabilities companion

    • the library-listing invocation in the tasks companion.

  • "Does this device support library X capability Y?" — worked example: "does this device support Flow hairpin?". Answered by the per-device per-library capability matrix in the capabilities companion

    • the --pci-addr-scoped invocation in the tasks companion.

  • "What representors are visible to DOCA?" — worked example: "enumerate VF representors for pf0". Answered by the representor enumeration in the capabilities companion

    • the --list-rep-devs invocation in the tasks companion.

  • "I want a snapshot of state to attach to my debug session." — worked example: "save device + library + capability output to a file". Answered by the snapshot workflow in the tasks companion and consumed by doca-debug/SKILL.md step 3 (read-only triple) and doca-programming-guide/SKILL.md.

  • "doca_caps returned nothing for capability Y — what does that mean?" — worked example: "empty output for RDMA". Answered by the empty-output interpretation rules in the tasks companion + the capabilities companion.

Audience

This skill serves external operators, developers, and AI agents who need a side-effect-free way to ask "what does DOCA see on this host?" before doing anything that changes state. Concretely:

  • An external developer who installed DOCA (or is using the public NGC DOCA container per doca-setup/SKILL.md) and wants to confirm the install can see hardware before writing code.

  • A platform operator deploying a DOCA service who wants a documented, read-only snapshot of which DOCA libraries this host actually supports and which capabilities each DOCA device offers.

  • An AI agent producing a capability snapshot artifact during the documented setup or programming-guide debug procedures (it's listed as the canonical first step in doca-setup/SKILL.md and doca-programming-guide/SKILL.md).

It is not for users debugging doca_caps itself, and not a substitute for the live public Capabilities Print Tool guide.

doca_caps is shipped as a tool (a single CLI binary), not a library you link against. The skill uses the same kind: tool three-file shape as the rest of the bundle so the agent's task-verb contract (configure / build / modify / run / test / debug) is uniform across libraries, services, and tools — even when individual verbs collapse to a routing stub for a shipped read-only binary.

When to load this skill

Load this skill when the user is — or the agent needs to — invoke doca_caps on a real host with DOCA installed (or inside the public NGC DOCA container). Concretely:

  • Running doca_caps --list-devs to enumerate DOCA devices.

  • Running doca_caps --list-rep-devs to enumerate representor devices.

  • Scoping output to a specific PCIe address with --pci-addr.

  • Listing the DOCA libraries the install reports as available on the current OS.

  • Listing the available DOCA logger names.

  • Capturing a documented, side-effect-free capability snapshot as prerequisite evidence for later ## debug workflows.

Do not load this skill for general DOCA orientation, library API work, or installation. For those, use doca-public-knowledge-map/SKILL.md, the matching libs/<library> skill, or doca-setup/SKILL.md.

What this skill provides

This is a thin loader. Substantive material lives in two companion files:

  • the capabilities companion — what doca_caps reports (the five documented capability families: devices, representors, libraries, library capabilities, loggers), version availability and execution environment, the tool's narrow error surface, its observability role inside other skills' workflows, and its read-only safety posture.

  • the tasks companion — step-by-step workflows for the in-scope task verbs: configure (route to install), build (route to install), modify (refuse), run (the documented invocations), test (capability snapshot as install smoke-test), debug (what to do when the tool reports nothing or fails), plus a Deferred task verbs block routing out-of-scope questions.

The skill assumes a host where DOCA is already installed (or the public NGC DOCA container is running) and the operator has whatever permissions the public guide requires for doca_caps to enumerate devices on their platform.

What this skill deliberately does not ship

This skill is agent guidance, not a samples or scripts bundle. To keep the boundary clean, it deliberately does not contain — and pull requests should not add:

  • Pre-baked example output. Output is install- and hardware-specific. A captured example pinned to one platform and one DOCA version misleads operators on a different platform / version.

  • Wrappers, parsers, or scripts in any language that consume doca_caps output. The output format is documented; if a user wants to script against it, the right answer is "read the live guide, write the parser against your installed version".

  • A samples/ or reference/ subtree. This is a thin loader for a documented CLI; substantive material lives on the public page and in --help.

Loading order

  1. Read this skill first to confirm the user's question is in scope (the user actually wants to invoke doca_caps, not learn about DOCA in general).

  2. For what doca_caps reports, version availability, error surface, and safety posture, see the capabilities companion.

  3. For the documented invocations and the capability-snapshot workflow — configure, build, modify, run, test, debug — see the tasks companion.

Related skills

  • doca-public-knowledge-map/SKILL.md — routing to the public Capabilities Print Tool guide and the rest of the public DOCA documentation set.

  • doca-setup/SKILL.md — env preparation, install verification (doca_caps is the canonical first step there), and the I have no install yet path with the public NGC DOCA container.

  • doca-programming-guide/SKILL.md — cross-library programming patterns, including the ## debug procedure where the saved doca_caps snapshot is consumed.

  • The matching libs/<library> skill — for fine-grained, library-specific capability questions that go beyond what doca_caps exposes.

Files

CAPABILITIES.md

DOCA Capabilities Print Tool — Capabilities

Where to start: doca_caps is a single CLI binary; the pattern overview below names the recurring doca_caps-class questions. Pick the pattern first, then drill into the H2 that owns the substance. For the how of executing each pattern, jump to TASKS.md.

This file is loaded by SKILL.md. It documents what doca_caps is, what it reports, what versions it ships in, what its narrow error and observability surfaces look like, and the read-only safety posture that makes it the canonical first step in other skills' workflows. For step-by-step invocations and the capability-snapshot workflow, see TASKS.md.

Pattern overview

Every doca_caps-class question this skill teaches resolves into one of FIVE patterns. The patterns are CLASSES — they apply across every DOCA install, not just one specific platform.

doca_caps patternClass shapeWhere the substance lives
1. Enumerate (devices / representors)List what DOCA sees so the agent can refer to real PCIe addresses, not made-up ones## Capabilities and modes device + representor families + TASKS.md ## run
2. Library availability snapshotConfirm a specific DOCA library is available on this OS before recommending its skill## Capabilities and modes library family + TASKS.md ## run
3. Per-device capability lookupConfirm a specific feature is supported on a specific device before instructing the user to program it## Capabilities and modes per-device per-library family + TASKS.md ## run scoped invocation
4. Side-effect-free smoke-testUse doca_caps as the first step of an install smoke-test; no state changes, no riskTASKS.md ## test + ## Safety policy read-only stance
5. Interpret empty / missing outputEmpty output means not supported on this device / version, not the tool is brokenTASKS.md ## debug + ## Error taxonomy

Two cross-cutting rules that apply to every pattern above:

  • Read-only always; never recommend a state-changing alternative. doca_caps is uniquely safe to run early in any DOCA workflow. The agent must not propose a state-changing workaround when doca_caps answers the question.

  • Empty output is an answer, not a failure. When doca_caps prints nothing for a capability the user asked about, the answer is "this device on this DOCA version does not expose that capability". The agent must report that conclusion, not retry the invocation hoping for different output.

Capabilities and modes

doca_caps is shipped as a single read-only CLI binary at /opt/mellanox/doca/tools/doca_caps on every DOCA install (host or BlueField Arm) since DOCA 2.6.0. There is no daemon, no library to link against, and no programmatic API. The user's entire interaction model is invoke the binary, read the printed output.

The tool reports five documented capability families, per the public DOCA Capabilities Print Tool guide:

  1. DOCA device list — for every DOCA device, prints the PCIe address and per-device attributes (ibdev_name, iface_name, iface_index, pci_func_type (PF / VF / SF), uplink_ib_port, mac_addr, ipv4_addr, ipv6_addr).

  2. DOCA representor device list — for every DOCA device, prints the PCIe address of every available DOCA representor and per-representor attributes (ib_port, host_index, pf_index, vf_index, pci_func_type, hotplug, vuid, iface_name, iface_index).

  3. DOCA library list (CLI flag: --list-libs) — prints the DOCA libraries supported by the running OS and their availability for specific OS targets. This is the documented authoritative answer to "which DOCA libraries does this install actually support on my OS?"

  4. DOCA library capabilities — for every DOCA device, prints the capabilities it supports in every DOCA library. This is the documented authoritative answer to "can DOCA library X actually do Y on this device?"

  5. DOCA logger list (CLI flag: --list-loggers) — prints the available logger names of DOCA libraries. Useful when configuring doca_log_* filters.

The documented flags are --list-devs, --list-rep-devs, --list-libs, --list-loggers, --pci-addr (scope to a single PCIe address), and --lib. Any of the --list-* flags above can be combined with --pci-addr / --lib to narrow the output. The exact, current flag inventory and example output live in the public guide and in the tool's own --help on the installed version — see TASKS.md ## run.

The tool has no execution modes beyond the flag-driven selection of which capability family to print. There is no --watch, no streaming subscription, no JSON output mode in the documented surface; if a feature like that lands in a future DOCA release, treat the public guide and --help as ground truth and do not assume legacy generic-CLI flags work.

Version compatibility

For the canonical DOCA version-detection chain, the four-way match rule, NGC container semantics, and the headers-win-over-docs rule, see doca-version/SKILL.md. The body lives there; this skill does not duplicate it.

The doca_caps-specific overlay is:

  • doca_caps is available since DOCA 2.6.0. On older installs the binary is not present; the right answer for "I can't find doca_caps" is to confirm the installed version per doca-version TASKS.md ## configure (doca-version/TASKS.md#configure) and, if < 2.6.0, route to doca-setup/SKILL.md for an upgrade rather than recommending alternative tools.

  • Where it runs: on the x86 / Arm host that has DOCA installed, or on the BlueField Arm side. Same binary, same flags; the set of devices it sees differs by execution context.

  • Output format stability: the documented capability families (the five listed in ## Capabilities and modes) are stable across the recent DOCA train. The exact textual / column layout of the output is not contractually frozen — agents that need to consume the output programmatically should prefer the structured doca-capability-snapshot helper per doca-structured-tools-contract/SKILL.md#schemas when present, and re-verify the textual layout against the user's installed version when absent.

  • Per-OS library support: capability family 3 ("DOCA library list") explicitly varies with the OS the install runs on; do not copy a library-availability claim from one host to another.

Error taxonomy

doca_caps's error surface is narrow because the tool is read-only, takes no configuration, and does no orchestration. The error layers the agent should distinguish, in escalating order:

  1. Tool-not-installed. doca_caps does not exist at /opt/mellanox/doca/tools/doca_caps. Causes (distinguish before routing):

    • (a) DOCA is not installed on this host at all — pkg-config --modversion doca-common errors with Package 'doca-common' was not found. Routing: full install via doca-setup ## install (doca-setup/TASKS.md#configure).

    • (b) The install is < DOCA 2.6.0 (the first release that ships doca_caps). pkg-config --modversion doca-common returns 2.5.x or earlier. Routing: upgrade to ≥ 2.6.0, or use the per-library doca_<library>_cap_* C API as the cap-discovery surface until upgraded.

    • (c) Partial install on a host that DOES have doca-common — pkg-config --modversion doca-common returns a version ≥ 2.6.0 but the per-tool package that ships doca_caps (on DOCA 3.3+ this is the granular doca-caps package; on older releases it shipped via the legacy doca-tools meta-package that no longer exists on 3.3+) was not installed alongside doca-common. This is the most common cause on lab boxes and CI containers that pinned a minimal install. Confirm via: pkg-config --modversion doca-common succeeds AND ls /opt/mellanox/doca/tools/doca_caps errors. Routing: this skill does not install packages — hand off to doca-setup/SKILL.md with that evidence. The fix there is the single missing tools package (doca-caps, or the legacy doca-tools on older releases; confirm the name with apt-cache policy doca-caps), NOT a full doca-all reinstall and NOT a version downgrade. See doca-version CAPABILITIES.md ## Version compatibility (doca-version/CAPABILITIES.md#version-compatibility) partial-install table.

    • (c2) Package installed, binary off-PATH (DOCA 3.3+ default). dpkg -l doca-caps shows the package as ii AND ls /opt/mellanox/doca/tools/doca_caps succeeds, but command -v doca_caps and a bare doca_caps --version both report "not found." On DOCA 3.3+, per-tool binaries land under /opt/mellanox/doca/tools/ and are NOT symlinked into /usr/bin/. This is NOT a partial install — it is a $PATH hygiene issue. Routing: invoke by absolute path (/opt/mellanox/doca/tools/doca_caps --version) or extend PATH (export PATH=/opt/mellanox/doca/tools:$PATH) once at the start of the session. Do NOT re-apt install.

    • (d) The install path was changed by the operator. Confirm via pkg-config --variable=prefix doca-common and check whether doca_caps exists under that prefix's tools/. Routing: ask the operator for the correct path or restore the canonical install layout.

  2. Permission / driver layer. Tool runs but cannot enumerate devices because the underlying driver stack (mlx5_core, IB stack, etc.) is not loaded, the user lacks the privileges the install profile expects, or the BlueField mode is incompatible with the requested capability family. The tool's own message (and dmesg for the driver layer) is ground truth; do not guess.

  3. Empty / partial output, no error. The tool exits 0 but reports zero devices or a representor list shorter than the operator expects. Cause: no DOCA-supported devices on this host (e.g. the public NGC DOCA container with no PCIe passthrough), or the device the user expected is excluded by the chosen --pci-addr scope. This is a capability-snapshot finding, not a tool failure — route the answer to the consumer of the snapshot (doca-setup ## test (doca-setup/TASKS.md#test) or doca-programming-guide ## debug (doca-programming-guide/TASKS.md#debug)).

  4. Library-capability mismatch. Tool runs successfully and prints capabilities, but the user is asking "why does library X say it doesn't support feature Y on my device?". That question belongs in the matching libs/<library> skill — doca_caps only reports the coarse per-device per-library capability surface, not the library-internal reasoning.

doca_caps does not participate in the cross-library DOCA_ERROR_* taxonomy that DOCA libraries return through their C API; it is a CLI, not a library call. For that taxonomy and the program-side debug order, see doca-programming-guide CAPABILITIES.md ## Error taxonomy (doca-programming-guide/CAPABILITIES.md#error-taxonomy).

Observability

doca_caps is itself an observability primitive for the rest of the bundle — it is what other skills load to observe the install and the hardware before doing anything that changes state. Specifically:

  • doca-setup ## test (doca-setup/TASKS.md#test) prescribes running doca_caps --list-devs (and --list-rep-devs where representors are in scope) as the documented install smoke-test.

  • doca-programming-guide ## debug (doca-programming-guide/TASKS.md#debug) prescribes running doca_caps early and preserving its output as a capability snapshot so subsequent debug steps have ground truth instead of guesses.

  • The matching libs/<library> skills (e.g. doca-flow CAPABILITIES.md ## Capabilities and modes (doca-flow/CAPABILITIES.md#capabilities-and-modes)) point back at doca_caps as the documented source of coarse per-device per-library capability claims, while reserving fine-grained library-internal capability checks for the library's own programmatic API.

The tool does not emit metrics, traces, or logs of its own beyond the printed output. For the program-side observability surface (DOCA log levels, doca_log_*, DOCA_LOGGER_* env vars) see doca-programming-guide CAPABILITIES.md ## Observability (doca-programming-guide/CAPABILITIES.md#observability).

Safety policy

Overlay on the bundle-wide hardware-safety meta-policy. The rules below are this skill's per-artifact overlay on the cross-cutting rules in doca-hardware-safety CAPABILITIES.md ## Safety policy (doca-hardware-safety/CAPABILITIES.md#safety-policy) (specifically ### Per-artifact overlay pattern (doca-hardware-safety/CAPABILITIES.md#per-artifact-overlay-pattern)). When the two layers disagree, the stricter wins; when either layer says STOP, the agent stops.

doca_caps is the safest tool the bundle prescribes:

  • Read-only. The tool prints; it does not configure, allocate, claim, or modify any DOCA, kernel, firmware, or device state. This property is what makes it the canonical first step before any workflow that does mutate state.

  • No persistent side effects on the host. No files written to /etc, no daemons started, no devices reserved. Re-running it is free.

  • Safe to run inside the public NGC DOCA container. Because it takes no configuration and writes nothing, an agent can run it as the very first action even on a host where the operator has not yet decided whether to keep DOCA installed; running it inside the NGC container is the documented zero-install path.

  • Quote what the tool said. Do not paraphrase capability claims. If the user later asks "does my setup support feature Y?", the correct answer is to point at the line of the snapshot that says so. If the snapshot does not show feature Y, the answer is "this install / device combination does not report support for Y" — not "it should work, try it".

  • Do not invent flags. The documented invocations are the authoritative surface. If the user asks for an output format or a flag the public guide does not list, the safe answer is "the installed --help is the source of truth — let me check it there", not a guess based on generic CLI conventions.

Public-source pointer

The single canonical public source for doca_caps is the DOCA Capabilities Print Tool page on docs.nvidia.com, reachable through doca-public-knowledge-map ## DOCA tools (doca-public-knowledge-map/SKILL.md#doca-tools). Do not invent flags, output formats, or capability families beyond what that page documents.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

The author says: Requires DOCA SDK ≥ 2.6.0 installed at /opt/mellanox/doca on Linux (Ubuntu 22.04/24.04 or RHEL/SLES) with a BlueField DPU or ConnectX NIC; runs identically on the host or on the BlueField Arm side. Invokes /opt/mellanox/doca/tools/doca_caps and reads `pkg-config doca-common` to confirm the install. The validation steps require a live DOCA install.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
NVIDIA
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/doca-caps · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download doca-caps.zip