Create Link (Deprecated)

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

The description adds substantial behavior beyond the annotations. It explains that calling the tool again creates another record (non-idempotent), describes the success response (HTTP 201 with new id), details common failure modes (401, 403, 404), and clarifies the request payload nesting ('Pass the record's fields as top-level arguments — they are nested under "link" in the request payload for you'). This enriches the sparse annotation set without contradiction.

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 front-loaded with purpose and effectively organized, but it contains redundancy: deprecation is mentioned twice ('This endpoint will be deprecated...' and 'DEPRECATED: Procore has deprecated this endpoint...'). Including the API path and Procore API section adds length without crucial value. It is informative but not maximally concise.

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?

Despite a simple tool with no output schema, the description covers permissions, deprecation, success and failure behavior, payload structure, and required parameters. It even mentions 'Creates the link and returns it with its new id (HTTP 201),' which addresses return value expectations. This is complete for an agent to select and invoke the tool correctly.

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?

The input schema already describes all three required parameters (project_id, title, url) with 100% coverage. The description adds minor context by listing them as required and noting the top-level versus nested payload structure, but it does not provide significant extra meaning beyond the schema. Baseline 3 is appropriate.

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 begins with a clear, specific verb and resource: 'Creates a Project Home Link on a given project.' This unambiguously states the tool's function and distinguishes it from sibling tools like list_links, update_link, and delete_link. It also references the V2 endpoint for bulk updates, further differentiating this creation action from related operations.

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 explicitly advises against using this deprecated endpoint and directs the agent to the V2 endpoint, even providing a link and instructing to 'use procore_search_endpoints to find it.' It also states required permissions ('Requires either Company Admin or Project Home Admin permission'), giving clear context on when this tool can be invoked versus alternatives.

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