Agent tool access (MCP)

Organ uses Model Context Protocol (MCP) to give agents structured access to approved product actions. The important customer concept is the effective toolset: an agent sees only the tools that match its venture, role, task, connected resources, and configured guardrails.

MCP access does not give an agent unrestricted access to your venture or connected systems.

EFFECTIVE MCP TOOLSET

Context narrows a large platform into safe actions

1. 01

   Identify

   Resolve venture, agent role, and current task.

2. 02

   Constrain

   Apply capabilities, guardrails, and resource approval.

3. 03

   Discover

   Expose the effective toolset and support search.

4. 04

   Act

   Validate input and record the product action.

How the effective toolset is selected

Tool availability is evaluated for each agent context. Organ considers:

• the active organization and venture;
• the agent's role and department;
• the workflow or chat that requested the action;
• enabled capabilities and explicit tool guardrails;
• whether the action is supported for that workflow;
• the resources approved when the work was launched.

This is why two agents in the same venture can legitimately see different tools. A department head may be able to schedule or dispatch work while a specialist can use only the tools required for its assigned task.

Tool categories

The exact list varies by context, but customer-visible agent actions generally fall into these groups:

Category	What agents can do when authorized
Venture knowledge	Record useful observations for later Brain synthesis.
Resources	Discover approved resource context and request scoped access.
Workflow dispatch	Start supported Developer, Research, Content, Discovery, or Health work.
Workflow control	Inspect results and use eligible retry or cancellation actions.
Schedules	Create or manage recurring work within the agent's authority.
Strategy and goals	Read strategy; authorized leadership agents can manage goals and strategy.
Escalations	Raise, review, or retire blockers according to role.
Publishing and media	Approve eligible content, record delivery, or create supported media assets.

A category in this guide does not mean every action is available to every agent. The workflow form and agent configuration are the reliable view of the current context.

Search the support center from an agent

Authenticated agents can use search_support to retrieve this public knowledge base. The tool accepts a concise query and an optional result limit, then returns matching article titles, descriptions, relevant excerpts, and public URLs.

Good queries use two to five product terms:

• model selection cache
• resource access failed
• escalation workflow resume
• compute token difference

The search corpus is exactly the public support collection used by the browser search dialog. It does not include private product-management inventories, staff procedures, credentials, venture records, or conversation history.

An agent should cite the returned article URL when giving operational guidance. If no article matches, it should simplify the query before opening a support ticket.

Permissions and guardrails

Agent capabilities define what the agent is intended to do. Guardrails can narrow that intent by explicitly allowing or denying tools. Organ then applies venture isolation, department authority, workflow support, and resource pre-authorization before an action is exposed.

Use these principles:

• grant the smallest toolset that completes the job;
• separate leadership/dispatch authority from specialist execution;
• approve only the resources the workflow needs;
• review tool changes alongside agent role changes;
• test consequential changes with a bounded workflow before broad rollout.

Resource access

An agent can request credentials only for resources approved for its current workflow or chat context. The Security Officer flow provisions access without placing the source secret in the model conversation.

See Resources and Security Officer for the customer workflow, security boundary, and troubleshooting steps.

Diagnose a missing tool

If an agent says an action is unavailable:

1. Confirm the task is running in the correct organization and venture.
2. Confirm the agent role and department match the requested action.
3. Review the agent's capabilities and tool allow/deny guardrails.
4. Confirm the selected workflow supports the action.
5. For connected systems, confirm the resource was included when work was launched and its credential is healthy.
6. Start a fresh bounded run after changing permissions; an active run can retain the context with which it started.

If the tool is visible but fails, capture the workflow or chat ID, agent, action, timestamp, and safe error message. Never paste credentials or session tokens into chat, logs, escalations, or support requests.

What to expect

• Tool availability is contextual, so a copied prompt does not grant the same permissions in another workflow.
• Support search is read-only and searches public documentation, not venture data.
• Changing an agent's configuration affects new contexts; verify an active run before assuming it received the change.
• Connected providers can still reject an authorized action because of their own permissions, rate limits, or service state.
• Some work requires a human approval or escalation even when the agent has the technical tool to prepare it.