Skip to main content
Glama
TylerIlunga

Procore MCP Server

create_project_file

Upload and create new files in Procore projects to store documents, track changes, and manage project documentation with custom permissions.

Instructions

Create project File. [Core/Documents] POST /rest/v1.0/files

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesUnique identifier for the project.
parent_idNoThe ID of the parent folder to create the file in. If not set the file will be created under the root folder.
nameNoThe Name of the file
is_trackedNoStatus if a file should be tracked (true/false)
explicit_permissionsNoSet file to private (true/false)
descriptionNoA description of the file
dataNo[DEPRECATED] File to use as file data. Please use upload_uuid instead. Note that it's only possible to post a file using a multipart/form-data body (see RFC 2388). Most HTTP libraries will do the r...
unique_nameNoToggles automatic renaming if the file name is already taken in a folder (unique_name = true). Returns a name taken error if a file name is taken in a folder (unique_name = false).
upload_uuidNoUUID referencing a previously completed Upload. This is the recommended approach for file uploads. See Company Uploads or Project Uploads endpoints for instructions on how to use uploads. You sho...
custom_field_%{custom_field_definition_id}NoValue of the custom field. The data type of the value passed in corresponds with the data_type of the Custom Field Definition. For a lov_entry data_type the value passed in should be the ID of one ...
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create project File' which implies a write/mutation operation, but does not disclose any behavioral traits such as required permissions, whether the operation is idempotent, what happens on conflicts (e.g., with 'unique_name'), or the response format. The mention of 'POST /rest/v1.0/files' hints at an HTTP method but adds little practical context for an AI agent.

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 extremely concise with just one sentence and an API endpoint reference. It is front-loaded with the core action ('Create project File'), but the brevity borders on under-specification rather than efficient communication. However, it avoids redundancy and wastes no words, earning a high score for conciseness despite lacking substance.

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

Completeness2/5

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

Given the complexity (10 parameters, no annotations, no output schema), the description is incomplete. It does not explain the tool's behavior, usage context, or what to expect upon success/failure. For a mutation tool with many parameters and no structured safety hints, the description should provide more guidance to compensate, which it fails to do.

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

Parameters3/5

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

Schema description coverage is 100%, meaning all 10 parameters are documented in the input schema with descriptions. The description adds no parameter-specific information beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline score is 3 even with no param info in the description, which applies here.

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

Purpose2/5

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

The description 'Create project File. [Core/Documents] POST /rest/v1.0/files' is a tautology that restates the tool name 'create_project_file' with minimal elaboration. It adds 'project' and mentions the API endpoint, but lacks specificity about what kind of file is created (e.g., document, spreadsheet, etc.) or its purpose. It does not distinguish this tool from other file-related siblings like 'create_company_file' or 'create_project_file_version'.

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

Usage Guidelines1/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a project_id), context for file creation, or any sibling tools for comparison. Given the extensive list of sibling tools, including many file-related ones, this absence of usage guidance is a significant gap.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TylerIlunga/procore-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server