Trent

Update a project

update_project

Destructive

Change an existing project: configure automatic scanning, switch project tickets on or off, file tickets for existing tasks, or add, remove, and restore sources. To make a new project, use create_project. Setting scan_interval disables push scanning, and enabling push scanning disables the interval.

User-requested changes take effect in this call. Ask first when you
propose a change.

remove_documents removes by name. The reply gives each document's undo
step. Restore uploads with restore_documents. For a connector copy such
as a Notion page or Linear issue, attach it again with the returned exact
sources value. A document removed together with its repository stays
removed; upload it again. A document tied to a repository the project no
longer has comes back after that repository is restored in the app,
then with restore_documents. Detach connected sources in the app at the
page the reply links. Removal and restoration leave scan initiation to
the caller.

file_backlog files tickets for every eligible existing task. This can
create many tickets. Tell the user the count before asking for that action.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_project"
  }
}

Input Schema

Name	Required	Description
`sources`	No	Connected sources to attach, exactly as find_related_sources returned them. Pass the ones the user chose; they attach in this call, and the reply names each one and the app page where it is detached.
`documents`	No	Documents to attach, each {s3_url, repo_slug?}: design docs, architecture specs and feature plans, or SARIF, Semgrep and Snyk findings from the customer's scanners. Call prepare_file_upload with the document_type, run upload_command, then pass s3_url; the type comes from the upload. Every later scan reads attached findings. Do not bundle source code into documents; connect it through github_repo. An upload under an existing document name replaces that document. A project holds up to 50 design documents, counting connected sources that will become one; external findings are outside that count.
`ticketing`	No	Whether Trent files tickets for this project's tasks. False stops new tickets while open tickets keep syncing. True turns filing back on. Workspace Tickets settings stay unchanged.
`project_id`	No	Project ID (provide either project_id or project_name)
`github_repo`	No	GitHub repository to add: 'owner/repo', 'https://github.com/owner/repo', or a GitHub URL ending in .git. New entries use the branch in 'owner/repo@branch', or the default branch when omitted. Existing entries keep their fixed branch. A request to change that branch is refused; use create_project for the other branch.
`website_url`	No	Website to add to the project. Existing entries stay as they are. Trent stores website logins through the app. If the user supplies a login, explain that route and that scanning with public access covers public pages. Do not put credentials in the URL, discard them silently, or invent a login parameter; this tool cannot accept them.
`file_backlog`	No	True files a ticket now, in priority order, for each existing task that qualifies and has none. Needs the project's tickets on; ticketing=True in the same call turns them on first.
`project_name`	No	Project name (provide either project_id or project_name)
`source_scopes`	No	Scopes to attach whole, exactly as find_related_sources returned them under 'scopes' (a Linear team or project, a Notion database or page and its subpages). A project holds up to 50 design documents, counting connected sources that will become one; external findings are outside that count. A request that would exceed it is refused before anything is written.
`remove_documents`	No	Document names to remove, as listed on the project. The reply gives the step to undo each removal. Removal leaves scan initiation to the caller.
`restore_documents`	No	Removed upload names to restore, from a removal reply. For a connector copy, attach it again through sources. Restoration leaves scan initiation to the caller.
`enable_push_scanning`	No	Enable scanning on every git push. Requires the Trent GitHub App to be installed.
`scan_interval_seconds`	No	Automatic scan interval in seconds. Allowed range: 300 (5 minutes) to 31536000 (365 days). Common values: 86400 (daily), 604800 (weekly). Set to 0 to disable scheduled scanning.
`scan_on_source_update`	No	Scan after a material source change, such as a synced document or findings scope producing a new version. Works independently of schedule and push settings. False turns it off.

Output Schema

Name	Required	Description
`error`	No	True when the call itself failed. False for successful calls, including a scan still running, an already approved plan, or a repository classified as non-agentic. The reason field describes these workflow states.
`reason`	No	A stable snake_case code from the allowed set. Present on every error and on successful calls that carry a workflow state.
`backlog`	No	After file_backlog: {queued, eligible_unfiled, destination} as Trent reported them. queued is how many tickets Trent is filing, and destination where they go.
`message`	No	Exactly one sentence written for the user. Never raw exception text or a backend error string, which may expose private details.
`metadata`	No	Caller metadata, such as 'expiration_warning'. Substantive results have their own fields. Never includes exception or backend error text, which may expose private details.
`outcomes`	No	When the call did more than one thing: what each part did, in order. message gives the first.
`next_steps`	No	Recommended next actions, in order.
`project_id`	No	Resolved Trent project identifier.
`scopes_refused`	No	Scopes whose attachment the server refused, each with its reason.
`pending_sources`	No	Sources still staged on the project; it refuses to scan while any remain.
`scopes_attached`	No	Scopes attached in this call, each with its scope_id and how many sources it added.
`sources_refused`	No	Connected sources whose attachment the server refused, each with its reason.
`sources_attached`	No	Connected sources attached in this call.
`documents_removed`	No	Documents this call removed, each with where it came from and its undo.
`documents_restored`	No	Documents this call put back on the project.
`push_scans_blocked`	No	After enabling push scanning: each repository where a push can't start a scan, or Trent couldn't check, with the reason and the GitHub page that unblocks it.
`retry_after_seconds`	No	With reason rate_limited, how many seconds Trent asks the caller to wait.
`documents_not_restored`	No	Documents whose restoration failed, each with the reason and the next step.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 30, 2026

addedOutput schema / properties / outcomes

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "When the call did more than one thing: what each part did, in order. message gives the first.",
+  "title": "Outcomes"
+}

addedOutput schema / properties / retry_after_seconds

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "With reason rate_limited, how many seconds Trent asks the caller to wait.",
+  "title": "Retry After Seconds"
+}

First observedOct 23, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructiveHint=true, idempotentHint=false, openWorldHint=true; the description adds real value beyond them by disclosing the scan_interval/push-scanning mutual exclusion, that removal returns per-document undo steps and that repository-coupled removals are permanent, and that file_backlog can create many tickets. Some of the removal/restore sentences are garbled enough ('comes back after that repository is restored in the app, then with restore_documents') to blur the actual consequence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose sentence is front-loaded and efficient, but the removal/restoration paragraph is a dense run of conditional cases with awkward line breaks and hard-to-parse clauses. Several sentences could be tightened or restructured without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 14 optional params, no required fields, a 100%-covered schema, and an output schema carrying the return format, the description covers the risky behaviors an agent must know (destructive removal semantics, ticket volume, scan config conflicts). The main residual gap is not explaining required-parameter logic for project identification.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description goes beyond per-field docs by explaining cross-parameter behavior: scan_interval disabling push scanning and vice versa, and file_backlog requiring ticketing=True in the same call. It does not clarify project_id vs project_name resolution or which params combine destructively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Change an existing project') and enumerates the concrete capability groups: scanning config, ticketing toggle, backlog filing, and source add/remove/restore. It explicitly names the sibling it is not ('To make a new project, use create_project'), so an agent can route between the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names create_project as the alternative for new projects and gives a clear confirmation rule ('Ask first when you propose a change'), plus a volume warning before file_backlog. It does not cover when to prefer this over sibling read/analysis tools, but for a mutation tool the key alternative (create vs update) is stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Trent tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.