v2.7.1

[2.7.1] - 2026-09-26

Fixed

• pipedrive_get_product_image reported a product with no image as a generic API_ERROR (409). Live Pipedrive answers GET /products/{id}/images for an existing product that has no image with 409 "Product Image not found." (the spec documents only 200; a missing product is a normal 404). The tool now returns NOT_FOUND with "Product {id} has no image" and a pointer to pipedrive_upload_product_image. This also clears the one standing failure in the read-only live smoke run.

• pipedrive_list_archived_leads returned active leads instead of archived ones. GET /leads has no archived_flag query parameter; Pipedrive's API silently ignores it and always returns non-archived leads, so listLeads and listArchivedLeads hit the same endpoint with the same effective result regardless of which flag value was sent. Archived leads live under a separate endpoint entirely, GET /leads/archived - confirmed against Pipedrive's official API docs and, live, against a real account: same response envelope and pagination shape as /leads, but genuinely different data (is_archived: true, different lead ids). listArchivedLeads now calls that endpoint; the dead archived_flag param is dropped from both functions since neither ever needed it. Thanks to @ehames for the report and fix (#193, #194).

• Release workflow: the registry job now verifies the .mcpb GitHub Release asset is live and byte-identical before publishing to the MCP registry. Creating the Release is deliberately continue-on-error (the npm publish above it is the irreversible step), and that same step uploads the bundle, so a soft-failed Release could previously let the job publish an immutable registry entry whose download URL 404s - recoverable only by cutting a new version. The job now fails closed instead, leaving the entry to be back-published once the Release exists.