Skip to main content
Glama
TylerIlunga

Procore MCP Server

List Observation Items

list_observation_items
Read-onlyIdempotent

Retrieve a paginated list of observation items for a project. Filter by status, assignee, location, or other criteria.

Instructions

Returns a collection of Observation Items. See Filtering on List Actions for information on using the filtering capabilities provided by this endpoint. Use this to enumerate Observations when you need a paginated overview, to find IDs, or to filter by query parameters. Returns a paginated JSON array of Observations. Use page and per_page to control pagination; the response includes pagination metadata. Required parameters: project_id. Procore API: Project Management > Observations. Endpoint: GET /rest/v1.0/observations/items

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filters__assignee_company_idNoQuery string parameter — array of Vendor IDs. Returns item(s) where the assignee is associated to the specified Vendor ID.
filters__checklist_list_idNoQuery string parameter — array of Checklist List IDs. Return item(s) associated with the specified Checklist List IDs.
filters__created_by_idNoQuery string parameter — returns item(s) created by the specified User IDs.
filters__idNoQuery string parameter — return item(s) with the specified IDs.
filters__location_idNoQuery string parameter — return item(s) with the specified Location IDs.
filters__assignee_idNoQuery string parameter — return item(s) assigned to the specified User ID.
filters__checklist_item_idNoQuery string parameter — return Observations(s) originating from the specified Checklist Item(s).
filters__priorityNoQuery string parameter — return item(s) with the specified priorities.
filters__searchNoQuery string parameter — return item(s) matching the specified Search query.
filters__statusNoQuery string parameter — return item(s) with the specified status values. The mapping is as follows: ``` 0: Initiated 1: Ready For reviewed 2: Not Accepted 3: Closed ```
filters__type_idNoQuery string parameter — return item(s) with the specified Observation Type ID.
filters__trade_idsNoQuery string parameter — array of Trade IDs. Returns item(s) with the specified Trade IDs.
filters__updated_atNoQuery string parameter — return item(s) last updated within the specified ISO 8601 datetime range. Formats: `YYYY-MM-DD`...`YYYY-MM-DD` - Date `YYYY-MM-DDTHH:MM:SSZ`...`YYYY-MM-DDTHH:MM:SSZ` - DateTime with UTC Offset `YYY...
project_idYesQuery string parameter — unique identifier for the project.
pageNoQuery string parameter — page number for paginated results (default: 1)
per_pageNoQuery string parameter — number of items per page (default: 100, max: 100)
Behavior4/5

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

Annotations already indicate readOnly and idempotent. The description adds value by stating the tool returns a paginated JSON array with pagination metadata, which is not covered by annotations. No contradictions.

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

Conciseness5/5

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

The description is four sentences, front-loaded with the core purpose, and each sentence provides necessary information without redundancy. It is concise and well-structured.

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

Completeness4/5

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

Given the tool's complexity (16 parameters, no output schema), the description covers essential aspects: purpose, filtering, pagination, and API reference. It could be more detailed about return fields, but the inclusion of a link to filtering documentation compensates.

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, so the baseline is 3. The description mentions that project_id is required and page/per_page control pagination, but this adds minimal value over the schema's own parameter descriptions.

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

Purpose4/5

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

The description clearly states that the tool returns a collection of Observation Items and is used for paginated overviews, finding IDs, or filtering. However, it does not explicitly differentiate from sibling tools like 'list_recycled_observation_items' or 'list_observation_item_response_logs'.

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

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on when to use the tool (e.g., for paginated overviews, filtering) and mentions pagination parameters. It does not specify when not to use or list alternatives, but the context is clear.

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