Procore MCP Server

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

No annotations are provided, so the description must fully disclose behavioral traits. It states 'Create' (implying a write/mutation operation) and includes an HTTP method (POST), which hints at creation. However, it lacks critical details: required permissions, whether the operation is idempotent, rate limits, error conditions, or what happens on success (e.g., returns a new change order ID). The description does not contradict annotations (none exist), but it is insufficient for a mutation tool.

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 parts: a restated name and an HTTP endpoint). It is front-loaded with the action but wastes space on redundant information (the name) and an endpoint that may not be relevant to the agent. It could be more concise by omitting the endpoint or integrating it better. However, it is not overly verbose.

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 (31 parameters, no annotations, no output schema), the description is incomplete. It fails to explain the tool's role in construction financials, what a commitment change order entails, or the expected outcome. Without annotations or output schema, the agent lacks guidance on behavioral aspects and return values, making this description inadequate for a creation tool with many parameters.

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?

The input schema has 31 parameters with 100% description coverage, so the schema documents each parameter thoroughly. The description adds no parameter-specific information beyond implying 'project_id' is in the URL path. Since schema coverage is high, the baseline score is 3, as the description does not need to compensate but also adds no extra semantic value.

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 Commitment Change Order. [Construction Financials/Commitments] POST /rest/v1.0/projects/{project_id}/commitment_change_orders' restates the tool name and adds minimal context. It specifies the verb 'Create' and resource 'Commitment Change Order' but lacks specificity about what a commitment change order is or its purpose in construction financials. It does not distinguish from sibling tools like 'create_prime_change_order' or 'create_commitment_change_order_batch'.

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. It does not mention prerequisites, dependencies, or typical scenarios for creating a commitment change order. Given the many sibling tools (e.g., 'create_prime_change_order', 'create_commitment_change_order_batch'), the absence of usage guidelines 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.