---
summary: "search_entities — coerce bare relevance_score sort to descending so OpenAlex stops rejecting it; document that relevance_score requires an active search"
breaking: false
---

# 0.6.6 — 2026-05-01

Bug-fix release. The `openalex_search_entities` tool's `sort` description recommended `relevance_score` (bare), but OpenAlex defaults bare-direction sorts to `:asc` and forbids ascending relevance — every such call returned `400 Bad Request: "Sorting relevance score ascending is not allowed."` Verified live against the API: ascending relevance is rejected, descending succeeds, and the field additionally requires an active search query.

## Fixed

- **`normalizeSort` coerces bare `relevance_score` to `relevance_score:desc`** — `src/services/openalex/openalex-service.ts`. Information-preserving (ascending relevance has no semantic meaning), so it isn't a guess at intent. The existing `-` prefix path (`-relevance_score` → `relevance_score:desc`) is unchanged. Other ascending sorts continue to pass through untouched. Closes [#12](https://github.com/cyanheads/openalex-mcp-server/issues/12).

## Changed

- **`openalex_search_entities` `sort` description** — recommends `-relevance_score` to match the documented `-` prefix convention, and now warns that `relevance_score` requires an active search via `query` or a `filter:search` filter. The previous wording (*"Use `relevance_score` or omit sort"*) actively encouraged the failing pattern.

## Maintenance

- 4 unit tests added for `normalizeSort` covering bare passthrough, the new `relevance_score` coercion, the `-relevance_score` translation, and no-sort omission. Field-tested live against OpenAlex: the issue's exact reproduction (`query: "natural remedy edema feet"`, `sort: "relevance_score"`) now returns 200 with relevance ranking; `-relevance_score` without a query surfaces the documented "must include a search query" constraint with the contract recovery hint.