StackJack Platform Tools (stackjack_*)

Alongside connector tools, StackJack serves platform tools under the stackjack_ prefix. They need no connector at all — a freshly created tenant with zero connectors configured can call the baseline…

Written By Christopher Scaminaci

Last updated About 22 hours ago

Alongside connector tools, StackJack serves platform tools under the stackjack_ prefix. They need no connector at all — a freshly created tenant with zero connectors configured can call the baseline tools. They are the "getting started" and self-service surface for any connected harness: session diagnostics, platform status, live documentation, support tickets, automation control and building, and — when catalog mode is enabled — on-demand tool discovery.

Most of them are on by default. Diagnostic and live-documentation tools are served to every connected harness automatically. Interactive MCP clients also receive all four support-ticket tools automatically. An Automation's dedicated MCP client keeps the two support reads but must opt into the two support writes, as explained below. A restricted tool selection does not otherwise hide these baseline tools. The remaining exceptions to "always on" are:

The billed stackjack_run_agent action, the two agent-config reads, and the automation authoring/lifecycle tools require an explicit per-client grant plus the Agentic Orchestration feature. Details in Automation tools below.
The five catalog feature tools appear only when catalog machinery is active for that connection. Full and compact modes list the four direct discovery/dispatch tools; minimal also lists the folded stackjack_platform router. The two catalog-mode switch tools (stackjack_get_catalog_mode / stackjack_set_catalog_mode) are the deliberate exception: they are visible in every mode, and even when catalog modes are switched off — an escape hatch you can only see once you have already escaped would be no help.

Everything else on this page is available without being selected, subject to the Automation support-ticket guardrail below.

The always-available diagnostic set

The diagnostic tools below are visible to every connected client — they can't be deselected, because they change nothing in StackJack or your connected products and exist so any harness can diagnose itself. All except stackjack_refresh_tool_list are flagged read-only in their MCP metadata. Refresh retains its action classification; it only reports the version and refresh instructions, and it mutates no tenant or connector data.

Tool	What it does
`stackjack_session_info`	Shows your session context: tenant, MCP client, each active connector whose credentials loaded for this request with its plan and monthly call limit, plus how many tools are accessible versus the total. A connector that needs your own sign-in before its tools will run carries `"status": "personal_sign_in_required"` and guidance on the row. If an expected connector is absent for some other reason, verify it on the portal's Connectors page or use `stackjack_health_check`.
`stackjack_list_tools`	Lists platform tools plus tools for connector credentials that loaded on this request, with each tool's required plan and an `accessible` flag. A transient credential-load failure can therefore omit a subscribed connector from this diagnostic projection even while protocol `tools/list` keeps that configured family discoverable; use `stackjack_health_check` when an expected family is absent. Supports optional filters by category (standard/advanced/premium) and by connector (the filter accepts any connector name or common alias across all connectors — for example halo, connectwise, meraki, ncentral, or eset).
`stackjack_health_check`	Live-validates the stored credentials of every configured connector against its vendor API and reports status, latency, and error detail per connector (a connector whose stored credentials can't be loaded is reported as `unavailable` and retryable rather than being probed). Pass an optional `connector` filter to probe just one. If your workspace has no connectors configured, it returns a `no_connectors` status pointing you to the portal; you can also validate any connector on the portal's Connectors page.
`stackjack_get_service_status`	Overall StackJack service status, component statuses, maintenance notices, advisories relevant to your connectors, and the current tool-catalog version.
`stackjack_list_advisories`	Lists published advisories, filterable by kind (incident, maintenance, advisory, release, tool recommendation), severity, connector, or tool name.
`stackjack_get_release_notes`	Tool-catalog release and patch notes; ask "what changed since version X" with the `sinceVersion` parameter.
`stackjack_get_tool_guidance`	Operator-published guidance for a specific tool — for example a deprecation notice with the recommended replacement.
`stackjack_refresh_tool_list`	Reports the current catalog version and explains how to refresh the list. StackJack cannot push a live update into an open session: have the harness re-list tools, or disconnect and reconnect when its cached list remains stale.
`stackjack_get_quota_status`	Shows how much of the current billing cycle's tool-call allowance each subscribed connector has used — calls used, the monthly limit, percent used, calls remaining, when the cycle resets, and an `approachingLimit` flag. See Checking your remaining call allowance below.
`stackjack_list_connections`	Lists every connection your workspace holds, grouped by connector — the connection's name and key, which one is the default, whether it is enabled and valid, and which one this endpoint is pinned to. A connector can hold more than one connection, one per customer or server; the names listed here are what your AI passes in the optional `connection` argument on that connector's tools. Contains no credentials. If this endpoint is pinned to one connection, only that connection is listed for that connector, because it is the only one this endpoint can reach. A connector whose shared connection is an owner's own sign-in that you cannot use carries `"status": "personal_sign_in_required"` on the connector, with the reason in its `note` — the connection itself is healthy, it is just not yours to run.

Checking your remaining call allowance

Every connector subscription carries a monthly tool-call limit that resets on that connector's own billing cycle. Once it is reached, further calls to that connector are refused with a monthly_limit_exceeded error until the cycle resets.

stackjack_get_quota_status lets a harness see that coming. It is worth calling before a large batch of work, and again after any monthly_limit_exceeded refusal to see which other connectors are close. It reports one row per subscribed connector:

Field	Meaning
`used`	Calls recorded against the current cycle.
`monthlyCallLimit`	The limit actually enforced for this connector. `null` when the subscription is uncapped.
`unlimited`	True when no cap applies, in which case `percentUsed` and `remaining` are `null`.
`percentUsed` / `remaining`	How far into the allowance you are, and how many calls are left.
`approachingLimit`	True once usage reaches the warning threshold — 80% by default.
`overLimit`	True once the limit is reached; the next call to that connector will be refused.
`periodResetUtc`	The nominal instant this connector's cycle rolls over and the counter returns to zero. Nominal because the reset is applied by the renewal that follows it, so a counter can briefly still show the old cycle's total just past this time.
`usageUnavailableReason`	`null` in the normal case. Carries a reason code when the usage counter could not be read, in which case `used`, `percentUsed` and `remaining` are all `null` rather than guessed — the limit and reset time are still accurate. See the codes below.

The response also opens with a summary, so a harness need not scan every row:

Field	Meaning
`thresholdPercent`	The warning threshold in force — 80 unless StackJack has changed it.
`anyApproachingLimit` / `anyOverLimit`	True if any connector is at or past the threshold / its limit. `null` when no connector's counter could be read — unknown, not "all clear".
`anyUsageUnavailable`	True when at least one connector's counter could not be read, including when the others could. Treat it as "re-read the rows", never as "no news is good news".

When usage cannot be read, the reason code says what to do about it:

Code	Meaning	What to do
`usage_counter_unavailable`	StackJack could not reach the usage counter at all.	Transient. Try again shortly.
`connector_credentials_unavailable`	This connector's stored credentials could not be loaded on this request.	Transient. Try again shortly; `stackjack_health_check` confirms.
`connector_not_configured`	The connector is subscribed but has no credentials set up.	Not transient — configure it on the portal's Connectors page. Its allowance is real and untouched.

Three things worth knowing:

Each connector has its own cycle. The counters and reset dates are per connector, not one shared monthly pool — a periodResetUtc next Tuesday on one connector says nothing about another.
Counts are as of the moment you ask. The figure does not include the call you are making right now.
A null count means unknown, never zero. StackJack will not guess a usage figure it could not read; that is the one wrong answer a pre-wall warning must not give.

The rows cover every connector you are subscribed to, which is slightly wider than the connector list stackjack_session_info reports — that one lists what is usable on the current connection, while an allowance exists whether or not credentials happen to be loaded. The extra rows always carry a usageUnavailableReason saying which case they are.

The same warning also arrives without being asked for. When a connector tool call is served while that connector is at or above the threshold, StackJack attaches a small stackjack.quota note to the result's protocol metadata (_meta). Adding that note does not change the response body — it rides beside the answer rather than inside it, so a harness that ignores _meta sees no difference at all. Two other things can change a body, and neither is this one: a documented adapter for file downloads and non-JSON vendor protocols, and an enabled response-shaping rule. See What a tool call returns. Harness support for surfacing metadata varies; treat the note as a bonus, and stackjack_get_quota_status as the reliable way to check.

The same numbers appear in the portal on the Connectors page, where each connected card carries a usage bar that turns amber at the same 80% point and red once the limit is reached.

To raise a limit, contact your StackJack administrator or support.

The "pending approval" signal

If a team member connects before an admin has assigned them any tools, stackjack_session_info returns a special pending_approval response telling the AI (and the user) that the connection works but an admin needs to approve them on the Team page and assign tool permissions. If a teammate reports "it connects but nothing works," ask them to run this tool first.

Live documentation tools (always available)

The live-documentation tools below let a harness read StackJack's own product documentation and browse the tool catalog on demand — so the AI can answer "how do I connect Halo?" or look up a tool's schema without leaving the conversation. Like the diagnostic set, they are served to every connected client automatically and are never plan-gated.

Tool	What it does
`stackjack_search_docs`	Searches StackJack's product documentation (how-to guides, connector setup, concepts) and returns ranked page matches — slug, title, section, and a snippet — without full page bodies.
`stackjack_get_doc_page`	Fetches one documentation page by slug (from a `stackjack_search_docs` hit) as cleaned markdown, with its title, section, and headings.
`stackjack_get_tool_catalog`	Browses the tools your organization and your connection can actually use, grouped by connector. Returns an overview of per-connector counts and tiers, or a single connector's tools (optionally with full input schemas). Connectors your organization is not subscribed to, or has not set up, are not listed.

Support ticket tools

Four tools let a harness open and follow up on StackJack support tickets. For interactive MCP clients, all four are automatic: they do not need to be selected, and a restricted tool selection does not hide them.

Automation clients use a stricter policy. stackjack_list_support_tickets and stackjack_get_support_ticket remain available, but stackjack_create_support_ticket and stackjack_add_support_ticket_message are deny-by-default. To let an Automation open or reply to tickets, enable Allow this agent to raise a StackJack support ticket for errors under its Guardrails. When that toggle is off, the two write tools are hidden from the agent's discovery response and refused if called directly; this is enforced separately from the normal tool selector.

Tool	What it does
`stackjack_create_support_ticket`	Files a new support ticket for your organization.
`stackjack_list_support_tickets`	Lists your organization's tickets with status and priority.
`stackjack_get_support_ticket`	Fetches one ticket with its full message thread.
`stackjack_add_support_ticket_message`	Adds a reply to a ticket (replying to a closed ticket reopens it).

When a connector execution routed through StackJack's shared gateway fails with one of the 14 support-worthy error types, its response can include a prefilled ticket draft and a next action that tells the harness to ask before calling stackjack_create_support_ticket (details). Bad requests, validation failures, not-found responses, rate limits, and ordinary access or billing refusals deliberately do not receive a draft.

Ticket creation commits the ticket first, then attempts the system diagnostic bundle and sanitized MCP-log upload as two independent best-effort steps. The response reports diagnosticsAttached: true when at least one succeeds; the ticket still exists when both fail. For an Automation, the separate diagnostic-payload guardrail controls whether the system bundle can include tenant identity detail. Interactive clients receive the full bundle.

The anti-flood controls have distinct windows:

Every create attempt first consumes a counter capped at 30 per tenant per hour, before any duplicate check runs — so an attempt answered with an existing ticket still spends one.
Interactive duplicates are looked up over 15 minutes by tenant, harness source, source tool, and error type; a match returns the existing open ticket.
Automation duplicates are looked up over 24 hours and also include the raising Automation. A match appends an occurrence note to the existing ticket instead of opening a second one.
New Automation-raised tickets are capped at 20 per tenant per UTC day. A suppressed response says not to retry. Duplicate appends bypass that daily-new-ticket cap but still consume the hourly attempt.

Automation tools (feature-gated)

The tools below let a harness discover, run, and build your StackJack Automations. All of them require the Agentic Orchestration feature, which is on by default for every workspace; StackJack can suspend it for an account, and while it is off these tools are hidden from discovery and any direct call returns a feature_disabled error — contact support if you are in that state. Once the feature is on, they split by risk:

These MCP-facing platform tools are separate from the three native Anthropic tools that an Automation can enable for web search, web fetch, and sandboxed code execution.

stackjack_list_agents, stackjack_get_run_transcript, stackjack_get_agent_run, and stackjack_suggest_agent_tools are served to every connected client automatically — like the other platform tools, a restricted tool selection doesn't hide them.
An explicit per-client grant is required for stackjack_run_agent (it triggers billed agent runs), the two config reads stackjack_list_agent_configs / stackjack_get_agent_config (they expose automation configurations including system prompts), each authoring/lifecycle tool — stackjack_draft_agent, stackjack_update_agent_draft, stackjack_set_agent_lifecycle, stackjack_accept_agent_consent, stackjack_manage_agent_knowledge, stackjack_delete_agent, stackjack_delete_run_transcripts, stackjack_stage_agent — and each maintenance tool: stackjack_set_agent_definition, stackjack_get_agent_definition, stackjack_describe_agent_schema, stackjack_inspect_agent, stackjack_apply_agent_maintenance, stackjack_control_agent_run, stackjack_manage_agent_templates, and stackjack_manage_agent_memory. Each is granted by name, so an admin can let a client attach knowledge and re-provision without letting it accept consent, rotate a webhook secret, or delete anything. A client with no tool restriction gets them automatically once the feature is on; a client with a restricted selection must include each one deliberately — including any tool StackJack ships after that selection was made.
A harness with these grants can build and maintain an automation end to end, the same way a person can in the builder: create it, revise it after it is live, change its schedule, write its fixed start and finish steps, accept its acknowledgments, install one from a template, and read why a run did what it did. Two things bound that. Every change is made as the person whose sign-in the connection is using — a client with no person behind it (an admin-created key) is refused on every write — and that person passes exactly the checks they would pass in the Portal. And adding or changing a step that changes something asks for the destructive-action acknowledgment again: the acknowledgment covers the list of those steps that existed when it was given, so changing that list withdraws it, and nobody can run those steps until a person accepts it again.

Tool	What it does
`stackjack_list_agents`	Lists the automations exposed to harnesses across every trigger type. They must be active, consent-accepted, MCP-exposed, and otherwise runnable. A `SyncNeeded` automation remains listed intentionally, with a warning, because an invocation may still run against its current provisioned state. Each entry discloses what to pass as `context`: payload mode, selected field paths, and any saved sample payload.
`stackjack_run_agent`	Starts an exposed automation by id or name and returns immediately with a `runId` — it does not wait for the run to finish, because a run may legitimately outlast the request. Poll `stackjack_get_agent_run` with that id until it reports `isTerminal`. A stable `idempotencyKey` you generate is required: retrying with the same key returns the same run instead of starting and billing a second one. Every harness invocation is recorded as a Manual run, including scheduled and webhook automations invoked off cadence. Pass webhook context in the disclosed shape. `rerunOfRunId` reuses that run's exact stored trigger payload but executes the automation's current mutable configuration, creates a fresh run, and bills it separately. A stored `AgentVersionId` is partial version attribution, not proof that every executed setting was an immutable snapshot. Managed-key runs settle through StackJack credits; with BYOK, StackJack bypasses its credit ledger and Anthropic bills your account directly.
`stackjack_get_agent_run`	Reports how a run started by `stackjack_run_agent` is going: its status, the summary once it finishes, and the credits and tokens it consumed. `isTerminal` tells you when to stop polling — a status this build does not recognize reads as not terminal, so an unfamiliar state keeps you polling rather than stranding you believing a live run has ended. For the turn-by-turn detail behind the summary, use `stackjack_get_run_transcript`.
`stackjack_get_run_transcript`	Fetches one page of live Anthropic session events for a running or completed tenant run with a session. Events are oldest-first and are fetched live from Anthropic; the full transcript stream is not stored by StackJack as a transcript. Separate run, usage, audit, tool-call, argument-capture, and opted-in fixture records can still retain execution fields under their own controls and retention rules. Treat `page` as an opaque cursor: pass the previous response's `next_page` value while `has_more` is true or `next_page` is non-null. The raw events can contain customer data, tool arguments, and tool results. A run with no session, or a session no longer available upstream, has no transcript to return.
`stackjack_suggest_agent_tools`	Suggests connector tools for an automation you describe in plain language, ranked by relevance and limited to what your subscriptions can actually call. Destructive tools are flagged.
`stackjack_list_agent_configs`	Lists your automations with their configuration summaries (tools, trigger, model, state) — including drafts. Grant-required because it exposes configuration detail across all automations.
`stackjack_get_agent_config`	Fetches one automation's full configuration plus a readiness report. Grant-required because it reads the system prompt.
`stackjack_draft_agent`	Creates a new automation draft — name, prompt, tools, trigger, guardrails, notifications, reasoning effort, webhook payload disclosure, MCP exposure, outbound network access, run-as identity, and the support-ticket toggles. The draft is saved unprovisioned, inactive and in dry-run mode, so it cannot run or reach a customer system until it is provisioned. The response links you to it in the Portal.
`stackjack_update_agent_draft`	Edits an automation's configuration — a draft you have not finished, or one that is already live and running. A change to a live automation applies to its next run, and the configuration it replaced is kept as a version you can restore. Turning an automation on or off, and moving it in or out of dry-run mode, belong to `stackjack_set_agent_lifecycle` instead; the fixed start and finish steps belong to `stackjack_set_agent_definition`.
`stackjack_set_agent_lifecycle`	Provisions or re-provisions an automation, promotes it out of dry-run so its tools act on real customer systems, returns it to dry-run, or turns its trigger on and off. The Portal can provision a draft too; this tool is the harness-facing lifecycle path, not the only route that can make a draft runnable.
`stackjack_accept_agent_consent`	Records general/autonomous consent, destructive-action consent, or both. General consent stores a timestamp only. Destructive consent records the harness-prefixed MCP client identity and appends the authenticated user identity when one is available. It cannot be withdrawn here; archive the automation instead.
`stackjack_manage_agent_knowledge`	Lists, adds, replaces, re-crawls, or removes the knowledge sources inlined into an automation's prompt. `refetch` re-reads a URL source right now. `add_file` attaches a document by sending its bytes base64-encoded, up to 2 MB once decoded; text formats, PDF and modern Word, Excel and PowerPoint documents have their text extracted, and older binary Office formats are refused. Attach a larger document in the Portal. `update` edits a source in place and keeps its id; a new URL is read at once and keeps its re-crawl schedule; a file takes a new name only.
`stackjack_set_agent_definition`	Replaces an automation's fixed start and finish steps, or its tool chains. The document replaces what is stored, so read the current one first and send the whole thing back — anything left out is gone. An empty string removes the document. Pass `expectedDocument` with exactly what you read and the write is refused rather than applied if somebody else changed it in the meantime, which is what stops a replacement silently discarding a step you never saw. It never returns the document; read it back with `stackjack_get_agent_definition`.
`stackjack_get_agent_definition`	Reads one document at a time: the fixed start and finish steps, the tool chains, the trigger configuration, the tool policy, the version history, or the difference between two versions. A version comparison also lists the settings a version does not capture at all, so "nothing changed" can be read correctly.
`stackjack_describe_agent_schema`	Returns the authoring rules and worked examples for those documents — the step kinds, how one step reads another's result, the tool-policy modes, trigger configuration, and the decision question model. It reads nothing about your automations, and it is where the contract lives so the other tools' descriptions can stay short.
`stackjack_inspect_agent`	Reads what an automation has been doing rather than how it is configured: its recent runs, what arrived at its webhook address and what happened to each delivery, what its smart filter decided, the decisions one run recorded, its lifecycle audit, whether its schedule is actually registered, which of its tools nothing references, and the tools its runs tried to call and could not. This is the view to open when somebody asks why an automation did not run.
`stackjack_apply_agent_maintenance`	Restores a saved version, removes the tools nothing references, registers a schedule again, rotates webhook secrets, or grants tools an automation's runs asked for. Every action requires an exact confirmation string, and the refusal that hands it to you also says what the action will do. Rotating breaks every existing sender immediately and does not return the new secrets — a person reads those in the Portal. Retiring an automation is not an action here; use `stackjack_delete_agent`.
`stackjack_control_agent_run`	Stops a run that is going, or answers a run that paused to ask permission for a destructive tool call. Stopping a run does not undo the changes it already made. Approving is agreeing on the user's behalf, so ask them first and say what the call will do; who answered is recorded against the decision.
`stackjack_manage_agent_templates`	Lists the automation templates available to your organization, reads one in full, or installs one as a new automation. An installed automation starts in dry-run mode with no acknowledgment of its own, exactly like one drafted by hand. Pass the template version you reviewed and the install is refused if the template was republished in the meantime.
`stackjack_manage_agent_memory`	Reads what an automation remembers between runs, removes one saved revision, erases the whole memory, or moves it to the engine the automation is about to run on (StackJack's own, or your Azure Foundry, where StackJack keeps it) before you switch where it runs. Memory contents are whatever the automation wrote down about the systems it works on, so treat them as customer data. Removing a revision and erasing a memory are permanent and each requires an exact confirmation string.
`stackjack_delete_agent`	Uses the legacy delete action to retire an automation. After remote cleanup it archives the local automation and disables execution; it does not hard-delete the complete audit record. Run, version, and audit history remain, and cross-run memory is retained as archived memory. Incomplete remote cleanup leaves an inactive repair row for later cleanup rather than pretending deletion completed. The exact guard is `DELETE '<automation name>'`. To stop execution without retiring it, use `stackjack_set_agent_lifecycle` with `deactivate`.
`stackjack_delete_run_transcripts`	Permanently deletes the transcripts of an automation's runs: the conversation, each run's input and final answer, and the tool inputs, from StackJack and from our AI provider. The run records stay: status, times, credits used and which tools ran. Pass the run ids, or `all: true` for every finished run of the automation. Call it once with an empty `confirm` to get the counts and the exact text, then call it again with that text. With `all: true` the text is `DELETE ALL TRANSCRIPTS`, and every run finished by then is deleted. With a list of run ids the text is `DELETE <N> TRANSCRIPTS`; if the number changes in between, the call is refused and you ask for the counts again. Runs that are still running are skipped, and a run whose billing is not final is deleted once it is. Only owners and administrators can do this, and never from an automation's own connection. A deleted run cannot be re-run or saved as a test scenario.
`stackjack_stage_agent`	Creates, deploys, or discards a staging copy. Creation copies the trigger and schedule, behavior, tool/native-tool policy, bookends, and knowledge, but gives the copy no consent or run-as binding and resets MCP exposure, failure notifications, and the support-ticket toggles; fixture recording and the concurrent-run setting are copied from production, not reset. Its trigger remains inert while it is a staging row. Deploy transfers the staged behavior, trigger type and configuration (including a schedule), tool/native-tool policy, bookends, production-consent re-arm setting, the webhook-dedup setting (a copy that never set one leaves production's), and transfers the staged concurrency choice. Production preserves its identity and secrets, lifecycle/run posture, MCP exposure, run-as binding, general and existing destructive acknowledgements, fixture-recording consent, knowledge and memory, notification/support settings, passing-check policy, and published-template linkage. A deploy never changes which engine the automation runs on: when the copy and production run on different engines it is refused with `staging_runtime_mismatch` and nothing changes; when both run on the organization's Azure Foundry, the Foundry spend guard transfers. Destructive consent is re-armed only when the staged callable set introduces a destructive tool that production did not already include.

Drafting is only the start of what a granted harness can do: these tools cover the whole automation lifecycle, including editing a live automation, promotion, and destructive-action consent. Three controls bound them. First, every grant-required tool is granted by name, so an admin decides exactly how far a given client reaches. Second, every change is made as the person whose sign-in the connection is using, and that person passes exactly the checks they would pass in the Portal — a client with no person behind it is refused on every write. Third, the irreversible actions require exact confirmation text: accepting consent, retiring an automation, deleting run transcripts, deploying a staging copy, restoring a version, trimming tools, registering a schedule again, rotating webhook secrets, granting proposed tools, removing a memory revision, and erasing a memory. These are deterministic request guards: callers can compute or obtain the expected text, and the strings are not nonce-based, expiring, one-shot, or bound to a named approver. They create a deliberate second-call workflow, but the server cannot prove that a person saw or approved the consequence. Grant these tools only to clients whose confirmation behavior you trust.

If you need a named person on the general-consent record, accept it in the Portal; only the destructive-consent path can append an authenticated harness user when one is present. stackjack_accept_agent_consent cannot withdraw consent; archiving the automation is the way back.

When your organization is already using all its concurrent run slots — or the platform pool is full — a harness launch is queued rather than refused. stackjack_run_agent still returns immediately with a runId, but the run's status starts as Queued and it begins when a slot frees; keep polling stackjack_get_agent_run exactly as you would for a running run. A queued run that waits past its deadline ends as Skipped. That deadline is one hour by default, configurable per automation, and shorter for a scheduled automation so a queued run can never still be waiting when its next tick fires. The same applies when another run of the same automation is already in progress: the new attempt queues behind it.

capacity_exceeded is therefore a narrower signal than it sounds. It means queueing was not available for that attempt, and it has two sources: the global run-slot pool shared across the platform, and your own organization's concurrency limit. Read the returned message — a per-organization refusal names your organization and its slot count, and is not a StackJack outage. Transcript upstream rate limiting uses the same code.

A paused (Awaiting Input) run is separate again: it holds no slot and counts against neither limit. Resuming one is the single action that is refused rather than queued when capacity is short, which leaves the run resumable — try the resume again shortly.

Catalog-mode tools

When catalog machinery is active for a connection, five feature tools become eligible to power on-demand discovery and dispatch. Full and compact modes advertise the four direct tools; minimal advertises those four plus the stackjack_platform router. If the machinery is inactive, all five are absent.

The last two in the table are different: the catalog-mode switch tools are served to every connection in every mode, including when your organization has catalog modes switched off (in which case they answer with a plain "catalog modes are not enabled for your organization" and change nothing). They are the escape hatch — a harness whose tool list has been truncated by its own client-side budget can see the problem and fix it itself, without anyone opening the portal first. A restricted tool selection can't hide them either. All seven are Free (never plan-gated).

Tool	What it does
`stackjack_search_tools`	Searches the current session's permitted, configured tool catalog by a natural-language query and returns ranked matches with each tool's plan, safety flags, and how to run it in the current mode. Connector rows with no credential record are withheld from search.
`stackjack_describe_tools`	Returns the full description, required plan, safety flags, and JSON input schema for up to 10 named tools — inspect a tool before running it.
`stackjack_run_readonly_tool`	Runs a read-only connector tool by name and returns that target tool's normal result, including any documented file/protocol adapter or enabled response-shaping rule. Refuses non-read-only tools (use `stackjack_run_tool`). Because the dispatcher is marked read-only, a compatible harness can choose to auto-approve it.
`stackjack_run_tool`	Runs any permitted connector tool by name — including writes and destructive actions — and returns that target tool's normal result, including any documented adapter or enabled shaping rule. It applies credential, subscription, billing, allowance, and safety gates at execution. The dispatcher itself is marked destructive so compatible harnesses can ask for approval; clients differ, so do not assume every harness will prompt.
`stackjack_platform`	Minimal-mode router for ordinary StackJack platform tools (diagnostics, docs, support, and the default-on Automation reads). It refuses grant-gated Automation run/configuration/authoring tools; switch to Compact or Full so those tools appear natively and their per-client grants remain visible.
`stackjack_get_catalog_mode`	Reports the mode this connection is being served, where that mode came from, how many tools are actually being advertised versus how many you can reach in total, and which tools are pinned. Read-only, so a well-behaved harness can auto-approve it.
`stackjack_set_catalog_mode`	Switches this connection to `full`, `compact`, or `minimal` — or back to `inherit`, which clears the connection's own setting so it follows the organization default again (the portal's "Auto (inherit)"). It saves the preference against the MCP client (or, for a personal OAuth sign-in, against your membership) — the same settings an admin edits in the portal — and it applies to the next tool list, so the harness has to refresh. On a successful `inherit` it reports which setting it now follows. If the connection's mode is being forced by a `?tools=` URL or a host alias, it says so instead of silently doing nothing.

Dispatching a tool through stackjack_run_readonly_tool, stackjack_run_tool, or stackjack_platform runs the real tool with every permission, configuration, subscription, billing, allowance, and safety check applied exactly as a direct call — and usage is attributed to the tool you actually ran, not the dispatcher. For how modes, pins, and enablement work, see Catalog modes.

Do platform tools count against my quota?

Monthly allowances are per connector, and an ordinary platform tool is not a connector call. Session diagnostics, docs, status, catalog and support tools can be used freely without consuming any connector's allowance.

The dispatchers are the exception, and they are not really an exception at all. stackjack_run_readonly_tool, stackjack_run_tool, and stackjack_platform are wrappers: when one of them runs a connector tool, the connector call is real and is metered against that connector's monthly allowance exactly as a direct call would be. Usage is attributed to the tool that actually ran, not to the wrapper, so routing through catalog mode neither adds a charge nor avoids one.

Still need help? Ask the team