Skip to main content
Glama

ACC MCP

by io.scanbimlabs

acc_upload_file

Upload a file from a public source URL into an ACC project folder. Runs the full four-step APS Data Management flow: top-folder discovery → storage object creation → OSS PUT of bytes → first-version item creation.

When to use: The user wants to push a document/photo/model into ACC Docs — e.g. 'upload this site photo to the Tower project Photos folder' or an automation needs to archive an exported report into Project Files.

When NOT to use: Do not use for files already in ACC; do not use for files behind auth-gated URLs (fetch step is an unauthenticated GET). For very large files (>100MB), prefer the chunked/signed-S3 upload flow, not this single-PUT implementation.

APS scopes: data:read data:write data:create account:read.

Rate limits: APS Data Management ~50 req/min per endpoint; OSS upload bandwidth typically 100 MB/min per app. This tool issues 3–5 APS calls per upload, so budget accordingly.

Errors: 401 (APS token expired — refresh); 403 (user lacks folder write permission — ask account admin to grant 'Edit' on folder); 404 (project_id not found or folder_path does not match any top folder — verify 'b.' prefix, hub membership, and folder name); 422 (invalid file_name or conflicting version); 429 (rate limit — back off 60s); 5xx (ACC/OSS upstream — retry with jitter BUT be cautious: storage object may already be created so reuse, do not re-create). Also: if source file_url returns non-2xx, the tool throws before touching ACC.

Side effects: Creates a storage object, uploads bytes, and creates a versioned item in the target folder. NOT idempotent — a retry may create a duplicate item with a new version. Surface the returned item_id to the user to avoid re-uploads.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_urlYesPublicly fetchable HTTPS URL of the source file. Must return 2xx to an unauthenticated GET. Max practical size ~100MB for this single-PUT implementation.
file_nameYesDestination filename in ACC, including extension. 1–255 chars. Avoid path separators.
project_idYesACC project ID. MUST use 'b.' prefix literal. Obtain via acc_list_projects.
folder_pathNoCase-insensitive substring of the target top-level folder's display name. Defaults to 'Project Files'. Common values: 'Project Files', 'Plans', 'Photos', 'Submittals'.

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses side effects: creates a storage object, uploads bytes, creates a versioned item, and is NOT idempotent—retries may duplicate items. It also lists all relevant error statuses, authentication scopes, rate limits, and the unauthenticated GET behavior, leaving little hidden.

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

Conciseness5/5

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

The description is long but every sentence earns its place: flow overview, usage guidance, exclusions, scopes, rate limits, errors, and side effects are organized under clear headers. There is no redundant filler; the length is justified by the tool's complexity.

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 tool's complexity (4 parameters, no output schema, no annotations), the description covers all necessary context: prerequisites, error handling, retry caveats, and expected return value (item_id). It leaves no significant operational gap, making it fully contextual.

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?

The schema already provides 100% parameter coverage with descriptions and examples. The description adds value by reiterating key constraints in context (e.g., the 100MB practical limit for file_url, the 'b.' prefix requirement for project_id) and clarifies folder_path matching in the error guidance. This goes slightly beyond the schema's baseline.

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 description opens with a specific verb+resource: 'Upload a file from a public source URL into an ACC project folder.' It then details the four-step APS flow, clearly distinguishing this tool from siblings like acc_search_documents or acc_create_issue. The purpose is unambiguous and actionable.

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 provides explicit 'When to use' and 'When NOT to use' sections, including concrete examples, exclusions (auth-gated URLs, existing files), and an alternative flow for large files. It also covers rate limits and error responses, giving the agent clear operational guidance.

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

All ACC MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct entity (issue, RFI, project, document, file) and action (create, list, update, search, upload, summary). The 'When to use' and 'When NOT to use' notes in descriptions further prevent confusion.

Naming Consistency5/5

All tools follow a consistent acc_verb_noun pattern (e.g., acc_create_issue, acc_list_projects, acc_upload_file). Verbs are always lowercase, nouns are singular, and there are no mixed conventions.

Tool Count5/5

9 tools is well-scoped for an ACC MCP server. It covers core project management operations (issues, RFIs, projects, documents, file upload) without being too sparse or bloated.

Completeness4/5

The set covers create, read (list), and update for issues, plus create and list for RFIs. Missing update for RFIs and a dedicated get-by-ID for individual issues or RFIs are minor gaps, but the core workflows are supported.

Resources