Procore MCP Server

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 fails to indicate that this is a mutation operation (adding a vendor), what permissions are required, whether it is idempotent, or what the response contains. The description is insufficient for a tool that modifies data.

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 under-specified, not concise. It consists of a tautological phrase and a URL fragment that is not explanatory. While brief, it fails to convey necessary information, making it inefficient rather than succinct. Every sentence should earn its place, but here the content is inadequate.

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?

Given the complexity of adding a vendor to a project, the lack of annotations, and no output schema, the description is severely incomplete. It does not explain the action, prerequisites, outcomes, or error conditions. For a mutation tool with no structured support, this description is wholly inadequate.

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 clear descriptions for project_id and id, and an enum for view. The description adds no additional parameter semantics beyond what the schema provides, but the schema is well-documented. The baseline score of 3 is appropriate as the schema does the heavy lifting.

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 'Add to project' is a tautology that restates the tool name without specifying what is being added or to what resource. It lacks a clear verb and object, making the purpose vague. The URL fragment suggests adding a vendor to a project, but this is not explicitly stated in the description itself.

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?

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'add_company_user_to_project' or 'add_category_to_project', there is no indication of how this tool differs or when it is appropriate. The agent must infer usage from the URL alone.

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