Fix search_devices API parameter mapping

[r2DoesInc]

Summary

Fix search_devices so its documented interface maps to the query parameter names and values accepted by the Bugfender devices API.

The MCP schema advertises last_active, name_asc, and name_desc, but forwarding last_active directly causes the API to return Invalid order. The Get App Devices API documentation specifies these tokens instead:

• last_active -> seen
• name_asc -> nameaz
• name_desc -> nameza

This keeps the clearer MCP-facing enum while translating it at the HTTP boundary. If the API rejects an order value, the returned error now lists both accepted MCP values and API tokens.

The same query mapper corrects additional schema drift:

• name -> device_name
• model -> device_model
• enabled -> device_status (1 or 0)
• next_cursor -> nextCursor
• current_app_version is now an integer app-version ID and maps to version
• device_id is exposed for exact UID/UDID filtering and prefix matching
• device page size is clamped to the documented maximum of 100

The API exposes a versions listing endpoint, but accepting the integer ID directly matches the existing search_logs convention and avoids ambiguity when one version string has multiple builds. Callers can obtain IDs from list_app_versions.

Undocumented filters

date_range_start, date_range_end, log_text, and log_level were advertised and forwarded to the devices endpoint, but are absent from the Get App Devices documentation. Each was tested individually against a live app with otherwise valid query parameters. Every one returned HTTP 400 with Invalid query parameters; none was silently ignored. They have therefore been removed from the search_devices schema.

Tests

• Added unit coverage for all order mappings
• Added unit coverage for device ID, version ID, field-name, status, and cursor mappings
• Added page-size limit coverage
• Added actionable invalid-order error coverage
• pnpm test
• pnpm check
• pnpm build