Delete Project Currency Configuration

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

Beyond the annotations, the description discloses that the deleted configuration is returned in the 200 response body, that subsequent GETs return null currency fields until a new configuration is created, and that a repeat call returns 404. It also details common error statuses (401, 403, 404) and the error payload format, all of which are not present in the annotations.

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 longer than average but every sentence carries distinct information: core action, response body, post-deletion state, error condition, safety tip, defaulting behavior, irreversibility, required parameters, and API reference. The primary purpose is stated first, and supporting details follow in a logical, front-loaded structure.

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?

For a destructive tool with no output schema, the description comprehensively covers return values, side effects, error semantics, prerequisites, and default values. It also includes the exact HTTP endpoint and Procore API category, making it fully self-contained for an agent to 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 schema already provides full descriptions of company_id and project_id (coverage 100%), so the baseline is 3. The description adds the valuable context that these parameters default to values set by procore_set_config when omitted and that they are required. This supplements the schema without redundancy.

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 opens with 'Deletes the project's currency configuration,' clearly stating the action and target. It further specifies that the deletion is permanent and cannot be undone, distinguishing it from create/update tools among siblings like update_project_currency_configuration. The project-level scope is explicit, differentiating it from company-level configuration tools.

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 instructs to 'Confirm the target id with the matching show or list tool before calling' and notes that a 404 is returned when no configuration exists, implying when not to call. It also explains default behavior for omitted company_id and project_id via procore_set_config, and warns about irreversibility, providing clear guidance for safe usage.

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