MCP: send your key in a header; query-string keys stop working November 30, 2026
The api_key query parameter is deprecated on the MCP endpoints. Send your key in an Authorization: Bearer header (or X-API-Key) instead. A key in a URL ends up in proxy and access logs, browser history and Referer headers. ?api_key= keeps working on /api/v1/mcp, /api/v1/mcp/sse and /api/v1/mcp/messages until November 30, 2026. After that date a request that only sends its key in the URL gets a 401. Until then, every response to such a request carries Deprecation, Sunset and Warning headers so your client can tell. If you send both a header and a query key, the header is used.
GetByHtsTool now lists the same additional duties as /resolve. With an origin, its additional_measures come from the same calculation /resolve uses, so duties that stack on one another, such as Section 232 alongside Section 301, all appear. You may see more duties listed for a line than before, and a total built from them may be higher.
Unknown HTS codes now fail. ResolveTariffTool and GetByHtsTool return an error with error_code HTS_NOT_FOUND for a code we cannot identify, the same answer /resolve gives, instead of a result. In BatchResolveTariffsTool the item fails with the same code and the rest of the batch still resolves.
Dates must be YYYY-MM-DD. as_of on the MCP tools now accepts only that format. Anything else fails with INVALID_DATE rather than being guessed at.
Tool results are JSON. Every tool result is now JSON text, and a failed call sets isError: true on the result, so your client can tell a failure from an answer without reading the text.