Skip to main content
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.
  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.
  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.

​
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.

​
Point the agent to the right place

Manage project, under Connections, holds 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.

​
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. 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:
  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.