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 mentions 'List generic tool items' and includes an API endpoint, but does not describe whether this is a read-only operation, if it requires specific permissions, what the output format is, or any rate limits or pagination behavior. For a list tool with 19 parameters, this lack of behavioral detail is a significant gap.

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 a single sentence and an API endpoint, but it is under-specified rather than efficiently informative. The bracketed note and endpoint add some structure, but the core description 'List generic tool items' is too vague. While not verbose, it fails to convey essential information, making it less effective despite its brevity.

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 (19 parameters, no annotations, no output schema), the description is incomplete. It does not explain what 'generic tool items' are, the expected output, or behavioral traits like pagination or filtering logic. For a tool with many parameters and no structured guidance beyond the schema, the description should provide more context to aid the agent in proper usage.

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%, meaning all 19 parameters are documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as explaining relationships between filters or typical usage patterns. However, with high schema coverage, the baseline score is 3, as the schema adequately handles parameter documentation.

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 'List generic tool items' is a tautology that restates the tool name without adding clarity. It includes a bracketed note '[Company Admin/Custom - Configurable Tools]' and an API endpoint 'GET /rest/v1.0/projects/{project_id}/generic_tools/{generic_tool_id}/generic_tool_items', but these do not specify what the tool does beyond listing items. The description fails to explain what 'generic tool items' are or how this differs from other list tools, making it vague and minimally informative.

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. While the bracketed note '[Company Admin/Custom - Configurable Tools]' hints at a context, it does not explicitly state usage scenarios, prerequisites, or exclusions. Without clear instructions on when or why to invoke this tool, the agent lacks necessary decision-making context.

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