MCP Server

Kangentic ships a built-in MCP (Model Context Protocol) server that gives most agents it spawns a set of tools for working with the board, backlog, sessions, and the embedded browser while they run. It is enabled by default. Which agents get wired, and how, is in How the MCP Server Works.

When an agent discovers follow-up work - bugs, refactoring opportunities, or new features - it can file tasks directly on the board instead of you entering each one by hand. Agents can also search existing tasks to avoid duplicates, read prior session transcripts, inspect board status, and drive a task’s Browser pane.

The server runs as an in-process streamable HTTP transport inside the Kangentic app. By default it binds to loopback (127.0.0.1) with a fresh token generated on every launch, and Kangentic wires it into each session automatically - there is nothing to install and, for local use, nothing to configure. To turn it off, toggle MCP Server off in Settings or set mcpServer.enabled to false. To reach the server from another machine, widen the bind interface with mcpServer.bindAddress (a wildcard like 0.0.0.0 still binds loopback) and allowlist a hostname with mcpServer.callbackHost - see the Configuration Reference.

This page lists every shipped tool, grouped exactly as the Settings > MCP Server panel groups them, with one anchor per tool (for example #kangentic_create_task) so the app can deep-link a tool’s pill straight to its entry here.

Tool annotations

Every tool is annotated read-only or mutating. This is load-bearing for plan mode: Claude Code auto-approves read-only tools without a permission prompt while planning, so the plan-mode auto-approval surface is exactly the read-only set. Mutating tools - the board and backlog writers (create, update, delete, move, promote, link) and the browser tools that change the loaded page or a pane’s lifecycle (navigate, click, type, keypress, drag, eval, open pane, close pane) - still prompt in plan mode by design. Outside plan mode, agents Kangentic spawns never see a prompt for Kangentic’s own tools.

Cross-project calls

Most tools accept an optional project parameter - a project name (case-insensitive) or UUID - to route the call at a different Kangentic project than the one the session is bound to. There are two exceptions. kangentic_get_current_task resolves the agent’s own working directory and branch, so cross-project lookup makes no sense there. The whole kangentic_browser_* family takes no project argument at all: those tools are bound to the project in the connection’s own URL, which makes “there is no path to another project’s pane” a guarantee of the tool shape rather than a runtime check. kangentic_browser_close_pane is the one browser tool that can reach beyond its own project, and only through an explicit includeOtherProjects flag that is off by default.

When project is set, the response is prefixed with [Project: <name> (<shortId>)] so the caller can confirm where the action landed. Use kangentic_list_projects to discover valid selectors. kangentic_move_task_to_project skips the prefix: it resolves two projects at once (source via project, destination via targetProject), so its response names both directly instead.

Tasks

Operations on individual tasks.

kangentic_create_task

Create Task - add a task to any board column or the backlog. This is the only task-creation tool. With no column it lands in the To Do column; pass column: "Backlog" to stage it in the backlog instead. Titles are capped at 200 characters and descriptions at 50,000. Creating a task in a column with auto-spawn enabled also starts an agent session for it. As a runaway-loop safeguard, the server caps creation at 500 tasks per app launch; once that cap is hit this tool returns an error until Kangentic is restarted.

The spawn behavior can be pinned per task with optional overrides: agentOverride locks the CLI for the task’s lifetime, modelOverride and effortOverride set the model and reasoning level, and permissionMode sets the permission mode (default, plan, acceptEdits, dontAsk, bypassPermissions, or auto). Each falls back through the column override, then the project default, then the app default when omitted. autoCommand delivers a message to the agent once it spawns (MCP-only; overrides the destination column’s own message for this task).

Since v0.37.0 agentOverride, modelOverride, and effortOverride are validated when the task is created, not when it spawns. An unknown value is rejected on the spot with the valid values listed, and no task is created - a typo used to produce a card that looked correct and failed hours later, when someone moved it into an executing column. The rejection names the resolved agent and which rung of the ladder it came from, since the caller usually did not pass one. Validation stays permissive wherever it cannot know: an agent that enumerates nothing accepts the value and leaves its own CLI as the judge, a floating alias like opus is always accepted (discovered model lists hold only concrete versioned ids), and a capability probe that runs out of time accepts too. Only the fields present on the call are checked.

useWorktree: false means no worktree is created: the agent runs in the project directory itself. What happens to the branch depends on what else you passed. A branchName is fetched, created if it does not exist, and checked out in the project directory, so it is still subject to the conflict guard below. With no custom branch but a baseBranch, that base is checked out and fast-forwarded from origin. With neither, git is not touched at all and the agent runs on whatever branch the repo currently has out. Either checkout refuses on a dirty working tree, so commit or stash first. Omit useWorktree to follow the project’s own setting.

Labels are worth one call first: kangentic_board_summary reports the board’s existing label vocabulary, so an agent can reuse a label instead of coining a near-duplicate. There is also a client-side quirk to know about. When a call carries both labels and a description of roughly 1KB or more, the labels can be dropped before they ever reach Kangentic, upstream in the MCP client’s own tool-call emission. Kangentic detects that signature and appends a [Labels not received] line to the response naming the follow-up call to make. It is advisory rather than an error - the task itself was created correctly - and a caller that deliberately sent no labels never sees the line.

Naming a branch with branchName is checked before anything is written. Git allows a branch in only one working tree at a time, so if that branch is already checked out the call is refused, naming the branch and the path holding it, and no task is created. Retrying the same call fails identically; free the branch or use a different name. See Naming a branch yourself.

kangentic_list_tasks

List Tasks - browse tasks in board order (top to bottom within each column), optionally filtered by column. Each task reports position, its zero-based ordinal slot within its own column. That is the same slot kangentic_move_task and kangentic_reorder_tasks accept, so a listing can be read and handed straight back. Each task also renders its labels as [a, b] after the title, omitted entirely when it has none.

kangentic_search_tasks

Search Tasks - keyword search across both the board (active and archived) and the backlog. Use the scope parameter to narrow to a single surface; results are grouped so you can see which surface each hit came from. Board and backlog hits both render their labels the same way, but note the asymmetry in matching: backlog items match on their labels, board tasks match on title and description only, so a board task is not found by searching for one of its labels.

A query of # followed by digits (#42) is a ticket lookup by the task’s #N number, prefix-matched. Backlog items have no ticket number, so a ticket query returns board tasks only whatever scope says.

kangentic_find_task

Find Task - look up a task or backlog item by display ID, UUID, branch name, title keyword, or PR number. Returns matching board tasks (with branch, worktree path, and PR info) and any matching backlog items.

kangentic_get_current_task

Current Task - resolve the task for the current working directory or git branch. Use it at the start of work in a worktree to confirm which task you are on before commits, PRs, or merge-back. This is the one tool that does not take a project argument.

It deliberately does not report the task’s reserved dev-server ports. This serializer is a per-project read while the port ledger is global, so including them would make every task lookup hit a second database once per matched task. Use kangentic_check_dev_ports, which answers that question and probes each port besides.

kangentic_get_task_stats

Task Stats - token usage, cost, duration, tool calls, and lines changed for a specific task or aggregated across all tasks, with an optional sort metric.

kangentic_update_task

Update Task - edit a task’s title, description, PR info, agent assignment, model/effort/permission overrides, run mode, Board Profile, priority, labels, base branch, worktree toggle, and attachments. The model, effort, and permissionMode overrides mirror the ones on kangentic_create_task; pass an empty string to clear one and fall back to the column, project, or app default. agent, model, and effort get the same call-time validation as their create counterparts, resolved against the agent this task actually runs under. A task’s stored pins are never re-validated, so a labels-only follow-up still succeeds on a task carrying a since-deprecated model, and labels carries the same large-description caveat and the same [Labels not received] advisory.

profile and runMode choose how the task gets its agent settings, and they are mutually exclusive. A profile (a Board Profile name or id) re-resolves per column as the task moves; pass an empty string to clear it back to Default. runMode: "column_settings" follows each column and clears the pins, while runMode: "agent_override" pins agent, model, effort, and permission for the task’s whole life. Setting any pin already implies agent_override, so you only need runMode to switch modes without pinning anything, and pairing a pin with column_settings is rejected as a contradiction. Attachments passed here are added to the task; existing ones are kept (remove one with kangentic_remove_task_attachment). To move a task between columns, use kangentic_move_task instead.

The description can be changed three ways, so an agent editing a long description does not have to resend the whole thing:

• description replaces the entire description.
• descriptionEdits applies an ordered list of exact find-and-replace edits to the current text, like the file Edit tool. Each find must appear exactly once (as the text stands after the previous edits in the list); a missing or non-unique find fails the whole call and writes nothing.
• appendDescription adds text to the end of the current description.

descriptionEdits and appendDescription can be combined (edits apply first, then the append), but neither can be used together with a full description. Descriptions are capped at 50,000 characters.

kangentic_move_task

Move Task - move a task between columns, optionally placing it at a chosen slot in that column, running the same lifecycle as a drag: spawning or suspending agents, creating or cleaning up worktrees, and running configured transition actions. Moving to Done auto-archives the task; moving back to To Do kills the session and removes the worktree.

The optional position is a zero-based ordinal slot among the column’s tasks; the tasks at and below it shift down. It is clamped to the column, so a value past the end lands last, and omitting it appends. Naming the task’s current column together with position repositions it in place, which changes nothing but its order: no session, worktree, or lifecycle effects. Position has no useful effect when moving into Done, which archives the task.

kangentic_reorder_tasks

Reorder Tasks - set the top-to-bottom order of tasks within one column in a single call, for sequencing a column by priority or execution order. Pass column (case-insensitive) and taskIds, an array of display IDs or UUIDs in the order they should appear from the top; every ID must already be in that column.

The listed tasks take the top slots in the order given, and any task in the column you do not list keeps its relative order below them. So you can pass every task to set the full order, or just a few to pin them to the top. Read the current order first with kangentic_list_tasks or kangentic_get_column_detail. This never moves a task between columns and never spawns, suspends, or otherwise touches a session or worktree; use kangentic_move_task to change a task’s column.

kangentic_move_task_to_project

Move Task to Project - relocate a task from the To Do column of one project’s board to a different project’s board. Only To Do tasks can move, since entering To Do already resets a task’s live state (session killed, worktree removed, branch deleted), so nothing live has to cross the project boundary; move a task to To Do first if it is elsewhere. The relocation preserves title, description, labels, priority, creation time, and attachments, and assigns a new task ID and display number in the target project. Pass targetProject (the destination, which must differ from the source) and optionally column to land somewhere other than the destination’s To Do column - landing in an auto-spawn column there spawns an agent, just like kangentic_create_task. The project parameter names the source project (omit to use the active one), so this is the one tool where project is not the destination; its response states both the source and destination directly instead of the usual [Project: ...] prefix.

kangentic_link_pr

Link PR - authoritatively resolve and attach a task’s pull request via the gh CLI, even for PRs opened outside Kangentic and even when the task has no live session. Re-running refreshes the linked PR’s state.

kangentic_delete_task

Delete Task - permanently remove a task, its attachments, and session records, cleaning up the associated worktree and branch. This cannot be undone.

kangentic_remove_task_attachment

Remove Attachment - remove a single attachment by its attachment ID, from either a board task or a backlog item (the ID alone determines which surface owns it). Find attachment IDs with kangentic_query_db. This cannot be undone.

Board

Columns, the backlog, projects, and unified search.

kangentic_list_columns

List Columns - see every non-archived board column with its role and current task counts.

kangentic_get_column_detail

Column Detail - inspect a column’s automation, permission mode, plan-exit target, and visual settings. It also returns taskOrder, the column’s tasks top to bottom with their zero-based ordinal position, which makes this a complete read-before-write call for kangentic_reorder_tasks.

kangentic_update_column

Update Column - rename, recolor, and configure a column’s automation: its description, auto-spawn, the message delivered on entry, agent/model/effort overrides, permission mode, handoff context, and the plan-exit target column.

The message parameter is autoCommand, which the column editor labels Message to agent. It accepts plain prose as readily as a slash command, and it is delivered whenever a task enters the column, not only when one spawns there. See Auto-Commands.

kangentic_create_column

Create Column - add a new column to the board, with optional color, icon, and automation settings.

kangentic_delete_column

Delete Column - remove a column. Refuses non-empty columns and the role columns (To Do and Done). Naming Done still gets you the role refusal rather than a confusing “not found”, even though Done is stored archived. Deletion transactionally cleans up lane transitions, other columns’ plan-exit targets, and Board Profile references.

kangentic_list_board_profiles

List Board Profiles - read the board’s named per-column strategy ladders: id, name, description, and the per-column settings each one overrides. Returns JSON, because the primary uses are diffing two boards and copying a profile between them, and both need the exact structure back out. Entries for columns that no longer exist are omitted, so the listing reflects what will actually apply. Profile entries are keyed by column name, which is what makes copying a profile between projects work. See Board Profiles.

kangentic_create_board_profile

Create Board Profile - add a named preset of per-column agent, model, effort, and automation settings. Names must be unique on the board. The columns object is sparse and keyed by column name, so list only the columns this profile changes. kangentic_create_task and kangentic_update_task accept a profile parameter so an agent can file tasks that ride a specific ladder.

kangentic_update_board_profile

Update Board Profile - rename a profile, change its description, or retune its per-column settings. columns merges by default, so retuning one column does not wipe the rest, which is what makes a sweep like “change every profile’s Opus 4.8 to Opus 5” safe to run column by column. Pass replaceColumns: true for a wholesale swap, the usual choice when copying a profile from another board. On the active project this reaches live sessions exactly as saving the profile in the Board Manager does.

kangentic_delete_board_profile

Delete Board Profile - remove a profile. Tasks riding it are not rewritten; they fall back to each column’s own settings, and the response reports how many were affected. That fallback is itself a settings change for a running session, so on the active project it propagates like any other profile edit.

kangentic_board_summary

Board Summary - a high-level overview: task counts per column, the board’s label vocabulary, active sessions, completed tasks, and aggregate cost and token metrics.

The label vocabulary answers “what labels does this board already use”, which a paginated, count-free task listing cannot. It reports the labels in use with their counts, most-used first, tallied across active tasks, archived (Done) tasks, and backlog items - archived included because on a mature board most of the vocabulary lives in Done. The header carries two figures that measure different things: N distinct is the size of the vocabulary, while M labelled items counts items carrying at least one label, so the per-label counts (which are label uses) sum to more than M. The printed list is capped at 30 with an “and N more” tail, while the structured data.labels carries the whole tally uncapped. Label colors are deliberately not reported: passing an existing label back as a plain string preserves the color it already has.

kangentic_get_usage_stats

Usage Stats - tokens, cost, burn rate, and by-model / by-agent usage for a project or all projects over a time range. The MCP counterpart of the Usage Stats Dashboard.

kangentic_list_backlog

List Backlog - see items staged in the backlog, optionally filtered by priority or keyword.

kangentic_promote_backlog

Promote Backlog - move backlog items onto the board as tasks (defaults to the To Do column). Attachments are copied to the new tasks.

kangentic_update_backlog_item

Update Backlog Item - edit a backlog item’s title, description, priority, labels, or attachments. Labels are replaced wholesale, not merged; attachments passed here are added to the item, keeping existing ones (remove one with kangentic_remove_task_attachment).

kangentic_delete_backlog_item

Delete Backlog Item - permanently remove a backlog item and all of its attachments. This cannot be undone.

kangentic_list_projects

List Projects - every Kangentic project registered on this machine, with name, id, path, and an active flag. Use a returned name or id as the project argument on any other tool.

kangentic_search

Search - unified search across board tasks, backlog items, session events, project names, and your agents’ past conversations in one call. This is the same backend as Quick Find. Scopes to the active project by default; pass scope: "all" to widen across every registered project.

Conversations are matched by keyword by default, or by meaning when you pass mode: "hybrid" (fusing keyword and local semantic search); mode only affects the conversation results. Pass taskId to restrict conversation hits to a single task’s history. Each conversation hit carries a sessionId and turnUuid - follow up with kangentic_get_transcript (aroundUuid) to read the surrounding turns. Conversation results require Conversation Memory indexing to be on (the default), and rank semantically only when Semantic search is enabled in the Memory settings. This tool subsumes the former kangentic_recall.

A query of # followed by digits (#42) is a ticket lookup: it matches tasks by their #N number and returns only task hits, skipping backlog, projects, events, and conversations. The match is a prefix (#4 finds 4, 40, 41), with the exact number first and active tasks ahead of archived ones. kangentic_search_tasks accepts the same syntax on the board scope. A bare number with no # stays an ordinary text search.

Sessions

Per-task session history, transcripts, and handoff.

kangentic_list_sessions

List Sessions - session records for a task with start and end times, exit codes, suspension reasons, cost, token counts, and duration.

kangentic_get_session_history

Session History - read the agent’s native session history file (Claude JSONL, Codex rollout JSONL, or Gemini chat JSON) for a task’s most recent session. A transcript over 16 MB is parsed from its most recent 16 MB only, and the result carries a leading notice saying how much was left out, so a conversation never just starts partway through with no explanation.

kangentic_get_session_files

Session Files - absolute paths to every per-session file (activity log, status, settings, MCP queue, native history, and more), each with an exists flag.

kangentic_get_session_events

Session Events - parsed activity events from a session’s log (the PreToolUse / PostToolUse / Stop / Notification stream), filterable by tail count, timestamp, and event type.

kangentic_get_activity_intervals

Activity Intervals - the durable history of active versus idle spans for a task or session, from Kangentic’s recorded activity-interval ledger. Shows how long a session spent working versus waiting over time, including the current idle-wait duration for a still-running session.

kangentic_reserve_dev_ports

Reserve Dev Ports - claim free TCP ports for a task before it starts a dev server, so two agents working at the same time never bind the same one.

Kangentic does not decide what a project’s ports should be. The project already does, in angular.json, a vite config, or a compose file, so nothing is reserved until an agent asks. What Kangentic can do that a project cannot is see every task and every project in the app at once. The case this exists for: several tasks sit in one column and run concurrently, and they all default to the same port.

Ask for every port you are about to bind in one call. A project needing an API and a frontend asks for count: 2, because asking twice leaves a window where a sibling task takes the second. Each returned port has been probed as genuinely free, not merely unclaimed. Getting back fewer ports than requested means the scan range ran out; fall back to the project’s own configured ports for the rest. count is capped at 10 per call.

A reservation lives until its task or its project is deleted, so a restart hands the same task the same ports. The scan range defaults to 7300-7499, picked to sit clear of every common framework default (3000, 4200, 4321, 5000, 5173, 8000, 8080). Change it with devServer.portRangeStart and devServer.portRangeEnd in the global config.json; there is no Settings UI for it. See the Configuration Reference.

kangentic_check_dev_ports

Check Dev Ports - report what a task holds and what the machine actually says about those ports. Reserves nothing.

Every port reported is probed, because a reservation is a promise rather than a fact. Reading the ledger alone is silent about the case that bites most often: a dev server started outside Kangentic entirely, on a port the ledger never handed out. Pass ports to ask about specific numbers, such as the ones a project’s own config pins, which is the only way to learn that short of trying to bind and failing. At most 20 ports per call, since each one is probed.

Each port comes back as one of four answers: reserved by this task, reserved by another task, in use by something outside Kangentic, or free. Use it to recover ports granted earlier in a session (after a resume, or before restarting a server) instead of reserving again.

kangentic_get_handoff_context

Handoff Context - the most recent cross-agent handoff record for a task: which agent handed off to which, when, and the path to the prior agent’s session history.

kangentic_get_transcript

Get Transcript - read what the agent on another task or project said, as clean structured markdown (default) or verbatim raw scrollback. Structured output supports view, tail, and search levers and a configurable character budget. Pass aroundUuid (a turnUuid from a kangentic_search conversation hit) with an optional context count to pull just the neighborhood of a cited turn instead of the whole transcript.

kangentic_send_session_message

Send Session Message - steer another task’s running agent by sending a message into its session. Self-sends are refused, and a per-target sliding-window circuit breaker stops a runaway sender from flooding a session.

kangentic_get_session_messages_sent

Session Messages Sent - the durable audit log of cross-session messages: what was sent to whom, and whether each landed (delivered, queued, refused, or failed).

Browser Automation

The kangentic_browser_* family drives the embedded Browser pane of a task (an Electron webview showing the user’s own dev server) via Chrome DevTools Protocol. Target a surface with sessionId or taskId, or omit both to use your own task’s surface. A surface in another project is refused.

The whole family is gated by the Agent Browser settings. browserAutomation.enabled is the master switch; when it is off the tools are not registered at all. Sub-gates then apply: allowInteraction gates click/type/keypress/drag (off means observe-only), allowNavigation gates navigate, and allowEval gates eval (off by default). A fifth gate, restrictNavigationToLocalhost (off by default), confines navigation to localhost and private hosts when enabled.

Surface handles and implicit targeting

Two things about targeting changed in v0.38.0, and both are contract changes worth reading before you pass a sessionId.

sessionId is a surface handle, not an agent session id. It looks like pane_<8 hex> for a visible pane or lane_<8 hex> for an offscreen lane, and you get it from kangentic_browser_open_pane or kangentic_browser_list_panes. A handle names exactly one tab for that tab’s whole life: re-registering the same tab keeps it (a /clear rotating the owning session does not change it), and a new tab always gets a new one, so a handle can never quietly retarget to a different page. Passing something that was never a handle - an agent session id, for instance - is refused as no-pane-open.

When the tab behind a handle is gone, the call fails with surface-gone rather than being redirected. The error says why the tab went, how long ago, that per-tab state (sessionStorage, in-memory app state) did not carry over while cookies and localStorage did, and which surface to use instead.

Omitting both targets your own task only. For a caller bound to a task, resolution ranks that task’s surfaces - visible pane first, then a hand-off lane, then an isolated lane - and refuses with multiple-panes (carrying the candidates) when two share the top rank, or no-pane-open when the task has none. It never falls through to another task’s pane, however many are open in the project: that fall-through was observed navigating a sibling task’s signed-in app to an identity-provider URL. Only a caller with no task - a human-driven client, a Command Terminal, or the two-segment .kangentic/mcp-config.json URL - uses the project-wide rule of “a surface my own session owns, else the single pane open in the project”.

Every driving tool can therefore return surface-gone alongside the older shared refusals: no-pane-open, multiple-panes, foreign-project, pane-destroyed, pane-not-rendering, cdp-attach-failed, pane-busy, and driver-error.

kangentic_browser_list_panes

List Browser Panes - list the open embedded Browser surfaces in your project, with their handle (sessionId, the value to pass back), the agent session that owns them, taskId, kind (pane or lane, flagged handoff for a lane standing in for a closed pane), current URL, and whether the surface is alive and debugger-attached. Use it to discover a target for the other tools, or to confirm the user has a dev server loaded. Panes in other projects are excluded by default; pass includeOtherProjects to see them too, though they are listed for visibility only and cannot be driven. Returns an empty list when no pane is open.

Each surface also carries visibility: showing (the user can see it), hidden (the user put it away behind the terminal with the Browser pill), parked (the user closed its window), or offscreen (a lane). Every value is still driveable - the field says whether the user can watch what you are doing, not whether you may act. A pane the user closed with Close browser is not listed at all; its handle answers surface-gone.

kangentic_browser_open_pane

Open Browser Pane - open the Browser pane for your own task and load a URL, so you can then drive it with the other kangentic_browser_* tools. Use this instead of asking the user to click the Browser pill. It opens the task’s detail window if it is not already open, and returns the pane once it is registered and driveable, so the very next call can act on it.

It shows a hidden pane again. A pane the user hid with the Browser pill, or whose window they closed while you were live, is still registered and driveable, so the call takes the warm path and additionally asks the app to surface it: same tab, nothing reloaded, and the window it raises is agent-stamped so its terminal never steals the user’s keyboard. Only close_pane discards. The visibility on a warm response is a snapshot taken before that re-surface is applied, so call list_panes afterwards if you need the settled value.

url is optional; omit it to reuse the task’s saved Browser URL or the project default. If neither exists, pass one, because a pane with no URL registers nothing and cannot be driven. Calling it again with a different url navigates the existing pane rather than reopening it. This tool only ever targets your own task; there is no way to open a pane for another task or project. It is gated by allowNavigation, not by a separate gate.

Pass isolated: true to get a private browser lane instead of the task’s shared pane, for when several agents are working on one task at once and would otherwise fight over a single viewport. A lane renders offscreen: it never disturbs the user’s pane and cannot take their keyboard focus. It shares the task’s cookie jar, so it inherits logins the user already has. The response returns a laneId, which is the lane’s surface handle - pass it as sessionId on every later kangentic_browser_* call, or the call falls back to the task’s visible pane and undoes the isolation. An isolated lane ranks last in implicit resolution, and two of them with no handle given refuse multiple-panes. See Browser Lanes.

kangentic_browser_close_pane

Close Browser Pane - discard Browser panes, exactly as the user’s Close browser control does. This is not what the Browser pill does: the pill only hides a pane, keeping the page loaded for you. The task’s detail window stays open. With no arguments it closes your own task’s pane; pass all to close every pane in your project, which takes precedence over sessionId and taskId. Panes in other projects are left alone and reported as a count unless you pass includeOtherProjects, which is off by default because another project may have an agent mid-verification in its pane. The response lists the panes actually closed, so a partial close is never reported as complete. A pane you close this way is never handed off to a lane.

kangentic_browser_navigate

Navigate - point a task’s Browser pane at a URL. Gated by allowNavigation.

kangentic_browser_screenshot

Screenshot - capture the Browser pane as an image.

If the page is showing a dev-server build-error overlay, the call returns a dev-server-error describing the failure instead of a picture of the red rectangle. The check runs inside the same drive as the capture, so the two can never disagree about what was on screen.

kangentic_browser_screenshot_element

Screenshot Element - capture a single element in the Browser pane.

kangentic_browser_query_dom

Query DOM - get the HTML and box model of an element.

kangentic_browser_query_all

Query All - measure every element matching a selector in one call.

kangentic_browser_bounding_box

Bounding Box - the CDP box model of an element. Its quads are page coordinates and do not account for scroll, while kangentic_browser_click takes viewport coordinates. Do not feed one into the other; click by selector instead, which scrolls the element into view and measures it there.

kangentic_browser_console

Browser Console - read recent console messages from the pane.

kangentic_browser_wait

Wait - wait for an element or text to appear. Each poll takes the pane on its own rather than holding it for the whole wait, so a long wait never blocks another agent’s click or screenshot. A refusal (pane gone, busy, or policy) ends the wait immediately instead of retrying to the deadline.

kangentic_browser_click

Click - click an element or a point in the pane. Gated by allowInteraction.

kangentic_browser_type

Type - type text into the Browser pane. Gated by allowInteraction.

kangentic_browser_keypress

Keypress - send a key or chord to the pane. Gated by allowInteraction.

kangentic_browser_drag

Drag - drag from one element to another. Gated by allowInteraction.

kangentic_browser_eval

Eval - evaluate a JavaScript expression in the loaded page. Off by default; gated by allowEval. An expression that has not settled after 20 seconds is abandoned and reported as an evaluation error, so a promise that never resolves cannot hold the pane against every other caller.

Diagnostics

Read-only tools for inspecting Kangentic itself. This group is dev-leaning and renders last in the panel.

kangentic_query_db

Query Database - run a read-only SQL query against the project database. The connection uses PRAGMA query_only = ON, so writes are rejected.

kangentic_tail_logs

Tail Logs - read recent lines from the Kangentic console log. Errors and warnings are always captured; info, debug, and log levels only when developer.persistConsoleLogs is on.

kangentic_get_recent_crashes

Recent Crashes - list recent crash records with source-mapped stacks and the version captured at crash time. Always on, no toggle required.

kangentic_get_process_metrics

Process Metrics - a live snapshot of memory and CPU per Electron process (main, renderer, GPU, utility) plus version and uptime.

kangentic_get_ipc_log

IPC Log - recent IPC traffic with per-call timings and errors. Available only when developer.recordIpcTraffic is on; channels carrying secrets are redacted.

kangentic_list_worktrees

List Worktrees - enumerate worktrees for one or every project, each with branch, base ref, dirty flag, commits ahead/behind upstream, and last-commit time.

Note

Development builds register an additional kangentic_devtools_* family for inspecting Kangentic’s own UI. Those tools are excluded from production binaries at compile time and are not part of the shipped tool surface, so they are intentionally left out of this reference.

Next steps

Next: Agent Orchestration - how the board spawns, suspends, and resumes the agents that call these tools.

See also:

• Configuration Reference - the mcpServer.enabled toggle and related settings
• Settings - the MCP Server and Agent Browser settings tabs
• Quick Find - the palette backed by kangentic_search