Skip to main content
Glama
TylerIlunga

Procore MCP Server

list_project_vendors

Retrieve vendor information for a specific project in Procore, enabling filtering by name, trade, cost code, and other criteria to manage project suppliers.

Instructions

List project vendors. [Core/Directory] GET /rest/v1.0/projects/{project_id}/vendors

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesUnique identifier for the project.
viewNoThe normal view provides what is shown below. The extended view is the same as the normal view but includes children_count, legal_name, parent, and bidding. The default view is normal.
pageNoPage
per_pageNoElements per page
filters__searchNoReturn vendors where the search string matches the vendor name, keywords, origin_code, or ABN/EIN number
filters__standard_cost_code_id__NoReturns vendors associated with the specified standard cost code id(s)
filters__trade_id__NoReturns vendors associated with the specified trade id(s)
filters__id__NoReturns vendors with the specified id(s)
filters__parent_id__NoReturns vendors with the specified parent id(s)
filters__abbreviated_name__NoReturn vendors(s) matching any of the specified abbreviated names in the abbreviated_name filter.
sortNoReturn items with the specified sort.
Behavior2/5

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 'List project vendors' and includes a technical endpoint '[Core/Directory] GET /rest/v1.0/projects/{project_id}/vendors', which implies a read-only operation via HTTP GET. However, it does not disclose behavioral traits like pagination behavior (implied by 'page' and 'per_page' parameters but not explained), rate limits, authentication needs, or error handling. The description adds minimal context beyond the endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: 'List project vendors. [Core/Directory] GET /rest/v1.0/projects/{project_id}/vendors'. It is front-loaded with the purpose and includes technical endpoint information. However, the endpoint detail might be extraneous for an AI agent if not contextualized, but it does not waste space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (11 parameters, no annotations, no output schema), the description is incomplete. It lacks information on behavioral aspects like pagination, filtering behavior, return format, or error cases. The endpoint hint adds some context but does not compensate for the missing guidance on usage and transparency needed for a tool with many parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with detailed parameter documentation (e.g., 'view' enum values explained, 'filters__search' semantics). The description does not add any parameter semantics beyond what the schema provides. With high schema coverage, the baseline score is 3, as the description does not compensate but also does not detract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List project vendors' clearly states the verb ('List') and resource ('project vendors'), which is adequate. However, it does not distinguish this tool from its sibling 'list_project_vendors_v1_1' or other list tools, making it vague in comparison. It lacks specificity about scope or differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 any prerequisites, exclusions, or context for usage. The sibling tool 'list_project_vendors_v1_1' exists, but no comparison is made, leaving the agent without direction.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TylerIlunga/procore-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server