Tools

Agents act only through tools, and every tool call goes through the MCP gateway. Polarion tools act as the agent’s own bot user, so Polarion also enforces its project permissions.

How tools are granted

Source	Tools
Every agent	The read tools, add_hyperlink and propose_memory
Skills	Each approved skill lists tools in its tools field; the agent gets the union of its skills’ tools
Bundled with create_work_item	Whoever may create items may also correct and arrange them: update_field, update_fields, link_work_items, set_test_steps, move_to_document, create_document, extend_document, edit_document_text, remove_document_part, comment_document, record_test_run, request_review, workflow_action, attach_file
Bundled with delegate	Whoever delegates also reviews and answers: review_subtask, answer_teammate
Connections	Tools of granted MCP servers, under their policy (read, approve, block)
Sandbox	Shell, files and git in the task’s workspace (sandbox harnesses only)

The Agent brain view lists the exact Polarion tools and connected systems of an agent in a project. Markers below: H = held for the supervisor’s approval on items written by people, R = refused on items written by people.

Read

Tool	What it does
read_work_item	Reads up to 10 items: type, status, text, fields, test steps, screens, links in and out, reviews, recent comments
query_work_items	Searches the project with a Polarion Lucene query
list_documents	Lists the project’s LiveDocs
read_document	Reads a LiveDoc in order: headings, items and text paragraphs with their part ids
describe_type	Lists the settable fields of a work item type and the allowed values of selection fields, read live from the project’s configuration

Create and change work items

Tool	What it does
create_work_item	Creates an item (requirement, test case, risk, task, issue, user story, design), optionally in a document, with fields and test steps. Marked AI generated and linked ai_produced_by the task
update_field H	Changes the title or description
update_fields H	Sets several fields at once, custom fields included, validated against the type
link_work_items	Links two items with a trace role (refines, verifies, relates_to, depends_on, mitigates, parent, implements) and checks that Polarion kept the link
add_hyperlink	Links an item to an object in a connected system by URL (tracked in, implemented in, verified by, other)
add_image H	Adds an image returned by a connected system to an item’s screens
set_images H	Replaces an item’s screens with these images
workflow_action R	Lists or runs a workflow action on the agent’s own AI items; never into approved, done, closed, rejected or similar states, never signature-bound actions
request_review	Asks people to review an item through Polarion’s own approval (people only, the supervisor by default)

Documents

Tool	What it does
create_document	Creates a new LiveDoc as a draft in an existing space: introduction, headings, text and AI-marked items
extend_document	Appends chapters with text and items to an existing document
move_to_document	Moves existing items into a document chapter (keeps ids, links and history)
edit_document_text	Replaces one text paragraph, list or table of a document
remove_document_part	Removes a stray paragraph or an empty heading, only in documents the agent created
comment_document	Comments on a document as a whole

Tests

Tool	What it does
set_test_steps R	Replaces the steps in a test case’s Test Steps table
record_test_run	Records a Polarion test run (AI-<agent>-<time>) with one record per test case: passed, failed or blocked, with evidence

Collaboration

Tool	What it does
comment	Comments on a work item, signed with the agent’s name and role
ask_human	Asks the supervisor focused questions with answer options; the task goes to waiting_input. On a delegated task the delegating agent answers first
submit_for_approval	Submits the result with a headline and summary, plus open decisions as questions; the task goes to awaiting_approval. Refused while sub-tasks or held changes are open
delegate	Creates a sub-task for a teammate, optionally after another sub-task
review_subtask	Approves a teammate’s sub-task or sends it back with feedback
answer_teammate	Answers a teammate’s question on a delegated sub-task
propose_task	Sidebar chat only: proposes a task the person creates with one click

See Agent runs for the delegation limits.

Memory

Tool	What it does
propose_memory	Proposes a project memory (a short rule) from the supervisor’s feedback, for this agent or the current team. A person approves it before it is used. See Memory

Connected systems (MCP)

Tools of granted MCP servers appear as <connection>__<tool>, e.g. a GitLab connection’s issue tools. What they can do depends on the server. The gateway applies the connection’s policy, the engagement’s scope and any standing approvals:

Policy	Behavior
read	Runs and is recorded
approve	Held for the supervisor, with the agent’s reason; runs exactly as stored when approved
block	Refused and recorded as blocked

Sandbox and workspace

Agents with the claude_code or codex harness work in their task’s sandbox with the harness’s own tools: shell, file editing and git. Git to granted repositories goes through the gateway’s git proxy (clone, fetch, push to agent branches). Reading web pages works only for websites allowed on the engagement.

Tool	What it does
attach_file	Attaches a workspace file (text or image, up to 5 MB) to a work item or document as evidence
checkout_repository	Downloads a scoped GitHub repository into the workspace with a local git baseline. Only offered when the connection has no git remote configured
push_workspace	Sends the changed files as one commit to a branch (never main) through the connection’s push_files tool, under its policy. Same condition as above

Always allowed vs. granted vs. held

	Tools
Always allowed	read_work_item, query_work_items, list_documents, read_document, describe_type, add_hyperlink, propose_memory
Granted by skills	Everything else, directly or through the bundles above
Held on items written by people	update_field, update_fields, add_image, set_images
Refused on items written by people	set_test_steps, workflow_action
Held by connection policy	MCP tools with policy approve (unless a standing approval exists)
Never allowed for agents	MCP tools with policy block; moving items into approval or closure states; signature-bound workflow actions; git pushes outside the connection’s branch patterns

Note

In the sidebar chat, an agent gets only the read tools, the read tools of its connections and propose_task. Nothing is written until a person creates the proposed task. See Agent chat.