Skip to main content
Glama
Sign In
Corbel

Corbel

by sgoettl17
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Search Procore API endpoints

corbel_search_endpoints
Read-only

Search a bundled Procore REST API index by keyword to find matching operation IDs, HTTP methods, and paths without making API calls.

Instructions

Search the bundled index of the Procore REST API (https://developers.procore.com/reference/rest/docs/rest-api-overview) by keyword and return matching operation_ids with method and path. Does not call Procore.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "corbel_search_endpoints"
  }
}

Input Schema

NameRequiredDescriptionDefault
areaNoTool area filter, e.g. 'Rfis'.
limitNo
queryYese.g. 'rfis project'
methodNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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

readOnlyHint already declares safety, but the description adds genuinely new behavior: the data comes from a bundled local index and no live Procore request or auth is involved, which matters a lot for agent planning. It also discloses the return fields. It omits truncation/default behavior for the limit parameter, keeping it short of a 5.

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?

Two sentences, front-loaded with the core action and scope, with the non-obvious caveat ('Does not call Procore') placed last for emphasis. No filler.

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

Completeness3/5

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

With no output schema, the description usefully names the return fields (operation_ids, method, path). However, for a 4-parameter search tool it leaves the filter parameters and result-size behavior unexplained, so an agent cannot fully predict what a call with 'area', 'method', or 'limit' will do.

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

Parameters2/5

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

Schema coverage is only 50%: 'area' and 'query' have descriptions, while 'limit' and 'method' have none. The description only says search is 'by keyword', vaguely mapping to query; it says nothing about area/method filtering or what limit does, so it fails to compensate for the coverage gap.

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?

States a specific verb and resource ('Search the bundled index of the Procore REST API') and specifies the return shape ('matching operation_ids with method and path'). 'Does not call Procore' implicitly separates it from corbel_get, but no sibling is named outright, so differentiation is inferred rather than explicit.

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

Usage Guidelines3/5

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

The description implies this is a discovery step (search the index, then presumably describe or call an endpoint), and 'Does not call Procore' signals it is not the execution path. It never states when to prefer this over corbel_describe_endpoint or corbel_get, nor any exclusions or preconditions.

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

Deploy Server

Other Tools