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.
Your model doesn't know that React 19 killed forwardRef, that Next.js made cookies() async, or that Tailwind v4 nuked @tailwind directives. It writes deprecated patterns with full confidence. It hands you SQL injection dressed up as a query builder and uses any in TypeScript like it's a feature.
GroundTruth runs on your machine. Fetches docs from the source — llms.txt, Jina Reader, GitHub — right when you ask. 598+ curated libraries, plus npm, PyPI, crates.io, and pkg.go.dev as fallback. The audit tool reads your actual files, finds issues at exact file:line locations, and fetches the current fix from the real spec.
Related MCP server: docs-mcp
claude mcp add gt -- npx -y @groundtruth-mcp/gt-mcp@latestAdd to your MCP config (claude_desktop_config.json, .cursor/mcp.json, or .vscode/mcp.json):
{
"mcpServers": {
"gt": {
"command": "npx",
"args": ["-y", "@groundtruth-mcp/gt-mcp@latest"]
}
}
}No build step. No config file. Node.js 24+. Using @latest means npx pulls the newest version on every session start — you always get the latest libraries, audit patterns, and fixes without doing anything.
GroundTruth fetches README files, release notes, migration guides, and code examples from GitHub. Unauthenticated requests are limited to 60/hr. A token with no extra scopes takes it to 5,000/hr.
# Claude Code
claude mcp add gt -e GT_GITHUB_TOKEN=ghp_yourtoken -- npx -y @groundtruth-mcp/gt-mcp@latest
# Cursor / Claude Desktop / VS Code — add env to your config:
"env": { "GT_GITHUB_TOKEN": "ghp_yourtoken" }Fourteen tools. Each does one thing.
Tool | What it does |
| Find a library by name. Falls back to npm, PyPI, crates.io, pkg.go.dev |
| Fetch live docs for a specific topic |
| Patterns, anti-patterns, and config guidance for any library |
| Read your manifest, fetch best practices for every dependency |
| Search OWASP, MDN, web.dev, W3C, AI provider docs, Google APIs |
| Scan source files — issues at exact |
| Release notes before you upgrade |
| Browser and runtime compatibility via MDN + caniuse |
| Compare 2-3 libraries side-by-side |
| Real-world code examples from GitHub |
| Migration guides and breaking changes |
| Resolve up to 20 libraries in one call |
| Pre-indexed, ranked code snippets per library and version, cached on disk |
| Routes a plain-text query ("use gt mcp") to the right tool with args |
You don't need to memorize tool names. Just talk to your AI assistant.
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 gt
use gt for Google Gemini API
use gt for Claude tool useOr 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_audit — the one that finds what you missedWalks your project, runs 107+ patterns across 18 categories, pinpoints issues at file:line, then fetches fix guidance 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 |
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_scan — best practices for your whole stackPoint it at your project root. It reads the manifest, figures out what you're using, and pulls best practices for each dependency.
gt_auto_scan({ projectPath: "." })Supports package.json, requirements.txt, pyproject.toml, Cargo.toml, go.mod, pom.xml, build.gradle, and composer.json.
gt_search — anything that isn't a specific libraryCovers security, accessibility, performance, web APIs, CSS, HTTP, AI providers, Google APIs, infrastructure, databases, and more.
gt_search({ query: "WCAG 2.2 focus indicators" })
gt_search({ query: "Core Web Vitals LCP optimization" })
gt_search({ query: "Claude tool use best practices" })
gt_search({ query: "Google Gemini API function calling" })
gt_search({ query: "JWT vs session cookies" })
gt_search({ query: "gRPC vs REST tradeoffs" })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 |
For every request, GroundTruth tries sources in order and stops at the first one that returns useful content:
llms.txt / llms-full.txt — context files published by maintainers for LLM consumption
Jina Reader — converts docs pages to clean markdown, handles JS-rendered sites
GitHub README / releases — latest release notes and README
npm / PyPI / crates.io / pkg.go.dev — fallback for packages outside the curated registry
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 you asked before returning it. The check measures 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 — a 404 page whose nav links happen to contain your topic doesn't pass.
Three things follow from that:
Weak coverage triggers a second, topic-targeted fetch rather than 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, not a failure.
Every successful answer carries an ## Evidence footer — source URLs, fetch date, and topic-coverage stats — so you can audit where it came from.
Docs vocabulary rarely matches yours, so 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 then failed for lacking the literal word.
598+ curated entries with 100% best-practices and URL pattern coverage, plus automatic fallback to npm, PyPI, crates.io, and pkg.go.dev. Any public package in any major ecosystem is resolvable.
Ecosystem | Libraries |
React / Next.js | React, Next.js, shadcn/ui, Radix UI, Tailwind CSS, Headless UI |
State management | Zustand, Jotai, TanStack Query, SWR, Redux Toolkit, XState |
Backend (Node.js) | Express, Fastify, Hono, NestJS, Elysia, tRPC |
Backend (Python) | FastAPI, Django, Flask, Pydantic |
Backend (Go / Rust) | Gin, Fiber, GORM, Axum, Actix Web, Tokio |
Database / ORM | Prisma, Drizzle, Kysely, TypeORM, Supabase, Neon, Turso |
AI / LLM | Claude API, OpenAI API, Gemini API, Vercel AI SDK, LangChain, LlamaIndex |
Testing | Vitest, Playwright, Jest, Testing Library, Cypress, MSW |
Auth | Clerk, NextAuth, Better Auth, Lucia |
Mobile | Expo, React Native, React Navigation, NativeWind |
Build tools | Vite, Turbopack, SWC, Biome, ESLint, Turborepo |
Cloud | Vercel, Cloudflare Workers, AWS SDK, Firebase, Google Cloud |
Monitoring | Sentry, PostHog, OpenTelemetry |
The full curated list is the registry source itself: src/sources/registry.ts.
Context7 is solid. Here's why I reach for this instead.
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 -> Jina -> GitHub -> npm/PyPI | 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 | 598+ curated + npm/PyPI/crates.io/Go fallback | Undisclosed (claims "thousands") |
API key required | No | No |
Context7 indexes docs into a vector database — fast lookups, but with indexing lag on new releases. GroundTruth fetches from the source at query time, prioritizes llms.txt, and scores content quality so your model knows when to retry.
All optional. Works out of the box with zero configuration.
Variable | Purpose | Default |
| GitHub API auth — raises rate limit from 60 to 5,000 req/hr | none |
| Disk cache location for persistent cross-session caching |
|
| Parallel fetch limit in |
|
| Bearer token required for HTTP transport endpoints | none |
| Port to enable HTTP transport (otherwise stdio) | none |
| Set |
|
The public registry lives in src/sources/registry.ts. Adding a library is a PR with id, name, docsUrl, and llmsTxtUrl if the project publishes one.
Issues and requests: github.com/rm-rf-prod/GroundTruth-MCP/issues
GroundTruth is under active development. New curated registry entries, audit patterns, search topics, and features are added regularly. The registry covers 598+ libraries with 100% bestPracticesPaths and urlPatterns coverage. Automatic fallback to npm, PyPI, crates.io, and pkg.go.dev means any public package is resolvable out of the box.
To stay updated:
Star and watch the GitHub repo for release notifications
Use @latest in your MCP config (the default install command) — npx fetches the newest version automatically
Check tool responses — GroundTruth appends an update notice when a newer version is available
Every tool ships its own full schema and description — your MCP client lists them, and gt_dispatch explains which one it would pick for a given phrasing and why.
What | Where |
Tool schemas and parameter docs |
|
Complete library list | |
Audit rules — 107 patterns, 18 categories | |
Routing table |
|
Health, telemetry, circuit-breaker state |
|
Release history |
Elastic License 2.0 — free to use, free to self-host, free to build on. The one thing you can't do is turn it into a managed service and sell it. Fair enough.
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.
