Skip to main content
Glama

Create a project

create_project

Create a Trent project for security scanning. Its first scan starts automatically unless trigger_analysis is false, or a source is still syncing in (sources or source_scopes); then start it with trigger_analysis, which syncs any source that has not landed.

Supply at least one source: github_repo, website_url, or documents. For
documents, call prepare_file_upload, run upload_command, and pass s3_url.
Do not bundle source code into documents; connect its repository through
github_repo and the Trent GitHub App. For a quick plan review before
creating a project, use security_advisor.

The scan runs in the background and takes up to 1 hour. Read job_id, then
poll get_scan_status, with a first look around 10 minutes in. Relay any
returned 'Trent dashboard: <url>' line verbatim.

A matching repository or website returns reason='confirmation_needed'
with existing_project_details. Show the match and ask the user, then call
again with dedup_policy='reuse' or 'force_new'. A first call with
'force_new' requires the user's existing request for a new project.

If GitHub access prevents the scan starting, reason is
'github_app_install_required'. Send the user to the returned Trent GitHub
App install URL, then retry with trigger_analysis.

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": "create_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoProject name. Trent generates one when omitted.
sourcesNoConnected 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.
documentsNoDocuments 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 the returned s3_url. Trent uses the uploaded name and type. Do not bundle source code into documents; connect it through github_repo. A project holds up to 50 design documents, counting connected sources that will become one; external findings are outside that count. For a quick interactive plan review, use security_advisor.
ticketingNoWhether Trent files tickets for this new project's tasks when the Trent workspace files tickets. Default true; update_project(ticketing=...) changes it later. Ignored when this call reuses an existing project.
complianceNoCompliance frameworks to analyze. Defaults to ['THREAT_MODEL'].
github_repoNoGitHub repository to scan: 'owner/repo', 'https://github.com/owner/repo', or a GitHub URL ending in .git. Add '@branch', such as 'acme/app@release', to select a branch. Omit it for the default branch. The branch stays fixed after creation; create a second project for another branch. Pass GitHub URLs here. github_repo and website_url can be supplied together. For several repositories, use github_repos.
website_urlNoLive website to crawl and scan, such as 'https://myapp.com'. Pass GitHub URLs in github_repo. Both inputs can be supplied together. Trent stores website logins through the app. If the user supplies a login, explain that route and wait for their request before creating a project with public-page access. Do not put credentials in the URL, discard them silently, or invent a login parameter; this tool cannot accept them.
dedup_policyNoProject deduplication policy. 'auto' (default): check for existing match and ask. 'force_new': always create a new project. 'reuse': reuse an existing matching project.auto
github_reposNoGitHub repositories for a project with several repositories, such as a frontend and backend or microservices. Trent models data flows across them. Each accepts the github_repo formats: 'owner/repo', 'owner/repo@branch', URL, or URL.git. Choose github_repos or github_repo. A project holds up to 10 repositories.
source_scopesNoWhole scopes to attach, as find_related_sources returned under scopes: a Linear team or project, or 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 exceeding that limit is refused before project creation. Scope sources sync in the background; scanning waits for them to attach.
trigger_analysisNoWhether to trigger the initial security analysis after creation. Default is True. Requires GitHub App to be installed for code access.

Output Schema

NameRequiredDescriptionDefault
errorNoTrue 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.
job_idNoTriggered analysis job identifier.
reasonNoA stable snake_case code from the allowed set. Present on every error and on successful calls that carry a workflow state.
messageNoExactly one sentence written for the user. Never raw exception text or a backend error string, which may expose private details.
metadataNoCaller metadata, such as 'expiration_warning'. Substantive results have their own fields. Never includes exception or backend error text, which may expose private details.
complianceNoCompliance frameworks configured for the project.
next_stepsNoSuggested follow-up actions for the caller.
project_idNoCreated or reused Trent project identifier.
repositoryNoThe first GitHub repository attached to the project; repositories lists them all.
website_urlNoWebsite URL attached to the project.
project_nameNoCreated or reused Trent project name.
repositoriesNoEvery GitHub repository attached to the project, each with the branch it scans.
scopes_refusedNoScopes whose attachment the server refused, each with its reason.
pending_sourcesNoSources still staged on the project. The app labels them 'not finished connecting'. The server refuses scans while any remain.
scopes_attachedNoScopes attached in this call, each with its scope_id and how many sources it added.
sources_refusedNoConnected sources whose attachment the server refused, each with its reason.
sources_attachedNoConnected sources attached in this call.
matching_projectsNoEvery existing project holding the requested sources, each with its repositories and the branch each one scans, when confirmation is required.
analysis_triggeredNoWhether an analysis was started automatically.
documents_uploadedNoDocuments attached to the project, each with the name it was uploaded under, its s3_url, and for a findings file the repo_slug it applies to.
is_existing_projectNoWhether an existing project was reused.
retry_after_secondsNoWith reason rate_limited, how many seconds Trent asks the caller to wait.
existing_project_detailsNoThe project dedup_policy='reuse' would reuse, when confirmation is required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, it discloses that scanning runs in the background for up to 1 hour, that the caller should read job_id and poll get_scan_status around 10 minutes in, and that returned dashboard URLs should be relayed verbatim. It also describes the confirmation_needed and github_app_install_required response paths, which are substantive behavioral details.

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

Conciseness4/5

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

The description is long but mostly justified by the complexity of project creation, source configuration, deduplication, and scan polling. It is front-loaded with purpose and workflow, though some details, such as the security_advisor recommendation and the 50-document limit, are repeated in the schema descriptions.

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

Completeness5/5

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

Given the 11 parameters, high schema coverage, annotations, and an output schema, the description covers the critical operational context: source requirements, document upload flow, deduplication handling, background scan expectations, and GitHub App remediation. An agent has enough information to call this tool correctly in the main scenarios.

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 most parameter meaning is already documented in the schema. The description still adds cross-parameter guidance, especially the requirement for at least one source and the automatic initial scan behavior when trigger_analysis is true, but many individual parameters such as ticketing, compliance, and github_repos are left to the schema.

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?

The first sentence states a specific verb and resource: 'Create a Trent project for security scanning.' It also names sibling tools for adjacent actions, such as security_advisor for plan review and get_scan_status for polling, so the agent can distinguish this tool from alternatives.

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

Usage Guidelines5/5

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

The description gives explicit creation preconditions ('Supply at least one source'), routes plan-review requests to security_advisor, and explains how to handle deduplication confirmations and GitHub App installation failures. It states when to retry with trigger_analysis and how to proceed when a matching project exists.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.