This server (GroundTruth) is a self-hosted MCP server that fetches live documentation, best practices, and code quality insights for 445+ libraries and frameworks — no API keys or rate limits required.
Resolve Libraries (gt_resolve_library): Look up any library by name to get its canonical ID and docs URL, with fallback to npm, PyPI, crates.io, and pkg.go.dev.
Batch Resolve (gt_batch_resolve): Resolve up to 20 library names to IDs and documentation URLs in a single call.
Fetch Documentation (gt_get_docs): Retrieve current docs for any library and topic, prioritizing llms.txt, then Jina Reader, then GitHub README.
Get Best Practices (gt_best_practices): Fetch patterns, anti-patterns, performance tips, and configuration guidance for any library or framework.
Auto-Scan Project Dependencies (gt_auto_scan): Automatically detect all dependencies from manifest files (package.json, requirements.txt, Cargo.toml, go.mod, etc.) and pull best practices for each.
Freeform Search (gt_search): Search any topic — security (OWASP), accessibility (WCAG), performance (Core Web Vitals), MDN web APIs, AI providers, infrastructure, and more.
Code Audit (gt_audit): Scan source files with 107+ patterns across 18 categories (security, accessibility, React, Next.js, TypeScript, Python, Node.js, etc.), returning exact file:line locations with live fix guidance.
Fetch Changelogs (gt_changelog): Retrieve recent release notes from GitHub Releases and CHANGELOG files before upgrading a library.
Browser/Runtime Compatibility (gt_compat): Check compatibility of web APIs, CSS features, or JavaScript syntax across browsers and runtimes using MDN and caniuse data.
Compare Libraries (gt_compare): Compare 2–3 libraries side-by-side on criteria like performance, TypeScript support, or bundle size.
Find Code Examples (gt_examples): Search GitHub for real-world usage examples of any library or pattern.
Migration Guides (gt_migration): Fetch breaking changes and upgrade instructions between versions of any library.
Provides documentation and best practices for Biome formatting/linting.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ws-mcp audit my source code for security issues"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
GroundTruth is a self-hosted MCP server and command-line tool. Models write code from what they were trained on, so they still wrap components in forwardRef after React 19 made ref a regular prop, call cookies() synchronously after Next.js made it async, and emit @tailwind directives that Tailwind v4 replaced with @import "tailwindcss". GroundTruth gives the agent the library's own documentation at request time: it reads llms.txt, the docs site as markdown, or the GitHub repository, ranks the sections that answer the question, and checks that the answer covers the topic before returning it. It also audits your source with 107+ patterns and links every finding to the current fix. It runs on your machine. No account, no API key, no rate limit of its own.
Requires Node.js 24 or newer.
Claude Code
claude mcp add gt -- npx -y @groundtruth-mcp/gt-mcp@latestCursor, Claude Desktop, Windsurf and other clients that use an mcpServers block (.cursor/mcp.json, claude_desktop_config.json, ~/.codeium/windsurf/mcp_config.json):
{
"mcpServers": {
"gt": {
"command": "npx",
"args": ["-y", "@groundtruth-mcp/gt-mcp@latest"]
}
}
}VS Code (.vscode/mcp.json):
{
"servers": {
"gt": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@groundtruth-mcp/gt-mcp@latest"]
}
}
}Any other MCP client: run npx -y @groundtruth-mcp/gt-mcp@latest as a stdio server.
Command line (same tools, no MCP client needed):
npm install -g @groundtruth-mcp/gt-mcp
gt-mcp bp nextjs caching@latest makes npx pick up new releases on the next session start. When a newer version exists, tool responses carry a one-line notice (GT_NO_UPDATE_CHECK=1 turns the check off).
GroundTruth reads READMEs, release notes, migration guides and code examples from GitHub. Without a token GitHub allows 60 requests per hour. A token with no extra scopes raises that to 5,000 and enables code search in gt_examples.
claude mcp add gt -e GT_GITHUB_TOKEN=ghp_yourtoken -- npx -y @groundtruth-mcp/gt-mcp@latestIn a JSON config, add "env": { "GT_GITHUB_TOKEN": "ghp_yourtoken" } next to args.
Related MCP server: docs-mcp
Fourteen tools. Each does one job, and each is also a CLI command.
Tool | CLI | What it does |
|
| Routes a plain request ("use gt for drizzle migrations") to the right tool and arguments |
|
| Finds a library by name; falls back to npm, PyPI, crates.io and Go modules |
|
| Live docs for one topic; also accepts a docs URL |
|
| Patterns, anti-patterns and configuration guidance for a library |
|
| Reads your manifest and fetches best practices for each dependency |
|
| Any topic without a library: OWASP, MDN, web.dev, W3C, AI provider docs, Google APIs |
|
| Scans source files and reports issues at |
|
| Release notes before you upgrade |
|
| Browser and runtime support from MDN browser-compat-data and caniuse |
|
| Two or three libraries side by side |
|
| Real-world code from GitHub |
|
| Migration guides and breaking changes between versions |
|
| Resolves up to 20 libraries in one call |
|
| Ranked code snippets per library and version, cached on disk |
The server also exposes 2 MCP resources (library-registry, library-docs) and 8 prompts (audit-my-project, upgrade-check, best-practices-scan, compare-libraries, security-check, migration-guide, find-examples, dependency-audit).
You don't need the tool names. Ask in plain language:
use gt for nextjs
use gt for drizzle migrations
gt audit
use gt to check WCAG focus indicators
use gt for OpenTelemetry setup
find all issues and fix with gtOr call tools directly:
gt_resolve_library({ libraryName: "nestjs" })
gt_get_docs({ libraryId: "nestjs/nest", topic: "guards" })
gt_best_practices({ libraryId: "vercel/next.js", topic: "caching" })
gt_auto_scan({ projectPath: "." })
gt_search({ query: "OWASP SQL injection prevention" })
gt_audit({ projectPath: ".", categories: ["security", "accessibility"] })
gt_changelog({ libraryId: "vercel/next.js", version: "15" })
gt_compat({ feature: "CSS container queries", environments: ["safari"] })
gt_compare({ libraries: ["prisma", "drizzle-orm"], criteria: "TypeScript support" })
gt_examples({ library: "hono", pattern: "middleware" })gt_auditWalks your project, runs 107+ patterns across 18 categories, reports each issue at file:line, then fetches the fix from the authoritative source.
gt_audit({ categories: ["all"] }) // all 18 categories
gt_audit({ categories: ["security", "node"] }) // OWASP + Node.js
gt_audit({ categories: ["python", "security"] }) // Python OWASP scan
gt_audit({ categories: ["accessibility"] }) // WCAG AA
gt_audit({ categories: ["typescript", "react"] }) // type safety + React rulesCategory | What it checks |
| XSS, SQL injection, command injection, SSRF, path traversal, hardcoded credentials, CORS wildcard |
| Missing alt text, onClick on div, icon-only buttons, inputs without labels, |
| forwardRef (React 19), useFormState renamed, index as key, conditional hooks |
| Sync cookies/headers/params (Next.js 16), Tailwind v3 directives, missing metadata |
|
|
| Missing lazy loading, useEffect data fetching, missing Suspense boundaries |
| CLS-causing images, 100vh on mobile, missing font-display |
| console.log in production, sync fs ops, unhandled callbacks |
| SQL injection via f-string, eval/exec, subprocess shell=True, pickle.loads |
Also |
|
Sample output:
## [CRITICAL] SQL built via template literal
Category: security | Severity: critical | Count: 2
Fix: db.query('SELECT * FROM users WHERE id = $1', [userId])
Files:
- src/db/users.ts:47
- src/api/search.ts:23
Live fix: OWASP SQL Injection Prevention Cheat Sheetgt_auto_scanPoint it at a project root. It reads the manifest and lockfile, works out which libraries you use and at which versions, and returns best practices for each, top libraries first. Default output is about 15K characters.
Reads package.json, deno.json, requirements.txt, pyproject.toml, Cargo.toml, go.mod, pom.xml, build.gradle, build.gradle.kts, composer.json, Gemfile and pubspec.yaml.
gt_searchFor anything that isn't one library.
Area | Topics |
Security | OWASP Top 10, SQL injection, XSS / CSP, CSRF, HSTS, CORS, JWT, OAuth 2.1, WebAuthn, SSRF, API security |
Accessibility | WCAG 2.2, WAI-ARIA, keyboard navigation |
Performance | Core Web Vitals, image optimization, web fonts, Speculation Rules |
Web APIs | Fetch, Workers, WebSocket, WebRTC, IndexedDB, Web Crypto, Intersection Observer |
CSS | Grid, Flexbox, Container Queries, View Transitions, Cascade Layers, :has(), Subgrid |
AI providers | Claude, OpenAI, Gemini, Mistral, Cohere, Groq, LangChain, LlamaIndex |
Maps, Analytics, Ads, Cloud, Firebase, Vertex AI, YouTube, Gmail, Sheets | |
Infrastructure | Docker, Kubernetes, GitHub Actions, Terraform, Cloudflare Workers |
gt-mcp <command> runs the same 14 tools in-process and prints the answer. With no arguments, gt-mcp is the stdio MCP server, exactly as before.
gt-mcp docs react useEffect # live docs for one topic
gt-mcp bp nextjs caching # best practices
gt-mcp search "OWASP SSRF prevention"
gt-mcp audit . # audit the current project
gt-mcp scan . # best practices for every dependency
gt-mcp compat "CSS container queries"
gt-mcp ask "how do I paginate with drizzle" # let gt_dispatch pick the tool
gt-mcp call gt_compare '{"libraries":["prisma","drizzle-orm"]}'
echo '{"libraryName":"drizzle"}' | gt-mcp call gt_resolve_library -Command | Does |
| Lists every command, its tool and its arguments ( |
| Calls any tool with JSON arguments; |
| Shows a command's flags, generated from the tool's input schema |
| Prints the full |
Exit codes: 0 ok, 1 tool error, 2 usage error. Logs stay quiet on stderr unless something goes wrong (GT_LOG_LEVEL defaults to warn for commands). The server flags still work: --version, --health, --routing-table, --help.
Measured on one machine with the same harness, published 7.5.0 against 8.0.0. Network timings depend on your connection and on the docs site.
Measurement | 7.5.0 | 8.0.0 | Change |
| 1,130 ms, 194 MB | 40 ms, 54 MB | 28x faster |
Spawn to MCP ready | 1,074 ms | 186 ms | 5.8x faster |
| 6,893 ms | 259 ms | 27x faster |
Same call the next day (20 h old cache) | 6,684 ms | 92 ms | 73x faster |
Repeat | 86 ms | 2 ms | 43x faster |
Fewer tokens per session and per answer:
Measurement | 7.5.0 | 8.0.0 |
| 23,638 bytes | 11,560 bytes (-51%) |
Tool descriptions | -75% | |
Wire bytes per docs or best-practices answer | halved (duplicate | |
| ~60K characters | ~15K characters |
| 2.7K characters | 0.9K characters |
More of the answer reaches the model in clients that display structuredContent instead of the text:
Tool | 7.5.0 | 8.0.0 |
| 220 characters | the full support table |
| 142 characters | 3.5K characters |
Where the time went: the binary is a small bootstrap that loads the server lazily and uses the Node compile cache; docs pages are requested as markdown; the reader service is only a fallback; and cached pages are served stale-while-revalidate. A page up to 7 days old is returned at once and refreshed in the background.
Resolve. The library name is matched against the curated registry, then npm, PyPI, crates.io and Go modules.
Cache. An in-memory LRU, bounded by entry count and by characters, then the disk cache in ~/.gt-mcp-cache.
Fetch. Sources are tried in order and the first useful one wins:
llms.txt / llms-full.txt, the files maintainers publish for LLMs. A nested llms.txt resolves to the library's own index.
The docs page as markdown, via Accept: text/markdown content negotiation where the site supports it. The Next.js caching page is 715 KB as HTML and 16 KB as markdown.
The HTML page, converted to markdown directly.
GitHub: README, docs files, releases. GitHub-hosted libraries read their own README, not GitHub's site-wide llms.txt.
The Jina reader, as a hedged fallback that starts after 1.5 s or after a direct fetch fails.
Sanitize. Prompt-injection filter, SSRF guard, navigation and boilerplate stripped.
Rank. BM25 scores each section against the topic and fills the token budget with the ones that mention it.
Check. The evidence gate (below) decides whether the answer covers the topic.
Answer. Ranked excerpts with source URLs, fetch date and topic coverage.
The fetch layer keeps connections alive for 60 s, shares one in-flight request between identical callers, honours per-call cancellation and the GT_TOOL_TIMEOUT_MS deadline, caches 404s and oversized bodies so they are not retried, and skips a host for a while after repeated failures.
The failure mode of every docs tool is the confident non-answer: you ask about row-level security, the tool hands back the Postgres landing page, and your model writes something plausible from it.
GroundTruth checks the content it fetched against the question before returning it. The check counts how many of your topic's terms appear, how often, and whether they show up in a heading or inside a code block. Link targets and URL query strings don't count, so a 404 page whose navigation happens to contain your topic doesn't pass.
Weak coverage triggers a second, topic-targeted fetch instead of shipping the first page that loaded.
Zero coverage returns an explicit miss. You get the sources that were checked, an outline of what those pages do cover, and what to try next. Treat it as a true negative.
Every successful answer ends with an ## Evidence footer: source URLs, fetch date and topic-coverage numbers, so you can check where it came from.
The check is synonym-aware: an rls query is satisfied by a page that says "row level security", and a page found by expanding "migration" to "upgrade guide" isn't failed for lacking the literal word.
Accuracy, 7.5.0 against 8.0.0:
Check | 7.5.0 | 8.0.0 |
False library detections on a 212-query generic corpus | 94 | 0 |
Correct detections on a library corpus | 217 of 217 | |
Live 23-check matrix across all 14 tools | 17 of 23 | 23 of 23 |
Both routing corpora run in the test suite.
793 curated libraries across 21 language ecosystems, plus automatic fallback to npm, PyPI, crates.io and Go modules for anything outside the registry.
Release 8.0.0 adds 195 libraries: Python, data and AI tooling, Java, Kotlin and Spring, .NET, Go, Rust, Ruby, PHP, Swift, Dart and Flutter, Elixir, C and C++, infrastructure, databases, observability and more JavaScript and TypeScript. Every one of the 598 existing entries was probed live: 35 broken docs roots fixed, 115 moved docs sites updated, about 190 verified llms.txt indexes added. The curated URL tables (2,638 URLs) were re-checked.
Ecosystem | Examples |
JavaScript / TypeScript | Next.js, React, Tailwind CSS, shadcn/ui, TanStack Query, Zustand, Hono, NestJS, tRPC, Vite, Vitest, Playwright |
Python | Django, FastAPI, Flask, Pydantic, SQLAlchemy, Celery, NumPy, Pandas, Polars, PyTorch, scikit-learn |
Java / Kotlin | Spring Boot, Hibernate, Quarkus, Micronaut, Ktor, Jetpack Compose, JUnit, Mockito |
.NET | ASP.NET Core, Entity Framework Core, .NET MAUI, xUnit.net, Serilog |
Go / Rust | Gin, Echo, Fiber, GORM, Tokio, Axum, Actix Web, Serde, sqlx |
Ruby / PHP / Elixir | Ruby on Rails, Sidekiq, RSpec, Laravel, Livewire, Symfony, Phoenix, Ecto, Oban |
Mobile | Flutter, Riverpod, SwiftUI, Alamofire, React Native, Expo |
C / C++ | CMake, Clang / LLVM, OpenCV, gRPC |
Databases | PostgreSQL, Redis, MongoDB, SQLite, ClickHouse, Elasticsearch, Prisma, Drizzle ORM |
Infrastructure | Docker, Kubernetes, Helm, Terraform, Pulumi, Ansible, Cloudflare Workers |
Observability | OpenTelemetry, Prometheus, Grafana, Grafana Loki, Sentry |
AI | Claude API, OpenAI SDK, Gemini API, Vercel AI SDK, LangChain Python, HuggingFace Transformers |
The full list is the registry source: src/sources/registry.ts.
GroundTruth fetches untrusted web content and hands it to a model, so the fetch path is hardened:
SSRF guard blocks private, loopback, link-local and ULA ranges, on redirects too. IP-literal URLs are checked against the full blocklist, including cloud metadata at 100.100.100.200 and fd00:ec2::254, NAT64 and 6to4.
Prompt-injection sanitizer decodes HTML entities and strips zero-width and bidi characters before scanning, then redacts the exact matching span using an offset map. It is best-effort pattern redaction; treat fetched docs as untrusted input.
Tokens stay on their origin. GT_GITHUB_TOKEN and GT_JINA_API_KEY are never forwarded to another origin, including on redirects.
Audit patterns are ReDoS-safe. The worst-case input went from 9.5 s to 1 ms.
HTTP mode binds 127.0.0.1 by default, validates Host and Origin, and compares the bearer token in constant time.
No user data on disk. The disk cache holds fetched documentation under hashed keys, not prompts or tool inputs.
Report vulnerabilities privately through GitHub Security Advisories. Scope and threat model: SECURITY.md.
Set GT_HTTP_PORT and GroundTruth serves Streamable HTTP instead of stdio. It speaks MCP spec 2026-07-28 and still serves 2025-era clients.
Path | Purpose |
| MCP endpoint (POST, GET, DELETE) |
| Health JSON, including a cache-directory check |
| Prometheus metrics |
Local, loopback only:
GT_HTTP_PORT=3100 npx -y @groundtruth-mcp/gt-mcp@latestIt binds 127.0.0.1. Without GT_AUTH_TOKEN it starts open to local callers and logs a warning. With a token, every path, /health and /metrics included, needs Authorization: Bearer <token>.
Docker:
docker build -t gt-mcp .
export GT_AUTH_TOKEN="$(openssl rand -hex 32)"
docker run -d --name gt -p 127.0.0.1:3100:3100 -e GT_AUTH_TOKEN gt-mcp
claude mcp add --transport http gt http://localhost:3100/mcp --header "Authorization: Bearer $GT_AUTH_TOKEN"The image is 277 MB, runs as the unprivileged gt user, and binds 0.0.0.0 inside the container, so it refuses to start without GT_AUTH_TOKEN. Its healthcheck sends the token. The -p 127.0.0.1: prefix keeps the port on the host's loopback; drop it to serve other machines.
Behind a reverse proxy: the server speaks plain HTTP. Terminate TLS at the proxy and add the public hostname to GT_HTTP_ALLOWED_HOSTS, otherwise requests carrying it get 403. On a non-loopback bind the server will not start without GT_AUTH_TOKEN.
Sessions: stateless by default. GT_HTTP_STATEFUL=1 gives each 2025-era client its own session, closed after 30 minutes without a request.
An authenticated caller can make the server fetch public URLs and run gt_audit and gt_auto_scan on any directory the process can read. Don't mount anything into the container you wouldn't want read.
Everything is optional. Invalid numeric or enum values fail at startup instead of falling back silently.
Variable | Default | Purpose |
| unset | Serve MCP over Streamable HTTP on this port instead of stdio |
|
| HTTP bind address; any non-loopback address needs |
| unset | Comma-separated extra |
| unset |
|
| unset | Bearer token required on |
| unset | GitHub API token: 5,000 requests per hour instead of 60, enables |
| unset | Jina reader key, lifts page rendering off the anonymous rate limit |
|
| Disk cache directory |
|
| Default cache lifetime |
|
| How long past expiry a cached page may still be served |
|
| Default answer size in tokens |
|
| Largest |
|
| Deadline per tool call |
|
| Timeout per outbound HTTP request |
|
| Outbound requests in flight at once |
|
| Parallel library fetches in |
|
| Linked pages read when the first page misses the topic |
|
| First-page topic relevance (0-1) that skips the deep fetch |
|
| Time budget for one deep fetch |
|
| Consecutive failures before a host is skipped |
|
| How long a failing host is skipped |
|
|
|
|
|
|
| unset |
|
| unset |
|
| unset |
|
gt-mcp --help prints the same list.
8.0.0 has four breaking changes. Stdio users on Node 24 or newer who read the text content are not affected by any of them.
Change | What to do |
HTTP mode binds | To expose it, set |
Requests with a foreign | Add your public hostname to |
Prose tools no longer return | Read the text content; it carries the full answer. |
Node.js 24 or newer | Upgrade Node. |
Also new under the hood: the MCP TypeScript SDK v2 (@modelcontextprotocol/server), tools/list cache hints, and a fixed HTTP mode (7.5.0 answered only the first HTTP request). Production dependencies went from 169 packages (27 MB) to 13 (7.7 MB), and the Docker image from 566 MB to 277 MB. Full list: CHANGELOG.md.
Context7 is a good product. The differences:
GroundTruth | Context7 | |
Hosting | Self-hosted (stdio) + HTTP mode | Cloud backend, local MCP client |
Rate limits | None | 1,000 free/month ($10/seat for 5,000) |
Transport | Stdio + Streamable HTTP | Stdio + Streamable HTTP |
Source priority | llms.txt, markdown docs, HTML, GitHub, reader fallback, fetched at query time | Vector DB with proprietary crawl pipeline |
Answer verification | Evidence gate on every topic query; explicit miss when unverifiable | No |
Tools | 14 specialized tools | 2 tools |
Code audit | 107+ patterns, 18 categories, file:line, live fixes | No |
Freeform search | OWASP, MDN, AI docs, Google APIs, web standards | Library docs only |
Changelog, compat, compare, examples, migration | Yes | No |
MCP Resources + Prompts | 2 resources, 8 prompts | No |
Lockfile detection | Reads exact versions from lockfiles | No |
Libraries | 793+ curated + npm/PyPI/crates.io/Go fallback | Undisclosed (claims "thousands") |
API key required | No | No |
Context7 indexes docs into a vector database, which is fast but lags behind new releases. GroundTruth fetches from the source at query time and tells the model when it found nothing on the topic.
Adding a library is a pull request to src/sources/registry.ts with id, name, docsUrl, and llmsTxtUrl if the project publishes one.
pnpm install
pnpm typecheck
pnpm test # 2063 tests across 267 files
pnpm buildCI runs the suite on Node 24 and 26. Issues and requests: github.com/rm-rf-prod/GroundTruth-MCP/issues.
What | Where |
Tool schemas and parameters |
|
Complete library list | |
Audit rules, 18 categories | |
Routing table |
|
Health, telemetry, circuit-breaker state |
|
Release history |
Elastic License 2.0. Free to use, self-host and build on. The one thing you can't do is offer it as a managed service.
Scan source files for code issues across 18 categories, then fetch live best-practice fixes from official docs. Returns file:line locations. Unlike gt_auto_scan (best practices for your dependencies), this audits YOUR OWN source code.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tokens | No | Max tokens per best-practice fetch | |
| maxFiles | No | Max source files to scan | |
| categories | No | Issue categories to audit. Use "all" for broad questions. Default: all. Available: layout, performance, accessibility, security, react, nextjs, typescript, node, python, vue, svelte, angular, testing, mobile, api, css, seo, i18n. | |
| projectPath | No | Project directory. Defaults to current working directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that audit patterns run locally and only fix guidance fetch requires network, along with token requirement. This adds useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with core function and sibling distinction. It is well-organized but somewhat verbose, containing repeated enumeration of categories. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (18 categories, multiple use cases), the description covers return format (file:line), error handling (token issue), and usage guidance. No output schema, but the return description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description enriches the categories parameter with example combinations for mobile and web apps. For tokens and maxFiles, description doesn't add much beyond schema, but overall it compensates adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans source files for code issues across 18 categories and fetches best-practice fixes. It distinguishes from sibling gt_auto_scan by specifying that this tool audits the user's own source code, while the sibling audits dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use specific category combinations (e.g., for mobile apps, web apps, broad questions). Also mentions troubleshooting for failed doc fetches (GT_GITHUB_TOKEN). However, it does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Fetches best practices for your installed DEPENDENCIES — to scan your own source code for issues, use gt_audit instead. Unrecognized dependencies are listed separately, never fail the call.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | What to look up for each detected dependency. Examples: 'latest best practices', 'security', 'performance', 'migration'. Leave empty for general best practices. | |
| projectPath | No | Absolute path to the project directory. Defaults to current working directory. The tool will read package.json, requirements.txt, Cargo.toml, go.mod, etc. | |
| tokensPerLib | No | Max tokens per library (default: 1500). Lower = more libraries covered. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and not destructive. The description adds context: reads specific config files, fetches best practices for dependencies, lists unrecognized dependencies separately. No contradiction. Could mention output format or rate limits but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences: purpose, file list, usage alternative, edge case. Each sentence adds value. Front-loaded with the core action. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what files are read, what happens with dependencies, how to invoke, alternative tool, and edge case. No output schema, but description gives enough for an agent to understand the tool's behavior. Could mention return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 3 parameters have descriptions in schema (100% coverage). Description adds little beyond the schema descriptions, only implicitly connecting projectPath to file reading. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Automatically detect all dependencies in a project and fetch latest best practices for each', and specifically distinguishes from sibling 'gt_audit' by directing source code scanning to that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this tool for dependency scanning and best practices, and provides an alternative: 'to scan your own source code for issues, use gt_audit instead'. Also notes that unrecognized dependencies are listed separately and never fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| libraryNames | Yes | Array of library names to resolve (max 20). Example: ['react', 'next', 'tailwind'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint etc. Description adds: 'Max 20 per call', 'Registry-only lookup — no external npm/PyPI/crates fallback', and 'Returns results for each library.' No contradictions. Minor gap: no mention of error handling or partial results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: first states action and key constraints, second provides usage context. Front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, description covers purpose, constraints, usage, and alternatives. Lacks detailed output structure (e.g., keys returned), but no output schema exists. Nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description and example. Description restates max 20 but adds no new semantic info beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly: 'Resolve multiple library names to IDs and docs URLs in a single call.' Distinguishes from sibling tools gt_resolve_library (single with external fallback) and gt_auto_scan (scanning project files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when you already have a list of library names and need to batch-resolve them to IDs efficiently' and points to alternatives: gt_resolve_library for single with external fallback, gt_auto_scan for project scanning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Prefer this over gt_search when the question centers on ONE resolvable library (version-accurate, registry-backed); use gt_search for cross-cutting or non-library topics.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Specific area: 'performance', 'security', 'testing', 'deployment', 'migration', 'patterns', 'v4 migration'. Leave empty for general best practices. | |
| tokens | No | Max tokens to return | |
| version | No | Version to scope results to, e.g. '14', '3.0.3'. Focuses extraction on version-specific patterns. | |
| libraryId | Yes | Library ID (from gt_resolve_library), npm:package, pypi:package, or library name like 'nextjs', 'react' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds important context: proprietary registry, usage restrictions, enumeration prohibition, and call limit. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured, front-loaded with purpose, then usage guidance, then important notice. Every sentence is necessary and contributes to clarity. Concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete description given rich annotations and schema coverage. Covers purpose, usage, behavioral constraints, and parameter details. No missing essential information for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all 4 parameters. Description adds value by explaining libraryId sources (gt_resolve_library, npm:pypi), enhancing schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches best practices, patterns, and guidelines for a library/framework, targeting specific doc types. Explicitly distinguishes from generic reference docs and siblings like gt_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use versus gt_search: use for one resolvable library, gt_search for cross-cutting topics. Also includes call limit and proprietary data notice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| tokens | No | Max tokens for content | |
| version | No | Filter to a specific version prefix, e.g. '15' or 'v15.2.0' | |
| libraryId | Yes | Library ID from gt_resolve_library, e.g. 'vercel/next.js' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by detailing the fallback order (GitHub Releases -> CHANGELOG.md -> docs site), which is useful behavioral context. However, it does not mention potential gaps (e.g., if all sources fail).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose+method, usage, sibling differentiation. No extraneous information, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a read-only tool with clear usage and sibling differentiation. It lacks explicit mention of output format (likely plain text/markdown) but the tokens parameter implies content. Annotations cover safety. Minor gap but overall solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for all three parameters. The description does not add significant new meaning beyond the schema; it merely repeats examples already present. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool fetches release notes and changelog for a library, with a clear verb ('Fetch') and resource ('library'). It distinguishes itself from the sibling tool gt_migration by specifying its scope (changelog vs. migration steps).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use before upgrading' and 'Use this for "what changed in version X" questions.' It explicitly tells when NOT to use it and directs to gt_migration for migration-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tokens | No | Max tokens per library (2000 default) | |
| criteria | No | Comparison angle: 'performance', 'TypeScript support', 'bundle size', 'DX' | |
| libraries | Yes | 2–3 library names to compare, e.g. ['prisma', 'drizzle-orm'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it fetches live documentation and resolves library names internally, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise: two sentences plus a short paragraph. Front-loaded with purpose, then guidelines, then clarification. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and rich annotations, the description is complete. It explains what the tool does, how to use it, and when to use alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, description adds value by specifying that library NAMES (not IDs) should be passed, and gives example criteria values, enhancing understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares 2–3 libraries side-by-side, fetches live documentation, and presents content relevant to criteria. It distinguishes itself from sibling tool gt_get_docs which fetches docs for a single library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'Use for X vs Y or which library should I choose questions.' Also provides alternative: 'For fetching docs about a single library, use gt_get_docs instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tokens | No | Max tokens for content | |
| feature | Yes | Feature to check: 'CSS container queries', 'Array.at()', 'fetch() browser support', 'WebAssembly' | |
| environments | No | Environments to focus on, e.g. ['chrome', 'firefox', 'safari', 'node', 'deno'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds that it fetches live data from MDN Web Docs and caniuse.com, providing transparency about external dependencies and dynamic results. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a clear purpose: stating the tool's function, providing usage examples and alternatives, and reinforcing the feature string requirement. It is concise, well-structured, and free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the combination of description and schema provides comprehensive guidance. All parameters are described, the data sources are mentioned, and usage examples are given. No additional information is necessary for effective use, though an output format note would be a minor enhancement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all parameters with 100% coverage. The description adds the critical clarification that the 'feature' parameter expects a feature string, not a library name, which enhances understanding beyond the schema. This additional semantic guidance justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as checking browser and runtime compatibility for web APIs, CSS, and JS syntax. It uses specific verbs and resources and distinguishes itself from siblings like gt_get_docs and gt_best_practices by stating it is for feature-level compatibility queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (questions about browser/runtime support) and when not to (general library docs or best practices). It provides example queries and names alternative tools for different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Plain-text user intent. Examples: 'use gt for react', 'find issues', 'migrate next from 14 to 15', 'best practices for fastapi'. | |
| projectPath | No | Optional project directory for project-level intents (auto-scan, audit). Defaults to current working directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, non-destructive, idempotent, and closed-world hints. The description adds behavioral context: output includes routing decision with confidence, tool name, args, and an embedded routing table for next-step calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, examples, and no superfluous text. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role as a dispatcher, the description, annotations, and schema together provide complete context: purpose, usage boundaries, parameter behavior, and output expectations (no output schema needed due to textual description).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds query examples and optional nature of projectPath, but the schema already describes parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it routes plain-text queries to the correct gt_* tool, with specific examples. It distinguishes from sibling tools by positioning itself as a single entry point when the target is unknown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections clearly state when to use this dispatcher vs. calling a specific sibling directly, including example phrasings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| library | Yes | Library or package name to find examples for, e.g. 'drizzle-orm', 'tanstack/query', 'fastapi' | |
| pattern | No | Specific usage pattern to search for, e.g. 'middleware', 'useMutation', 'auth guard' | |
| language | No | Programming language filter: 'typescript', 'python', 'rust', 'go' | |
| maxResults | No | Number of code examples to return (default: 5, max: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds important context: requires GT_GITHUB_TOKEN for higher rate limits and clarifies the source as open-source repositories, complementing annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no fluff. It front-loads the purpose, then covers authentication, usage context, and alternatives efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 well-documented parameters, comprehensive annotations, and no output schema, the description covers purpose, when to use, auth, and source. It could mention return format (code snippets with attribution) but that is implicit. Overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description does not add additional parameter-level details beyond what the schema provides, but it does mention the token requirement as a behavioral note. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search GitHub for real-world usage examples' with specific verb and resource, and distinguishes itself from sibling tool gt_snippets by noting the source of examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when you want to see how real projects use a library' and provides an alternative: 'For code snippets extracted from the library's own documentation, use gt_snippets instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
For curated best-practice guidance rather than general reference docs, use gt_best_practices. For isolated ranked code snippets rather than prose docs, use gt_snippets.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | What you need to learn or do. Examples: 'routing', 'authentication', 'middleware', 'caching', 'streaming'. More specific = more relevant content returned. | |
| tokens | No | Max tokens to return (default: 8000, max: 20000) | |
| version | No | Version to fetch docs for, e.g. '14', '3.0.3', 'v2'. Tries GitHub tag and npm version page. | |
| libraryId | Yes | Library ID from gt_resolve_library (e.g. 'vercel/next.js', 'npm:express') or a docs URL | |
| projectPath | No | Absolute project path. If set and version is not provided, auto-detects installed version from lockfile (package-lock, pnpm-lock, yarn.lock, Cargo.lock, poetry.lock, uv.lock). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint false) indicate safe, read-only behavior. The description adds details about document source prioritization (llms.txt, Jina Reader, GitHub README) and a proprietary data restriction, enhancing transparency without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, but slightly lengthy. It could be condensed by removing the notice about proprietary data, but overall it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, no output schema), the description covers prerequisites, source priority, usage limits, and restrictions. It lacks return format details, but that is acceptable without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have schema descriptions (100% coverage). The description adds value by explaining the libraryId prerequisite, version auto-detection via projectPath, and the topic's role in relevance, beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches documentation for any library/framework, specifies the prerequisite step (calling gt_resolve_library), and distinguishes from sibling tools (gt_best_practices, gt_snippets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use (after gt_resolve_library), when not to (for best practices or snippets, suggests alternatives), and imposes a usage limit ('Do not call this tool more than 3 times per question').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tokens | No | Max tokens to return | |
| libraryId | Yes | Library ID from gt_resolve_library (e.g. 'vercel/next.js') | |
| toVersion | No | Version migrating to, e.g. '15', 'v4.0' | |
| fromVersion | No | Version migrating from, e.g. '14', 'v3.0' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to cover safety. It adds behavioral context by specifying the types of documents it targets (MIGRATION.md, CHANGELOG, etc.), which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: what it does, prerequisite, and when to use vs alternative. No redundancy, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4-parameter input schema with 100% coverage and comprehensive annotations, the description covers all necessary context: what it retrieves, prerequisite, and differentiation from sibling. No output schema needed as the description clarifies the return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so schema already documents all parameters. The description adds value by explaining that libraryId comes from gt_resolve_library and reinforces the version parameters. This provides contextual meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches migration guides, breaking changes, and upgrade instructions for a library, specifying target files like MIGRATION.md. It distinguishes from sibling tool gt_changelog, which is for release notes without upgrade instructions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when user asks HOW to upgrade step-by-step. Also provides a clear exclusion: for release notes without upgrade instructions, use gt_changelog instead. Includes prerequisite to call gt_resolve_library first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a package/product name to a Context7-compatible library ID and returns matching libraries.
You MUST call this function before gt_get_docs 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. For 2-20 libraries at once, use gt_batch_resolve instead.
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:
Analyze the query to understand which library/package the user wants
Pick the result with the highest score; on ties prefer source 'registry', then results that expose an llmsTxtUrl/llmsFullTxtUrl
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional: what you want to do with this library, used to rank results | |
| libraryName | Yes | Library or framework name to look up. Examples: 'nextjs', 'react', 'tailwind', 'fastapi', 'drizzle' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds significant context: response fields, selection process, proprietary data notice, and usage restrictions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy and includes multiple sections. While well-organized, it could be more concise; some details like the selection process and proprietary notice are verbose but valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains return fields, selection logic, and limitations. Covers input, output, and constraints comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with clear descriptions. Description adds examples for libraryName, explains query's purpose for ranking, and details response fields, greatly enriching parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a package/product name to a Context7-compatible library ID, with specific verb and resource. It distinguishes from sibling tools like gt_batch_resolve and gt_get_docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call (before gt_get_docs unless user provides ID), when not to (user provides ID or 2-20 libraries), and includes a max call limit of 3 per question. Provides a clear selection process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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
If the query names ONE specific library, prefer gt_resolve_library + gt_get_docs/gt_best_practices for version-accurate, registry-backed results — use gt_search for standards, cross-cutting topics, or when no library applies. For browser/runtime feature support use gt_compat; for GitHub code examples use gt_examples.
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" })
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What you want to know. Can be anything: 'latest React best practices', 'WCAG 2.2 focus indicators', 'OWASP SQL injection prevention', 'CSS container queries browser support', 'JWT security', 'HTTP/3 vs HTTP/2', 'Web Workers API'. No library name required. | |
| tokens | No | Max tokens to return (default: 8000, max: 20000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description adds that searches are normalized to 2026 content and auto-detects from project context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and examples, though slightly lengthy. It could be trimmed without losing value, but it remains clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a general search tool with no output schema, the description covers purpose, usage, alternatives, behavioral traits, and examples comprehensively. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage; the description adds examples and usage context but does not significantly extend meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for searching any topic without needing a library name. It lists numerous examples across domains and explicitly distinguishes from siblings like gt_resolve_library, gt_compat, and gt_examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs alternatives: if a specific library is named, prefer gt_resolve_library + gt_get_docs/gt_best_practices; for browser/runtime features use gt_compat; for GitHub code examples use gt_examples. This covers when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. An explicit version overrides projectPath lockfile auto-detection. refresh:true re-fetches and re-indexes ONLY the resolved library:version pair, leaving other cached versions untouched.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic to filter snippets by. Examples: 'middleware', 'server actions', 'rate limiting'. Empty = all snippets. | |
| refresh | No | Skip cache and refetch + reindex snippets | |
| version | No | Version to pin docs to, e.g. '15', 'v4.0.0'. Caches snippet index per version. | |
| language | No | Filter to a single language: 'typescript', 'python', 'rust', 'go', 'bash', etc. | |
| libraryId | Yes | Library ID from gt_resolve_library (e.g. 'vercel/next.js', 'npm:express') or a direct docs URL | |
| maxSnippets | No | Max snippets to return (default 10, max 30) | |
| projectPath | No | Absolute project path. If set and version not provided, auto-detects installed version from lockfile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, non-destructive. Description adds significant context: first-call indexing, disk cache, source prioritization (llms.txt > Jina > README), refresh behavior, proprietary data notice. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat long but every sentence is informative. Front-loaded with purpose then usage details. Minor redundancy could be trimmed (e.g., 'IMPORTANT — PROPRIETARY DATA NOTICE' is important but adds length). Overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet description explains output format (Context7-compat with title, description, language, code, source URL). Covers caching, refresh, version detection, proprietary notice, and source prioritization. Fully adequate for a complex tool with 7 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have schema descriptions (100% coverage). The description adds extra context beyond schema: e.g., 'An explicit version overrides projectPath lockfile auto-detection' and 'refresh:true re-fetches and re-indexes ONLY the resolved library:version pair'. Adds meaningful value but not 5 due to already rich schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns ranked code snippets for a library and optional topic, with specific verb 'Return' and resource 'ranked code snippets'. It distinguishes from sibling tools gt_examples (real projects) and gt_get_docs (full pages), making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use ('focused code examples rather than full doc pages') and when not ('use gt_examples instead'). Also details caching behavior, refresh, and version auto-detection, providing clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v7.0.1gt_changelog1 field changedInput schema / properties / version / descriptionPrevious value: -"Filter to a specific version prefix, e.g. '15' or 'v15.1.0'"New value: +"Filter to a specific version prefix, e.g. '15' or 'v15.2.0'"gt_dispatchgt_get_docs1 field changedInput schema / properties / projectPathAdded value: +{
+ "description": "Absolute project path. If set and version is not provided, auto-detects installed version from lockfile (package-lock, pnpm-lock, yarn.lock, Cargo.lock, poetry.lock, uv.lock).",
+ "maxLength": 500,
+ "type": "string"
+}gt_snippetsv5.2.0gt_auditgt_auto_scangt_batch_resolvegt_best_practicesgt_changeloggt_comparegt_compatgt_examplesgt_get_docsgt_migrationgt_resolve_librarygt_searchScored across 14 tools
Most tools are clearly distinct in purpose, and descriptions cross-reference each other with explicit routing guidance (e.g., gt_best_practices vs gt_search vs gt_best_practices, gt_snippets vs gt_examples). However, some adjacent retrieval tools like gt_snippets and gt_examples or gt_get_docs and gt_best_practices could still be confused by an agent on a first pass, though the descriptions mitigate this.
The set is highly uniform at a surface level: every tool uses the lowercase gt_ prefix and snake_case. The deviation is that the part after the prefix mixes verbs (search, dispatch, audit, get, resolve, compare) with nouns (changelog, examples, snippets, compatibility), so while not chaotic, it is not a single verb_noun pattern throughout.
At 14 tools, the server sits near the upper end of the ideal 3-15 range but not beyond it. Each tool has a reasonable justification; the convenience router and batch resolution add overhead without being pure duplication. Overall the count feels slightly heavy but appropriate for a broad classification assistant.
For a documentation and best-practices retrieval server, the tool surface is remarkably complete: library resolution, batch resolution, plain docs, best practices, snippets, examples, compatibility checks, migration guides, changelogs, comparisons, project dependency scanning, and source auditing. No obvious gaps or dead ends like missing coverage of upgrade or use which tool flows.
An MCP server that gives your AI access to the source code and docs of all public github repos
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
