Procore MCP Server

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

No annotations are provided, so the description carries full burden. 'Create' implies a write/mutation operation, but the description doesn't disclose behavioral traits like required permissions, whether this overwrites existing files, what happens on failure, or what the response contains. The API endpoint hint suggests it's a POST operation, but no further behavioral context is given.

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

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

The description is brief (two phrases) but inefficiently structured. 'Create company File' is redundant with the name, and the API endpoint information, while potentially useful, is presented without clear separation from the purpose statement. It's concise but not optimally front-loaded or structured for clarity.

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

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

For a creation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what a 'company File' represents, what format the 'file' parameter expects, what happens after creation, or any error conditions. The API endpoint provides some context but doesn't compensate for the lack of behavioral and output information.

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

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

Schema description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, but with complete schema coverage and only 2 parameters, this is acceptable. The baseline for high schema coverage is 3, and the description doesn't detract from the schema's clarity.

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

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

The description 'Create company File' restates the tool name with minimal elaboration. It adds '[Core/Documents] POST /rest/v1.0/companies/{company_id}/files' which provides API context but doesn't clearly explain what 'company File' means or what resource is being created. It distinguishes from siblings only by the 'company' scope, but many sibling tools also create company-related resources.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, constraints, or when this specific file creation method should be chosen over other file-related tools in the sibling list (like create_company_file_version, create_project_file, etc.).

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