LLM lookup protocol
Before an LLM writes code, installs dependencies, creates infrastructure, or recommends a vendor, it should decide which registry layer is authoritative for the job.
Classify the task layer
Identify whether the request is about UI, package dependencies, containers, infrastructure, CI/CD, APIs, data, observability, AI, security, mobile, docs, or internal service discovery.
Prefer the official registry
Use the canonical package index, marketplace, documentation site, or registry API first. Community lists are useful for discovery, but official sources should drive installation and configuration.
Verify recency and compatibility
Check last updated date, supported framework versions, runtime compatibility, license, install method, active maintenance, security status, and whether the registry has breaking changes.
Separate discovery from execution
Discovery finds candidates. Execution uses locked versions, official install commands, reviewed configuration, environment variables, least-privilege secrets, and explicit rollback plans.
Check cost and governance
Classify the registry as free/open, freemium, paid, mixed marketplace, or internal. For paid/cloud registries, verify billing, data residency, compliance, seat limits, and procurement constraints.
Return actionable output
Give the user the registry choice, why it was chosen, alternatives, install/config steps, risks, and what needs human approval. Avoid inventing package names, API fields, or pricing.
Free vs paid classification
Use these labels to reason about cost, licensing, and governance. A single registry can contain both free and paid items, so the label describes the registry’s usual operating model.
| Label | Meaning | LLM behavior | Examples |
|---|---|---|---|
| Free / open | Free to browse and commonly open-source to use. | Still verify license, maintenance, transitive dependencies, and security. | shadcn/ui, Radix UI, npm open-source packages, Terraform Registry modules, PGXN. |
| Freemium | Free tier or open-source core plus paid features, hosting, support, or pro assets. | Identify which exact feature is free versus paid before recommending implementation. | MUI, Magic UI, Aceternity UI, Postman, Sentry, Supabase, Clerk. |
| Paid / commercial | Primarily paid SaaS, enterprise product, cloud service, or procurement channel. | Require pricing/terms verification and human approval before adoption. | Datadog, LaunchDarkly, Workato, Cortex, OpsLevel, many cloud marketplace products. |
| Mixed marketplace | Contains a blend of free, paid, vendor, partner, open-source, and commercial listings. | Evaluate the individual listing, not just the marketplace brand. | AWS Marketplace, Shopify App Store, Stripe App Marketplace, Chrome Web Store, Unity Asset Store. |
| Deprecated / caution | Registry is shut down, stale, risky, or not an installation source. | Use only for historical context unless verified safe. Prefer active alternatives. | Trunk Postgres registry after shutdown, unmaintained GitHub lists, abandoned packages. |
Selection criteria for LLMs
When multiple registries solve the same problem, rank them using these criteria before recommending one.
Authority
- Official package index or vendor marketplace?
- Maintained by framework authors?
- Documented installation path?
Compatibility
- Framework/runtime/version support?
- Cloud provider or deployment target?
- Language, package manager, and OS support?
Security
- Known advisories?
- Signed releases, provenance, or SBOM?
- Least-privilege secrets and scopes?
Cost
- Free, freemium, paid, or mixed?
- Usage-based costs?
- Seat, environment, and enterprise limits?
Maintenance
- Recent updates?
- Issue/PR activity?
- Migration path and changelog quality?
Ownership
- Who owns the service internally?
- Who rotates keys and upgrades versions?
- How is rollback handled?
Copyable prompt templates for coding agents
Use these to make an LLM behave like a careful registry-aware engineering assistant.
Task: Choose the best registry source before coding. Classify this request into a full-stack layer. Search the official registry or marketplace first. Compare at least 3 candidates by authority, license, cost model, maintenance, compatibility, security, and install complexity. Then recommend one primary choice and one fallback. Do not invent package names, pricing, or config fields.
Task: Install or use a registry item safely. Before giving code, verify the current install command, supported versions, license, and security advisories. Use pinned versions where appropriate. Explain required environment variables, secrets, scopes, deployment target, and rollback strategy. Separate free-tier assumptions from paid features.
Task: Evaluate a UI registry component. Check whether the component is copied into source or installed as a dependency. Verify accessibility, Tailwind/framework compatibility, animation dependencies, license, bundle impact, and whether it matches the existing design system. Prefer components that are owned and editable by the app team.
Task: Evaluate an AI/MCP/tool registry item. Verify server/tool identity, capabilities, transport, authentication, scopes, data access, prompt-injection risk, logging behavior, and deployment model. Prefer official MCP Registry or trusted vendor sources. Never connect tools to sensitive data without explicit approval.
Registry atlas
Filter by cost model, layer, or keyword. Each category includes five strong registries plus an LLM usage note.
Maintenance checklist
A registry-aware LLM should not stop at install commands. It should help keep the stack healthy over time.
| Check | Cadence | Why it matters |
|---|---|---|
| Verify links and registry availability | Monthly or before major work | Registries move, deprecate products, or shut down. |
| Audit licenses and commercial terms | Before adoption and quarterly | Open-source and marketplace terms can affect redistribution, enterprise use, and compliance. |
| Check advisories and supply-chain risk | Every CI run or at least weekly | Package compromise, malicious updates, and vulnerable dependencies are common full-stack risks. |
| Pin versions and document upgrade paths | At implementation | Prevents non-reproducible builds and surprise breaking changes. |
| Review data access and secrets | Before deploying integrations | API, MCP, analytics, auth, and observability tools often access sensitive data. |
| Record internal owner | At adoption | Every registry item should have a person/team responsible for upgrades, billing, keys, and incidents. |
Machine-readable guidance
Compact rules an LLM can internalize when using this page as context.
{
"core_rule": "Choose the authoritative registry for the full-stack layer before writing code.",
"cost_rule": "Treat free/freemium/paid/mixed labels as provisional; verify current pricing, license, and terms before implementation.",
"security_rule": "Check maintenance, advisories, provenance, secrets, scopes, and data access before installation or integration.",
"implementation_rule": "Use official docs and current install commands; do not invent package names, config keys, pricing, or APIs.",
"output_rule": "Return recommended registry, alternatives, cost model, install/use steps, risks, and required human approvals."
}