Nullcost Recommend

Nullcost Recommend

The user invoked this command with: $ARGUMENTS

Instructions

1. If $ARGUMENTS clearly asks for multiple stack parts such as hosting, auth, postgres, and email, use recommend_stack with the full natural-language request.
2. Otherwise use recommend_providers with the user's full natural-language use case.
3. If $ARGUMENTS is actually about domain availability, registrar pricing, TLD choice, transfers, renewals, or exact domain registration status, stop and route to TLDPlug instead of Nullcost.
4. Keep the answer DB-backed and catalog-first for v1. Do not browse, web-search, or verify official pricing pages.
5. If one result clearly wins and the user wants more detail on that exact provider, call get_provider_detail on that top provider before answering.
6. Preserve the tool's Markdown table output. Do not rewrite a table result into prose paragraphs when the host can render Markdown.
7. Return one short winner line first, unless the DB cannot confirm a requested feature from structured fields. In that case, say it is a shortlist instead of naming a hard winner.
8. Then render the top results as a Markdown table.
9. When there are 2 or more results, a Markdown table is required. Do not answer with prose paragraphs only.
10. Keep the table compact with a stable spine: Provider, Link, Price, and Fit.
11. Add only 1 compact dynamic column when it materially helps and actually varies across the returned rows. Use 2 only when the comparison really needs it.
12. Prefer dynamic columns like MCP Fit, Setup, Free Entry, API Surface, or Deployment based on the request.
13. Distinguish Free tier from Free trial in the Price or Free Entry cell. Do not collapse them into the same label.
14. If the user asks for best value, affordable, good value, cheap, spend, cost, current pricing, or SSR costs, stay on the Nullcost database path and prefer providers with visible pricing while calling out when pricing is unknown.
15. Do not waste columns on signals that are constant across the current rows.
16. Mention the main tradeoff for each row in the Fit text instead of adding a generic Notes column unless the comparison truly needs it. Keep Fit short.
17. Mention any verified program or discount signal only after the fit-based recommendation.
18. If the user is following up on an earlier shortlist, pass the earlier use case or shortlist summary into the tool's context field so modifiers like cheaper, self-hosted, or only show auth are interpreted correctly.
19. If the user asks for features the DB does not confirm cleanly, explicitly say that and present a shortlist table rather than overstating certainty.

Output Shape

Prefer this structure in normal chat:

**Best fit:** Provider name

| Provider | Link | Price | MCP Fit | Fit |
| --- | --- | --- | --- | --- |
| Winner | [Official](https://example.com) | ... | ... | ... |
| Alt 1 | [Official](https://example.com) | ... | ... | ... |
| Alt 2 | [Official](https://example.com) | ... | ... | ... |

If the host clearly fails to render Markdown tables, fall back to compact rows. Prose-only recommendation answers are incorrect when a table can be rendered.