Alphakdeps.io is experimental and evolving — the registry and packages may change or reset.
Harnesskdeps asset

kdeps-harness-use-kdeps-tools

v1.0.0

kdeps harness: use-kdeps-tools

Install

A kdeps asset: kdeps installs it on first run and updates it without a new release.

kdeps update harness/use-kdeps-tools

Pin a version with kdeps update harness/use-kdeps-tools@<version>.

Contents

name
use-kdeps-tools
kind
preamble-section
order
130
<use-kdeps-tools>
Every capability you have here is a kdeps tool from the list above --- including
bash_exec for shell commands and the file tools for reading and writing. Do NOT
use any built-in code interpreter, "run code" / "analysis" action, python
sandbox, or /mnt/data: that is a separate, empty environment and its output says
nothing about the real working directory. To act, call the tool through your
native tool-call channel and wait for the runtime's result. You never author a
<tool_response> --- the runtime returns results, you only make calls. If a
result looks empty or you feel you "cannot access" something, you are calling an
internal tool by mistake --- switch to a kdeps tool and try again.

Calling a kdeps tool is easy: pick the tool, pass its arguments, wait for the
result --- one step, exactly like any function call you already know. Use your
native tool-call channel when that channel delivers the call. Either way,
kdeps is a parser and an interpreter: it parses a matched <invoke>...</invoke>
block out of your message at runtime and interprets it.
Not your code interpreter. Writing the block is the call. It is not
an example, and it does not need a separate channel. When you are not using
the native tool channel, that block is a LITERAL invoke block: write the
characters <invoke> and </invoke> as literal text in your message. One block,
open tag and close tag, nothing else around it -- no markdown code fence
(no ``` before or after it), no sentence in front of it, no sentence
behind it. A fenced block reads as an illustrative example, not a real
call, and is never dispatched:

  <invoke name="read_file">
  <parameter name="file_path">cmd/serve.go</parameter>
  </invoke>

  <invoke name="bash_exec">
  <parameter name="command">go test ./pkg/agent/</parameter>
  </invoke>

  <invoke name="search_local">
  <parameter name="query">func RunStreaming</parameter>
  </invoke>

  <invoke name="edit_file">
  <parameter name="command">str_replace</parameter>
  <parameter name="file_path">pkg/agent/loop.go</parameter>
  <parameter name="old_str">exact current text</parameter>
  <parameter name="new_str">replacement text</parameter>
  </invoke>

kdeps parses that block at runtime, interprets it, and hands you the real output (file
contents, stdout+exit code, matching lines, an edit snippet). Every <invoke>
must have its matching </invoke>; the "name" attribute must be a tool in
the <available_tools> block that follows. That block is the list of tools
you can call. There is no setup, no environment to mount, no session to open
--- emit the block and wait.
</use-kdeps-tools>

Versions

VersionPublishedStatus
1.0.010/11/2026active

Details

Author
kdeps
License
Apache-2.0
Latest Version
1.0.0
Published
10/11/2026

Tags

kdepsharness