> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kiwiflow.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Work with other tools

> Let the agent on a step use your issue tracker, design tool or test manager through its own connection, and record what it used.

Kiwi does not connect to your other tools. The agent working on a step uses them through its own connection: the tool vendor's MCP server, command-line tool or API, set up in that agent. Kiwi never calls those tools and never holds their credentials. It records what the agent reports: the step's outputs, the settings it ran with and the skills it used.

## Set up

1. **Connect your agent to Kiwi.** See the [quickstart](https://docs.kiwiflow.io/quickstart.md#connect-your-agent).
2. **Connect your agent to the tool.** Follow the vendor's instructions for its MCP server, command-line tool or API. Keep the tool's credentials in your agent's configuration or secret store. Never put them in a skill, a step output or a Kiwi connection.
3. **Name the tool in the skill.** When you publish a workflow skill for a step that uses the tool, list the tool among the tools the skill requires. See [Publish a skill](https://docs.kiwiflow.io/workflow-skills.md#publish-a-skill).
4. **Add links for the step.** Optionally, a project Admin adds the tool's project or board as a connection and binds it to the steps that use it. See [Point the agent to the right place](#point-the-agent-to-the-right-place).

## Check that agents have the tool

When you check a skill, add the tools your agents will have to the check's workflow context. Through MCP, send them as `availableTools` in the `workflowContext` of `create_skill_check`, up to 100 names. If the skill requires a tool that is not in that list, the check reports `SK15-UNSUPPORTED-TOOL` as an error. Without a list of available tools, this rule is not checked. See [Structural checks](https://docs.kiwiflow.io/workflow-skills.md#structural-checks).

## Point the agent to the right place

**Manage project**, under **Connections**, holds [external references](https://docs.kiwiflow.io/team-and-billing.md#external-references): a name, a URL, notes and optional bindings to workflow steps. Use them for the board, project or file the agent should work in, and for notes on how to use it. Agents read them with `list_connections`, which returns each reference with its step bindings.

* The URL must be a public `https` address with no username, password, query string or fragment. Never put a token in a reference.
* Kiwi does not call the URL or check that it works.

## Record what the agent used

After starting a step, the agent can call `report_configuration` with the settings it ran with, including its tools and plugins, and `report_skill_use` with the skills it used. Kiwi records both as the agent's own statements. See [Report settings and skill use](https://docs.kiwiflow.io/workflow-skills.md#report-settings-and-skill-use).

## Submit work for people to review

The agent submits links to its work in the tool as the step's outputs. In the Development workflow, Implement outputs `candidate_ref`, `summary` and `handoff_notes`; see [Implement output](https://docs.kiwiflow.io/workflows.md#implement-output). Kiwi records the links. It does not open them or check what is behind them.

Reviews and sign-off stay with the steps and people your workflow names. In the Development workflow, the result approver tells their own agent to accept the result or request rework.

## Example: an issue tracker

A team tracks its work in an issue tracker whose vendor offers an MCP server.

1. Each developer adds the tracker's MCP server to their coding agent, following the vendor's instructions, and signs in to the tracker there.

2. A project Admin adds a connection named `Issue tracker` with the URL `https://tracker.example.com/team/web` and the note "Link each pull request back to its issue." and binds it to the Development workflow's `implement` step.

3. The Admin publishes a skill for the Implement step that lists the tracker among its required tools:

   ```text wrap theme={null}
   Start from the issue link in the run's request.
   Read the issue and its comments with the issue tracker's MCP server.
   Make the change on a new branch and open a pull request.
   Add the pull request link to the issue as a comment.
   Submit the pull request as candidate_ref, with a summary and handoff notes.
   If you cannot read the issue, report a blocker with the link you tried.
   Leave acceptance to the run's result approver.
   ```

4. Before publishing, the Admin checks the skill with the tools the team's agents have. An agent setup without the tracker would show `SK15-UNSUPPORTED-TOOL`.

5. During a run, the agent on Implement reads the connection with `list_connections`, reports its configuration with the tracker among its tools, and submits the pull request link as `candidate_ref`. People review the pull request, and the result approver accepts it through their own agent.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.