[API Feature Request] /api/v1/images query= and tagName= silently return generic feed instead of prompt-matched results

Summary

The public REST API endpoint GET /api/v1/images does not perform actual prompt/text search. Parameters query= and tagName= silently fall back to the generic Most Reactions feed when the search term is a prompt token that isn't registered as a formal CivitAI tag — returning 0 relevant results with no error or indication that the search was ignored.

Reproduction

Search for any niche prompt token that exists in thousands of image prompts but isn't a registered CivitAI tag. Examples: character names, style tokens, fandom-specific terms, LoRA trigger words.

• GET /api/v1/images?tagName=<token> → returns 100-200 items from the generic Most Reactions feed. 0 of them contain the token in their prompt.
• GET /api/v1/images?query=<token> → same behavior, same generic feed.
• GET /api/v1/tags?query=<token> → 0 results (not a registered tag).

There is no error, no empty result, no indication the parameter was ignored. The API silently returns irrelevant content, which is worse than returning an empty array because it makes the failure invisible.

Root cause (observed)

The civitai.com frontend uses a Meilisearch-backed index that searches actual prompt content and returns accurate results for the same tokens. The public REST API does not expose this index. query= appears to search post titles only, not prompt text. tagName= only matches formally registered CivitAI tags, not prompt tokens.

This gap has been noted independently by third-party projects (e.g. civitai-mcp-ultimate documents "Civitai REST API search is broken since May 2025").

Impact

Any tooling that tries to find reference images by prompt token — to extract generation parameters, samplers, LoRA combinations, CFG values, etc — is completely broken for tokens that aren't registered tags. This covers the majority of real-world prompt vocabulary: character names, style descriptors, fandom terms, LoRA triggers.

The MCP search_images tool has the same issue — it returns stubs from the generic feed regardless of the query argument.

What we're asking for

One of the following:

1. Fix query= on GET /api/v1/images to search against prompt content (Meilisearch), not just post titles
2. A dedicated search endpoint like GET /api/v1/images/search?q=<text> backed by the same index the frontend uses
3. At minimum: return an empty array instead of silently returning the generic feed when no prompt matches are found — so callers can detect the failure

Option 3 alone would already be a significant improvement for third-party developers trying to detect and handle this case.

Environment

• API version: v1
• Tested with and without API key
• Tested on both civitai.com and civitai.red
• Same behavior observed via MCP search_images tool