Skip to main content
Glama
Sign In
Corbel

Corbel

by sgoettl17
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Describe a Procore endpoint

corbel_describe_endpoint
Read-only

Look up a Procore endpoint's path, parameters, and request-body fields by operation_id from the local index without calling Procore.

Instructions

Return the path, parameters and request-body fields of one Procore endpoint from the bundled index. 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": {
      "operation_id": "<operation_id>"
    },
    "name": "corbel_describe_endpoint"
  }
}

Input Schema

NameRequiredDescriptionDefault
operation_idYesoperation_id from corbel_search_endpoints.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: the data comes from a bundled local index and no Procore API call is made, which tells the agent results may be static or stale. It does not say what happens for an unknown operation_id or whether output is paginated.

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 short sentences, front-loaded with the return payload and immediately followed by the key constraint. Nothing is redundant or padded.

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?

With no output schema, the description carries the burden of describing the return value and does so concretely (path, parameters, request-body fields). The main residual gap is failure behavior for an unknown or stale operation_id, which matters for an index-backed lookup.

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?

Schema coverage is 100% with a single parameter, and the schema already states that operation_id comes from corbel_search_endpoints. The description adds no additional detail about the identifier format or validity. Baseline 3 applies when the schema carries the parameter semantics.

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

Purpose5/5

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

States a specific verb and resource ('Return the path, parameters and request-body fields of one Procore endpoint') and names the source ('bundled index'). The sentence 'Does not call Procore' separates it cleanly from corbel_get, and 'one endpoint' separates it from corbel_search_endpoints.

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 plus the parameter note 'operation_id from corbel_search_endpoints' makes the call chain clear: search first, then describe. The negative 'Does not call Procore' implicitly routes live invocation to corbel_get. There is no explicit statement of when this tool is unnecessary, but the workflow context is unambiguous.

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