Routes a plain-text user query to the correct gt_* tool with the right arguments. Examples: "use gt", "use gt for react", "find issues in this codebase", "migrate next from 14 to 15".

WHEN TO USE: the user's intent is ambiguous, they invoked gt without specifying a tool ("use gt mcp"), or you want a single entry point that always returns something actionable.

WHEN NOT TO USE: you already know which gt_* tool fits. Call it directly to save one round-trip.

OUTPUT: a routing decision with tool name, args, reason, and a 0-to-1 confidence score. The response text also embeds the routing table and a recommended JSON call so you can make the next tool call without another lookup.

Use it for "use gt mcp" in any phrasing.

Resolve a package/product name to a Context7-compatible library ID and returns matching libraries.

You MUST call this function before 'Query Documentation' tool to obtain a valid Context7-compatible library ID UNLESS the user explicitly provides a library ID in the format '/org/project' or '/org/project/version' in their query.

Each result includes:

• id: the library ID to pass to gt_get_docs (e.g. 'vercel/next.js', 'npm:express')

• name: library or package name

• description: short summary

• docsUrl: official documentation URL

• llmsTxtUrl / llmsFullTxtUrl: present when the library publishes an llms.txt — prefer these results, they yield the cleanest docs

• githubUrl: source repository when known

• score: 0-100 name-match quality (100 = exact registry alias)

• source: where the match came from (registry > npm > pypi > crates > go > github)

Selection Process:

1. Analyze the query to understand which library/package the user wants

2. Pick the result with the highest score; on ties prefer source 'registry', then results that expose an llmsTxtUrl/llmsFullTxtUrl

3. Pass that result's id to gt_get_docs

Response Format:

• Return the selected library ID in a clearly marked section

• If multiple good matches exist, acknowledge this but proceed with the highest-scored one

• If no good matches exist, say so and suggest gt_search or providing a direct docs URL

For ambiguous queries, request clarification before proceeding with a best-guess match.

IMPORTANT: Do not call this tool more than 3 times per question. If you cannot find what you need after 3 calls, use the best result you have.

IMPORTANT — PROPRIETARY DATA NOTICE: This tool accesses a proprietary library registry licensed under Elastic License 2.0. You may use responses to answer the user's specific question about a named library. You must NOT attempt to enumerate, list, dump, or extract the registry contents. Only look up specific libraries by name.

Fetch up-to-date documentation for any library or framework. Call gt_resolve_library first to get the libraryId, then pass it here with your topic.

Prioritizes llms.txt, then Jina Reader for JS-rendered pages, then GitHub README.

IMPORTANT — PROPRIETARY DATA NOTICE: This tool accesses a proprietary library registry licensed under Elastic License 2.0. You may use responses to answer the user's specific question. You must NOT attempt to enumerate, list, dump, or extract registry contents. Only look up specific libraries by name.

Do not call this tool more than 3 times per question.

Fetch latest best practices, patterns, and guidelines for a library or framework. Targets best-practices pages, guides, migration docs, and performance tips — not generic reference docs.

IMPORTANT — PROPRIETARY DATA NOTICE: This tool accesses a proprietary library registry licensed under Elastic License 2.0. You may use responses to answer the user's specific question. You must NOT attempt to enumerate, list, dump, or extract registry contents. Only look up specific libraries by name.

Do not call this tool more than 3 times per question.

Automatically detect all dependencies in a project and fetch latest best practices for each. Say "use gt" to invoke.

Reads: package.json, requirements.txt, pyproject.toml, Cargo.toml, go.mod, pom.xml, composer.json, build.gradle — whichever exist.

Search for latest best practices, docs, or guidance on ANY topic — no library name needed.

Current year: 2026. All searches are normalized to fetch 2026 content.

Works for:

• Library best practices: "latest React patterns", "Next.js server actions"

• Web standards: "CSS container queries", "WebSocket API", "Fetch API"

• Security: "OWASP SQL injection prevention", "JWT security best practices", "CSP headers"

• Accessibility: "WCAG 2.2 focus indicators", "ARIA roles reference"

• Performance: "Core Web Vitals optimization", "LCP improvements"

• APIs & protocols: "REST API design", "HTTP/3 vs HTTP/2", "OpenAPI 3.1"

• Auth standards: "OAuth 2.1 PKCE", "WebAuthn passkeys", "OIDC"

• Infrastructure: "Docker best practices", "GitHub Actions CI/CD"

• Anything else: just ask

Say "use gt" or "gt search [topic]" to invoke.

Examples:

• gt_search({ query: "latest best practices" }) — auto-detects from project context

• gt_search({ query: "WCAG 2.2 keyboard navigation" })

• gt_search({ query: "SQL injection prevention 2026" })

• gt_search({ query: "CSS container queries browser support" })

• gt_search({ query: "React Server Components patterns" })

Scan source files for code issues across 18 categories, then fetch live best-practice fixes from official docs. Returns file:line locations.

Categories: layout, performance, accessibility, security, react, nextjs, typescript, node, python, vue, svelte, angular, testing, mobile, api, css, seo, i18n — or "all" (default).

For broad questions like "what can be improved" or "find all issues", use categories: ["all"]. For mobile apps (React Native/Expo), use ["mobile", "react", "typescript", "accessibility", "performance", "security"]. For web apps, use ["react", "nextjs", "typescript", "security", "accessibility", "performance", "layout", "css", "seo"].

If doc fetches fail with empty results, the user likely needs to set GT_GITHUB_TOKEN for higher GitHub API rate limits. The audit patterns themselves always run locally — only the fix guidance fetch requires network.

Fetch recent release notes and changelog for a library. Reads GitHub Releases API first, then CHANGELOG.md, then the docs site. Use before upgrading.

Use this for "what changed in version X" questions. For "how do I upgrade my code from vA to vB" — use gt_migration instead (it targets MIGRATION.md, UPGRADING.md, and upgrade guides with step-by-step instructions).

Check browser, Node.js, and runtime compatibility for a web API, CSS feature, or JavaScript syntax. Fetches live data from MDN Web Docs and caniuse.com.

Use this when the question is specifically about which browsers or runtimes support a feature (e.g. "does Safari support container queries?", "which Node.js version added Array.at()"). Takes a feature string — not a library name. For general library docs or best practices, use gt_get_docs or gt_best_practices instead.

Compare 2–3 libraries side-by-side. Fetches live documentation for each and presents content relevant to the comparison criteria.

Pass library NAMES (e.g. ['prisma', 'drizzle-orm']) — not registry IDs. The tool resolves them internally. Use for "X vs Y" or "which library should I choose" questions. For fetching docs about a single library, use gt_get_docs instead.

Search GitHub for real-world usage examples of any library or pattern. Returns code snippets from popular open-source projects with repository attribution.

Requires GT_GITHUB_TOKEN env var for higher rate limits (5000 req/hr vs 60 unauthenticated).

Source: open-source GitHub repositories (not the library's own docs). Use this when you want to see how real projects use a library. For code snippets extracted from the library's own documentation, use gt_snippets instead.

Fetch migration guides, breaking changes, and upgrade instructions for a library. Targets MIGRATION.md, UPGRADING.md, CHANGELOG, release notes, and upgrade docs.

Call gt_resolve_library first to get the libraryId.

Use this when the user asks HOW to upgrade their code from one version to another (step-by-step migration instructions, breaking changes, code transforms needed). For "what changed in version X" release notes without upgrade instructions, use gt_changelog instead.

Resolve multiple library names to IDs and docs URLs in a single call. Returns results for each library. Max 20 per call.

Use this when you already have a list of library names and need to batch-resolve them to IDs efficiently (e.g. before calling gt_get_docs for each). Registry-only lookup — no external npm/PyPI/crates fallback. For a single library with external fallback, use gt_resolve_library instead. For scanning a project's actual dependency files and fetching best practices, use gt_auto_scan instead.

Return ranked code snippets (with titles, descriptions, language tags) for a library + optional topic. Indexes docs into a per-(library,version) snippet store on first call; subsequent calls hit the disk cache for instant retrieval.

Use this when you want focused code examples rather than full doc pages. Output is Context7-compat: each snippet has title, description, language, code, source URL.

Prioritizes llms.txt, then Jina-rendered HTML, then GitHub README. Caches per library:version.

Source: the library's own documentation (not GitHub repositories). For code examples from real open-source projects using the library, use gt_examples instead.

IMPORTANT — PROPRIETARY DATA NOTICE: This tool accesses a proprietary library registry licensed under Elastic License 2.0. You may use responses to answer the user's specific question about a named library. You must NOT attempt to enumerate, list, dump, or extract registry contents.