Choosing Tools for Each Client and Managing Harness Tool Limits

Beyond plan tiers, you control exactly which tools each MCP client (the credential a harness connects with) and each team member can use. This page covers the tool selector on the Endpoints page, how selections are enforced, and how to work within harness tool limits — especially Microsoft Copilot Studio's tight MCP catalog budget. If your harness silently drops tools because your catalog is large, jump to Large catalogs & compact mode. If you are not sure which control you actually want, start at How do I narrow a connection?.

Where tool selections live

The same tool-selection interface appears everywhere you grant tool access:

• Endpoints — when creating or editing an MCP client, you choose the tools that client can call, or — once that client holds a custom tool role — the extra tools layered on top of what the role already grants (the button becomes Edit Extras).
• Team — when inviting a member or editing a member's grants, you choose the tools that person can use, or — once that member holds a custom tool role — the extra tools layered on top of what the role already grants (the button becomes Edit Extras).
• Automations — when building an automation, you choose the connector and explicitly grantable platform tools the agent may call. Support-ticket tools are not ordinary selector entries: read-only ticket lookup stays available, while the separate Guardrails setting described below controls whether the agent can create or reply to a ticket.

Using the tool selector

• The advanced selector has a connector/category tree and a search box that matches tool name, connector, display name, or description. Connector chips (the first eight plus a more control), Read, Write, Destructive, plan-tier, and Only selected facets compose with the search and tree scope.

• Each row shows its plan plus READ/WRITE and destructive safety indicators, and the selected-tool summary groups chips by connector. Endpoints and Team offer only tools within the current plans. The Automation picker additionally shows over-plan tools as locked upgrade rows; selecting one opens the upgrade affordance rather than granting it.

• Quick actions are All Tools, Read Only, Write, and Clear. After narrowing the advanced list, Select all shown and Deselect all shown act only on the visible search/facet result. Connector chips plus Select all shown replace the old row of one All <connector> button per connector. The redundant My Plan button has been removed. On a client or member that holds a custom tool role, All Tools does not remove the restriction — see How selections are enforced.

• Most StackJack platform tools (stackjack_*) are served automatically and are not shown as selectable toggles — this includes session diagnostics, live docs, and support-ticket tools. A restricted tool selection does not hide those baseline tools. There are two important qualifications:

  • Interactive MCP clients receive all four support tools automatically. For an Automation's dedicated MCP client, 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. Enable Allow this agent to raise a StackJack support ticket for errors under the Automation's Guardrails to expose those two write tools; when it is off, they are hidden from discovery and refused if called directly.

  • The following Automation platform tools require an explicit per-client grant:

    • stackjack_run_agent — triggers billed agent runs.
    • stackjack_list_agent_configs and stackjack_get_agent_config — read automation configurations, including system prompts.
    • stackjack_draft_agent and stackjack_update_agent_draft — create and edit automation drafts.
    • stackjack_set_agent_lifecycle — provisions an automation, promotes it out of dry-run onto real customer systems, or turns its trigger on and off.
    • stackjack_accept_agent_consent — records the autonomous and destructive-action acknowledgements.
    • stackjack_manage_agent_knowledge — changes the reference material inlined into an automation's prompt.
    • stackjack_delete_agent — archives and retire-disables the local automation after its remote cleanup; historical run, version, audit, and archived-memory records remain.
    • stackjack_delete_run_transcripts: permanently deletes the transcripts of an automation's runs, from StackJack and from our AI provider. The run records stay. Only owners and administrators can use it.
    • stackjack_stage_agent — creates a staging copy or deploys one back over production.
    • stackjack_set_agent_definition — replaces an automation's fixed start and finish steps, or its tool chains.
    • stackjack_get_agent_definition — reads one of those documents, the automation's trigger configuration or tool policy, its version history, or the difference between two versions.
    • stackjack_describe_agent_schema — returns the authoring rules and worked examples for those documents. It reads nothing about your automations.
    • stackjack_inspect_agent — reads an automation's recent runs, webhook deliveries, smart-filter decisions, lifecycle audit, schedule registration, unused tools, and the tools its runs asked for and could not call.
    • stackjack_apply_agent_maintenance — restores a version, trims unused tools, registers a schedule again, rotates webhook secrets, or grants proposed tools.
    • stackjack_control_agent_run — stops a run, or approves or denies a run that paused to ask permission for a destructive tool call.
    • stackjack_manage_agent_templates — lists and reads automation templates, and installs one as a new automation.
    • stackjack_manage_agent_memory — reads what an automation remembers between runs, removes one saved revision, or erases the whole memory.

    They appear as checkboxes only when Agentic Orchestration is enabled for your tenant, and each must be granted deliberately. The list is deliberately granular rather than one "manage automations" switch: granting by name is what lets you allow a client to attach knowledge and re-provision without also allowing it to accept destructive consent, rotate a webhook secret, erase an automation's memory, or delete anything. See Platform tools for what each one does and the confirmation strings the riskiest ones require.

    A client whose selection is a hand-picked list does not receive a newly shipped tool until you re-grant it. That is the point of a restricted selection — it is a fixed boundary, not a subscription to whatever ships next — so when StackJack adds an automation tool, open the client (or the team member) and tick the new name if you want it. A client with no restriction receives new tools automatically once the feature is on.

How selections are enforced

• A client with no restriction can call every tool the tenant's subscriptions and plans allow at the selection layer; configuration, feature, billing, consent, and other runtime gates still apply. An unrestricted grant is open-ended, so newly shipped eligible tools can become available without another selection edit. Use an explicit selection when you need a fixed least-privilege boundary. This state is not reachable for a client or member that holds a custom tool role — see the note below.
• A client with a restricted selection can call only the selected tools; everything else is hidden from its tool list and refused with tool_not_allowed if called anyway.
• When a team member with their own grants connects through a restricted client, the effective tool set is the intersection — a tool must be in both the client's selection and the member's grants.
• For a client or member that holds custom tool roles, that side's set is everything its roles grant plus its own extras. The client-side and member-side sets are resolved that way first and then intersected exactly as before.
• The tenant owner (including co-owners) is never restricted by member grants — though on a credential connection the tool selection of the MCP client they connect through still applies.

"No restriction" is not available once a role is involved. Saving "every tool" onto a client or member that holds any custom tool role is stored as an empty extras list instead. So clicking All Tools on a role-bearing client does not make it unrestricted — its effective set stays exactly what its roles grant. This is deliberate: it stops a later removal of the last role from silently escalating the target to your whole catalog. The only way a role itself reaches genuinely unrestricted access is a rule scoped to everything; see Custom roles.

Per-client tool selection is inert on the sign-in lane. Everything above about a client's selection applies to connections that present an MCP client credential — a Client ID + Secret, or an API key. A connection made by signing in is not using one of the MCP clients you created on Endpoints at all: that covers the OAuth browser sign-in most desktop AI apps use, and the per-user token connections such as Microsoft 365 Copilot's. On those connections there is no client row, so no client selection is consulted and none can be. What the connection may call is decided entirely on the person's side — their tool roles plus their extras, with owners and co-owners unrestricted. If you need a fixed least-privilege boundary for a particular harness, give that harness its own MCP client credential and restrict that credential; a selection saved on a client only binds connections that present it.

The saved selection and its discovery-time authorization agree: a name outside a restricted selection is hidden and refused. Runtime gates still apply after that check — for example a dry-run Automation intentionally sees a write so the attempted call can be recorded, then StackJack blocks execution; credentials, billing, consent, and vendor state can also refuse a selected tool.

How do I narrow a connection?

Four different controls are all called "narrowing" in conversation, and only two of them are boundaries. Pick from the effect you want, not from the word:

About that last row. Per-connector endpoints are the newest of the four and the one most often mistaken for a restriction. When they are available to your workspace, MCP Setup lists one copyable URL per connector you are subscribed to, beneath the standard and compact endpoint cards.

Point one MCP client at this URL to get only this connector's tools. Your tool selection and subscriptions are unchanged.

That is the whole effect: the URL decides what StackJack serves a cooperating client. The same credential or signed-in session still works on the standard endpoint and still receives everything it is permitted to call there, so a per-connector URL is a convenience for a client you configure, never a control over one you do not. Combine it with a restricted MCP client when you want both — the narrow list and the guarantee. Full detail: Per-connector endpoints.

What happens to selections when tools become unavailable

If a plan downgrade or connector cancellation makes previously selected tools unavailable, the behavior depends on where the selection lives:

• Automations — the automation editor flags the unavailable names as stale in a repair banner. You can remove them individually (per-chip remove) or click Remove all invalid to clean the selection in one action, and the save path filters the selection to currently valid names.
• MCP clients and team members — unavailable names are hidden from the checklist, and the "N of M tools selected" count (and the Copilot 70-tool warning) counts only currently valid tools. While unavailable, those names are neither served nor executable. A dormant saved name can become active again if the plan or connector later returns; opening and saving the selector while it is unavailable removes it because the save path keeps only currently valid names. Review explicit grants after restoring a subscription or upgrading a plan.

Harness tool limits and how to work within them

Microsoft Copilot Studio: use the compact endpoint

Copilot Studio takes at most 70 tools per MCP server. Copilot Studio's generative orchestrator has a separate 128-tool maximum per agent, and Microsoft recommends keeping agents to 25–30 tools for best performance. StackJack's selector warns when a client's valid selection exceeds 70, but the simplest Copilot Studio setup is usually catalog mode rather than trying to fit the full catalog under that warning.

Every tool-budget number in these docs is maintained in one place — see Client tool limits for what each client caps, how the number was established, and which clients StackJack reduces automatically. Copilot Studio is not one it reduces automatically, so set the mode yourself.

Recommended setup:

1. Enable catalog modes for the organization on the Settings page.
2. Point Copilot Studio at https://compact.stackjack.io/mcp.
3. Pin the small set of day-to-day tools you want visible by name. Copilot can find and dispatch every other permitted, configured tool through the compact catalog tools.

You can still create separate, narrowly scoped MCP clients for different job functions when you want distinct permissions or audit trails. Remember that multiple servers do not remove Copilot Studio's overall per-agent orchestration budget.

General guidance for all harnesses

Even in harnesses without a hard cap, huge tool lists have costs: every tool description consumes the AI's context window, and models choose tools less reliably from very large menus. Good practice:

• Scope clients to a purpose. A "service desk" client with ticket tools will outperform an everything-enabled client for service-desk work.
• Start from the narrowest useful view. Filter to the relevant connectors, access type, or plan, use Select all shown, then trim individual tools.
• Prefer several narrow clients over one broad one when your team uses AI for distinct workflows. Clients are free to create, and each shows up separately in usage reporting, which also improves your audit trail.
• Give a single-connector client a single-connector URL. Where MCP Setup lists per-connector endpoints, pointing a purpose-built client at one of them keeps its tool list small without you maintaining a hand-picked selection as the catalog grows. Pair it with a restricted MCP client when the small list also needs to be a boundary.

Large catalogs & compact mode

Trimming a client's tool selection (above) controls what a harness may do. Catalog mode controls how many tools StackJack shows it in the first place — the answer to harnesses that cap or truncate large tool lists. It has a full page of its own: Catalog modes: compact and minimal tool serving.

In short: instead of handing a harness your whole catalog, StackJack can serve a small compact surface or a still smaller minimal surface plus your pinned tools, and the AI discovers permitted, configured connector tools on demand via stackjack_search_tools. Every runtime permission check still fires — mode is presentation, never authorization. In Minimal mode, grant-gated Automation run/configuration/authoring tools deliberately require switching to Compact or Full instead of routing through the folded platform tool.

Choose an organization state deliberately — it governs the standard endpoint. On the Settings page, saving Enable catalog modes for this organization as on makes mode settings, pins and ?tools= eligible there; saving it as off forces the full catalog there. Before your organization has saved either choice, StackJack can auto-reduce a known capped harness only when no URL, host, or stored mode wins first and the estimated permitted, configured catalog exceeds that harness's operational threshold. Those explicit settings remain inactive until you enable the organization, but a winning one also prevents auto-detection from supplying the untouched-tenant default. The compact address is outside all of this: it serves the compact catalog on every connection, in every organization state, with nothing to enable — and nothing you append to that URL changes it, ?tools= included, which is why the parameter belongs on your standard endpoint address. See the full rules before diagnosing a mode as unexpected.

See Client tool limits for the maintained per-client budget table — which clients truncate, at what count, and which ones StackJack reduces on its own (four by the way the tool identifies itself, plus Microsoft 365 Copilot connections by how they sign in). The rest of Catalog modes covers the three modes and pins, the compact.stackjack.io host alias, the full precedence order, and the claude.ai re-add caveat.