Skip to main content
Glama

Prepare a file upload

prepare_file_upload

Get an upload destination for a file your shell transfers directly.

Use this to keep a file out of the context window. Call the tool, run
upload_command against the local file, then pass the returned reference
to the consuming tool.

Attach the file by passing s3_url to create_project or update_project as
documents[].s3_url. For external_findings on a project with several
repositories, add documents[].repo_slug. Every later scan reads attached
findings.

Uploading again under the same file_name stores a new version. Attaching
it replaces the attached version, and the reply says so.

Use document_name for security_advisor content_document and get_artifact
design_doc.

The file is stored under document_type, and the attaching tools read the
type from s3_url. Do not upload source code as a document. Connect its
repository through create_project's github_repo.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file_name": "<file_name>",
      "document_type": "<document_type>",
      "document_format": "<document_format>"
    },
    "name": "prepare_file_upload"
  }
}

Input Schema

NameRequiredDescriptionDefault
digestNoOptional content digest as 'sha256:<64 hex chars>' (compute with sha256sum). When it matches an already-stored version the upload is skipped and the existing location returned.
file_nameYesStored document name. Allowed characters are letters, digits, hyphens, underscores, and periods.
document_typeYes'design_doc' for design docs, specs, or plans; 'external_findings' for SARIF, Semgrep, or Snyk output from the customer's scanners. Do not upload source code as a document; connect its repository with github_repo.
document_formatYesFile format. design_doc: md or pdf; external_findings: sarif, semgrep_json, or snyk_json.

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.
reasonNoA stable snake_case code from the allowed set. Present on every error and on successful calls that carry a workflow state.
s3_urlNoStable document location. Pass this as the document reference to create_project or update_project documents[].s3_url.
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.
expires_atNoISO timestamp when the upload_url stops working.
next_stepsNoRecommended next actions, in order.
upload_urlNoPresigned PUT URL for the file bytes. None when skipped_upload is true because Trent already stores identical content.
content_typeNoContent-Type header to send with the PUT.
document_nameNoStored document name, for security_advisor content_document and get_artifact design_doc.
max_size_bytesNoServer-enforced maximum file size for this document type.
skipped_uploadNoTrue when the digest matched a stored version. The file is already available at s3_url, so use that reference directly.
upload_commandNoReady-to-run shell command template for the transfer; replace <local-file-path> with the file to upload.
document_versionNoVersion number assigned to this upload.
retry_after_secondsNoWith reason rate_limited, how many seconds Trent asks the caller to wait.
max_scan_total_bytesNoFor external_findings, the most findings-file bytes one scan reads across all the project's attached files. Files past it are skipped for that scan. Null for other document types.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / max_scan_total_bytes
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "For external_findings, the most findings-file bytes one scan reads across all the project's attached files. Files past it are skipped for that scan. Null for other document types.",
      +  "title": "Max Scan Total Bytes"
      +}
    • 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 (readOnly=false, idempotent=false, destructive=false), the description discloses version semantics: re-uploading under the same file_name stores a new version, attaching replaces the attached version, and the reply reports that. It also explains downstream effects ('every later scan reads attached findings') and that the storage type is taken from s3_url by the consuming tools.

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 core purpose and call sequence are front-loaded, and each paragraph carries actionable routing information. It is slightly longer than needed: the 'do not upload source code' instruction duplicates the document_type enum description in the schema, and the paragraph about document_type/s3_url overlap is somewhat repetitive.

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?

With an output schema present and 100% schema coverage, the description only needs to supply workflow and cross-tool context — which it does completely: when to use, how to run the upload, where the reference is consumed, versioning behavior, and the source-code exclusion. Nothing an agent needs to invoke it correctly is missing.

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; the description rises above it by explaining how outputs and parameters route across tools — s3_url into documents[].s3_url, document_name for security_advisor content_document and get_artifact design_doc, and repo_slug for external_findings. It does not restate digest or file_name character rules, which the schema already covers.

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 opening sentence names a specific verb and resource ('Get an upload destination for a file') and scopes it to files transferred by the shell rather than through the context window. An agent can immediately tell this is a pre-upload handshake step, distinct from the attaching tools like create_project or update_project.

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?

It gives the exact call sequence (call tool, run upload_command on the local file, pass the returned reference onward) and names where that reference goes (documents[].s3_url on create_project/update_project, plus repo_slug for external_findings). It also states an explicit exclusion: do not upload source code, connect the repository via create_project's github_repo instead.

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.