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 implies a read operation ('Show' and 'GET'), suggesting it's non-destructive, but doesn't confirm safety, permissions, rate limits, or error handling. The API endpoint hint offers some context, but behavioral details like response format or pagination (implied by 'page' and 'per_page' parameters) are missing, making it insufficient for a mutation-free 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 but not optimally structured. It front-loads the purpose ('Show Change Event') but wastes space on API details that don't aid tool selection. The bracketed category '[Construction Financials/Change Events]' adds minor context. It's concise but could be more informative without losing efficiency.

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 no annotations, no output schema, and 5 parameters (including pagination for a single event), the description is incomplete. It doesn't address why pagination parameters exist for a 'show' operation, what the output contains, or error cases. For a tool with moderate complexity and missing structured data, more explanatory context is needed.

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 (e.g., 'ID', 'Unique identifier for the project.'). The description adds no parameter semantics beyond the schema, but the high coverage justifies the baseline score of 3. It doesn't explain interactions like why 'id' and 'project_id' are both required or how pagination works with a single event.

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 'Show Change Event. [Construction Financials/Change Events] GET /rest/v1.1/change_events/{id}' restates the tool name ('Show Change Event') and adds an API endpoint, but it's vague about what 'show' means (e.g., retrieve details, display). It doesn't specify the resource clearly beyond 'Change Event' or distinguish it from siblings like 'show_change_event' (without version) or 'list_change_events_v1_1'. This is borderline tautological with minimal context.

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. With sibling tools like 'list_change_events_v1_1' (for listing) and 'show_change_event' (possibly a different version), the description lacks any indication of context, prerequisites, or comparisons. This leaves the agent without direction on selection.

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