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. It states 'Create RFI Reply' and includes an HTTP POST endpoint, implying a write operation, but does not disclose behavioral traits like required permissions, whether it sends notifications, if attachments are mandatory, or what the response format is. The description is minimal and fails to provide necessary behavioral context 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 concise with two parts: a restated name and an HTTP endpoint. However, it is under-specified rather than efficiently informative. The front-loaded 'Create RFI Reply' is clear but lacks substance, and the endpoint detail is technical without adding user-facing value. It avoids waste but fails to earn its place with meaningful content.

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 (a mutation tool with attachments and nested objects), no annotations, and no output schema, the description is incomplete. It does not explain what an RFI reply is, the expected reply object structure, success conditions, or error handling. The schema covers parameters, but the description lacks context needed for effective tool use, especially with sibling tools present.

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 parameter descriptions in the schema (e.g., 'Unique identifier for the project', 'RFI ID', 'reply', 'attachments' with upload instructions). The description adds no additional parameter semantics beyond the schema. Given the high coverage, 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 'Create RFI Reply. [Project Management/RFI] POST /rest/v1.0/projects/{project_id}/rfis/{rfi_id}/replies' restates the tool name ('Create RFI Reply') and adds only generic context tags and an HTTP endpoint. It does not specify what an RFI reply entails (e.g., submitting a response to a Request for Information) or distinguish it from sibling tools like 'create_rfi' or 'update_rfi_reply'. This is a tautology with minimal added value.

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 (e.g., an existing RFI), when to use it over other reply-related tools, or any constraints. With many sibling tools present, the lack of differentiation leaves the agent without usage context.

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