What can you do with this server?

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.

Which integrations are available for this server?

Provides documentation and best practices for Biome formatting/linting.

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. 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.

de en es ja ko ru zh

ws-mcp

by rm-rf-prod

Overview Schema Related Servers Score Discussions

TypeScript

Local

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.

The problem

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: docpilot-mcp

Install

Claude Code

claude mcp add gt -- npx -y @groundtruth-mcp/gt-mcp@latest

Cursor / Claude Desktop / VS Code

Add 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.

Optional: GitHub token

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" }

What it does

Fourteen tools. Each does one thing.

Tool	What it does
`gt_resolve_library`	Find a library by name. Falls back to npm, PyPI, crates.io, pkg.go.dev
`gt_get_docs`	Fetch live docs for a specific topic
`gt_best_practices`	Patterns, anti-patterns, and config guidance for any library
`gt_auto_scan`	Read your manifest, fetch best practices for every dependency
`gt_search`	Search OWASP, MDN, web.dev, W3C, AI provider docs, Google APIs
`gt_audit`	Scan source files — issues at exact `file:line` with live fixes
`gt_changelog`	Release notes before you upgrade
`gt_compat`	Browser and runtime compatibility via MDN + caniuse
`gt_compare`	Compare 2-3 libraries side-by-side
`gt_examples`	Real-world code examples from GitHub
`gt_migration`	Migration guides and breaking changes
`gt_batch_resolve`	Resolve up to 20 libraries in one call
`gt_snippets`	Pre-indexed, ranked code snippets per library and version, cached on disk
`gt_dispatch`	Routes a plain-text query ("use gt mcp") to the right tool with args

How to use it

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 use

Or 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 missed

Walks 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 rules

Category	What it checks
`security`	XSS, SQL injection, command injection, SSRF, path traversal, hardcoded credentials, CORS wildcard
`accessibility`	Missing alt text, onClick on div, icon-only buttons, inputs without labels, `outline: none`
`react`	forwardRef (React 19), useFormState renamed, index as key, conditional hooks
`nextjs`	Sync cookies/headers/params (Next.js 16), Tailwind v3 directives, missing metadata
`typescript`	`any` type, non-null assertions, `@ts-ignore`, floating Promises
`performance`	Missing lazy loading, useEffect data fetching, missing Suspense boundaries
`layout`	CLS-causing images, 100vh on mobile, missing font-display
`node`	console.log in production, sync fs ops, unhandled callbacks
`python`	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 Sheet

`gt_auto_scan` — best practices for your whole stack

Point 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 library

Covers 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
Google	Maps, Analytics, Ads, Cloud, Firebase, Vertex AI, YouTube, Gmail, Sheets
Infrastructure	Docker, Kubernetes, GitHub Actions, Terraform, Cloudflare Workers

How docs are fetched

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

Evidence, not vibes

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.

Library coverage

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.

vs. Context7

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.

Environment variables

All optional. Works out of the box with zero configuration.

Variable	Purpose	Default
`GT_GITHUB_TOKEN`	GitHub API auth — raises rate limit from 60 to 5,000 req/hr	none
`GT_CACHE_DIR`	Disk cache location for persistent cross-session caching	`~/.gt-mcp-cache`
`GT_CONCURRENCY`	Parallel fetch limit in `gt_auto_scan`	`8`
`GT_AUTH_TOKEN`	Bearer token required for HTTP transport endpoints	none
`GT_HTTP_PORT`	Port to enable HTTP transport (otherwise stdio)	none
`GT_HTTP_STATEFUL`	Set `=1` for session-per-request HTTP mode	`0` (stateless)

Contributing

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

Active development

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

Reference

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	`tools/list` in any MCP client, or `src/tools/`
Complete library list	`src/sources/registry.ts`
Audit rules — 107 patterns, 18 categories	`src/sources/audit-patterns.ts`
Routing table	`npx @groundtruth-mcp/gt-mcp --routing-table`
Health, telemetry, circuit-breaker state	`npx @groundtruth-mcp/gt-mcp --health`, or `/health` in HTTP mode
Release history	CHANGELOG.md

Star history

License

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.

Available Tools

14 tools

gt_auditAudit Project CodeA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`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.

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. Description adds valuable context: audit patterns run locally, only fix guidance fetch requires network, and potential token issues. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with front-loaded purpose, sibling distinction, category list, usage examples, and troubleshooting. While slightly lengthy, each sentence adds value and the organization aids readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description specifies return type (file:line locations). Covers purpose, parameter semantics, usage guidance, and edge cases (token limits). Could mention more about output structure, but overall complete for an audit tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with descriptions. Description enriches parameters by listing all 18 categories plus 'all', showing usage patterns for mobile and web apps, explaining default behaviors (tokens, maxFiles, projectPath), and clarifying the token parameter's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it scans source files for issues across 18 categories and fetches live best-practice fixes, returning file:line locations. It explicitly distinguishes from sibling gt_auto_scan by specifying 'this audits YOUR OWN source code' vs dependencies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: contrasts with gt_auto_scan, gives recommended category combinations for mobile apps and web apps, and advises on GT_GITHUB_TOKEN troubleshooting when doc fetches fail.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gt_auto_scanAuto-Scan Project DependenciesA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`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.

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

gt_batch_resolveBatch Resolve LibrariesA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description	Default
`libraryNames`	Yes	Array of library names to resolve (max 20). Example: ['react', 'next', 'tailwind']

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide safety and idempotency hints. Description adds that it does registry-only lookup (no external fallback) and max 20 per call. This adds 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, front-loaded with action. No wasted words. Each sentence provides essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple parameter and rich annotations, the description covers purpose, usage, behavioral constraints, and context for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with description. Main description does not add significant meaning beyond the schema's example and constraints. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it resolves multiple library names to IDs and docs URLs in a single call. Distinguishes from siblings like gt_resolve_library (single with fallback) and gt_auto_scan (project scanning).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly specifies when to use (batch resolution before gt_get_docs) and when not to (single library: gt_resolve_library; project scanning: gt_auto_scan). Provides clear alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gt_best_practicesGet Best PracticesA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`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'

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: a proprietary data notice (licensed registry, non-extraction requirement) and a usage limit. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: purpose first, then usage guidelines, then an important notice, then a usage limit. Each sentence adds value, and the total length (~150 words) is appropriate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, no output schema, and no nested objects, the description covers usage guidelines, behavioral restrictions, and parameter context sufficiently. The proprietary notice adds necessary completeness for legal/compliance awareness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with descriptions for all 4 parameters. The description adds meaningful context beyond the schema, such as the possible formats for libraryId (from gt_resolve_library, npm:pypi:, or library name) and that topic can be left empty.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches best practices, patterns, and guidelines for a library or framework, targeting specific content types (best-practices pages, guides, migration docs, performance tips) while excluding generic reference docs. It distinguishes from the sibling tool gt_search by specifying when to use each.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises preferring this tool over gt_search when the question centers on one resolvable library, and using gt_search for cross-cutting or non-library topics. Also includes a hard usage limit of 3 calls per question, providing clear when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gt_changelogFetch Library ChangelogA

Read-onlyIdempotent

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).

ParametersJSON Schema

Name	Required	Description
`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'

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, destructiveHint, etc. Description adds behavioral detail on data source priority (GitHub Releases API first, then CHANGELOG.md, then docs site). 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise: two short paragraphs, front-loaded with purpose, no redundant words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, sources, usage context, sibling differentiation. No output schema, but description doesn't detail return format; however, given the tool's simplicity, it's adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description adds minimal extra meaning. It notes libraryId is from gt_resolve_library and version is a prefix filter, but schema already says that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Fetch recent release notes and changelog for a library' with specific verb and resource. Distinguishes from sibling tool gt_migration by mentioning alternative use case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use before upgrading' and gives when-to-use ('what changed in version X') and when-not-to-use ('how do I upgrade... use gt_migration instead').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gt_compareCompare Libraries Side-by-SideA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`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']

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, etc. The description adds that it fetches 'live documentation' and resolves internally, which provides context beyond annotations. Lacks details on how content is selected 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise paragraphs: first states core function, second gives usage guidance and alternative. Front-loaded with key action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description indicates it presents relevant content. Input constraints (2–3 libraries) are clear. Could mention output format but not required. Complete enough for a comparison tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters have schema descriptions (100% coverage), but the description adds valuable context: clarifies that 'libraries' must be names not IDs, provides exemplars, and explains token defaults and range.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool compares 2–3 libraries side-by-side by fetching live documentation. It distinguishes itself from the sibling tool 'gt_get_docs' by specifying that this tool is for comparisons, not single library docs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (e.g., 'X vs Y' questions) and when not to (use gt_get_docs instead). Provides clear guidance on input format (library names not registry IDs).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gt_compatCheck Browser/Runtime CompatibilityA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`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']

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate read-only, idempotent, and non-destructive behavior. Description adds that it 'Fetches live data', implying network usage and potentially changing results. No contradictions, but could mention rate limits or response format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise paragraphs: first explains purpose and data sources, second provides usage guidance and alternatives. No redundant information, well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, good annotations, and comprehensive schema, the description covers all necessary aspects: purpose, usage, and data sources. Could mention output format but not essential.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with detailed descriptions for each parameter. The description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title and description clearly state that the tool checks browser/runtime compatibility for web APIs, CSS, and JavaScript syntax. It specifies data sources (MDN, caniuse) and distinguishes it from sibling tools like gt_get_docs and gt_best_practices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'when the question is specifically about which browsers or runtimes support a feature' and what not to use for: 'not a library name'. Provides clear alternatives (gt_get_docs, gt_best_practices).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gt_dispatchGroundTruth DispatchA

Read-onlyIdempotent

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.

ParametersJSON Schema

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.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool outputs a routing decision (tool name, args, reason, confidence) and embeds a routing table, not executing the target tool. This provides 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (WHEN TO USE, WHEN NOT TO USE, OUTPUT) and front-loaded with the main action. It is slightly verbose but every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no output schema), the description adequately covers purpose, usage, output format, and examples. It could be more precise about the routing logic, but it is sufficient for an agent to understand and use the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with both parameters well-documented. The description reinforces with examples but does not add new semantics beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool routes plain-text user queries to the correct gt_* tool with right arguments, giving multiple examples. It explicitly distinguishes itself as a single entry point from sibling tools that are direct calls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes explicit 'WHEN TO USE' (ambiguous intent, 'use gt' without tool) and 'WHEN NOT TO USE' (already know which tool), advising direct calls to save a round-trip. This provides clear decision criteria for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gt_examplesFind Real-World Code ExamplesA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`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)

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds valuable context beyond these: it requires a GT_GITHUB_TOKEN env var for higher rate limits (5000 req/hr vs 60 unauthenticated) and clarifies the data source is open-source GitHub repositories. It does not detail error handling when the token is missing, but overall it adds significant transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: two sentences in the first paragraph and two in the second. Every sentence adds value: purpose, differentiation from sibling, environment variable requirement, and source. No redundant or extraneous information. It is well-structured and front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (search over GitHub with rate limiting and library differentiation), the description covers all necessary context: what it does, when to use it, alternative tool, authentication/env var requirement, source of data, and a note on rate limits. Even without an output schema, the description provides enough for an agent to understand the tool's behavior and constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for all 4 parameters, so the baseline is 3. However, the description adds concrete examples for 'library' (e.g., 'drizzle-orm', 'fastapi') and 'pattern' (e.g., 'middleware', 'useMutation'), which help clarify the intended use of these parameters beyond the schema descriptions. This extra context justifies a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches GitHub for real-world usage examples of libraries or patterns, with specific verb 'Search' and resource 'GitHub'. It explicitly distinguishes itself from the sibling tool gt_snippets, which covers library's own documentation. The title 'Find Real-World Code Examples' also aligns well.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'Use this when you want to see how real projects use a library.' It also tells when not to use it by pointing to an alternative: 'For code snippets extracted from the library's own documentation, use gt_snippets instead.' This makes the usage context very clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gt_get_docsGet DocumentationA

Read-onlyIdempotent

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.

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

ParametersJSON Schema

Name	Required	Description
`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).

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses prioritization order (llms.txt, Jina Reader, GitHub README) and includes a proprietary data notice. Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false) are consistent and no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections (main purpose, alternatives, notice, limit). Slightly verbose but front-loaded and efficient overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all necessary aspects: prerequisite (resolve library), parameter details, fallback order, usage limits, proprietary notice. No gaps given high schema coverage and annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are well-documented. The description adds value by explaining how libraryId is obtained and how projectPath auto-detects version. Additional context beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Fetch up-to-date documentation for any library or framework' with specific verb and resource. It distinguishes from siblings (gt_best_practices, gt_snippets) by explaining when to use those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call gt_resolve_library first, provides context for alternatives, and includes a usage limit (no 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.

gt_migrationGet Migration GuideA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`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'

TDQS

A4.7/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

gt_resolve_libraryResolve LibraryA

Read-onlyIdempotent

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.

ParametersJSON Schema

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'

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey safe, idempotent, read-only behavior. The description adds valuable context: the 3-call-per-question limit and a proprietary data notice. This exceeds 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is comprehensive but lengthy, with sections that could be condensed. While well-structured, some parts (like the selection process and response format) are redundant with logical inference. It earns its place but is not optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity and absence of an output schema, the description is fully complete. It covers all necessary aspects: prerequisites, alternatives, selection logic, response format, and usage limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are well-described. The description reiterates the library name parameter and adds context about the query parameter's purpose, but does not significantly expand beyond schema details. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Resolve a package/product name to a Context7-compatible library ID and returns matching libraries.' It also explains its role relative to sibling tools like gt_get_docs and gt_batch_resolve, making it highly distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit usage guidance is provided: 'You MUST call this function before gt_get_docs...' and 'For 2-20 libraries at once, use gt_batch_resolve instead.' The selection process and response format are detailed, leaving no ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gt_searchSearch Any TopicA

Read-onlyIdempotent

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" })

ParametersJSON Schema

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)

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide read-only, open-world, idempotent hints. Description adds context: year normalization, auto-detection from project context, and token constraints. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with bullet points and headings. Front-loaded with main purpose. Slightly long but every sentence adds value. Could be tightened slightly, but highly functional.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Rich description covers purpose, usage guidelines, parameters with examples, and behavioral context. No output schema but annotations and schema cover remaining needs. Complete for a search tool with many use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with detailed descriptions for both 'query' and 'tokens'. Description reinforces 'query' with many examples but does not add new meaning beyond schema. Baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses 'Search for latest best practices, docs, or guidance on ANY topic' with specific verb 'Search' and resource 'any topic'. It distinguishes from siblings by naming alternative tools for specific library queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use gt_search vs alternatives: 'If the query names ONE specific library, prefer gt_resolve_library + gt_get_docs/gt_best_practices...' and also mentions gt_compat and gt_examples. Clear context with examples.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gt_snippetsGet Code SnippetsA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description
`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.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds significant context beyond annotations: first-call indexing, disk cache, refresh semantics, version precedence, source priority (llms.txt > Jina > GitHub README), and a proprietary data notice. Aligns 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured into logical paragraphs (purpose, usage, caching, sibling distinction, legal notice). Slightly verbose but every sentence adds value. Could tighten, but effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers caching, versioning, source priority, sibling distinction, and output format (Context7-compat). No output schema, but description lists fields. Lacks mention of maxSnippets in description, but schema covers it. Adequate for complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 operational meaning: examples for topic, cache behavior tied to version, projectPath auto-detection interaction, and maxSnippets default/max. Exceeds baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it returns ranked code snippets for a library + optional topic, distinguishing itself from sibling gt_examples (real open-source projects vs own docs). Specific verb and resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises use for focused code examples instead of full doc pages, and directs to gt_examples for real project code. Also explains caching, refresh, and versioning behaviors.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: audit scans code, auto_scan detects dependencies, batch_resolve resolves multiple libraries, best_practices fetches guidance, changelog gets release notes, compare compares libraries, compat checks runtime support, dispatch routes ambiguous queries, examples finds real-world code, get_docs fetches documentation, migration provides upgrade guides, resolve_library gets library IDs, search handles arbitrary topics, and snippets returns code snippets. No significant overlap.

Naming Consistency5/5

All tools follow the consistent pattern 'gt_verb_noun' or 'gt_verb' in snake_case, e.g., gt_audit, gt_batch_resolve, gt_dispatch. No mixing of conventions or irregular naming.

Tool Count5/5

With 14 tools, the set is well-scoped for a code quality and documentation server covering auditing, dependency scanning, library resolution, documentation fetching, comparisons, compatibility, examples, migrations, and search. Each tool earns its place, and the number is neither too small nor overwhelming.

Completeness5/5

The set covers the full lifecycle of developer informational needs: finding issues, getting best practices, comparing libraries, checking compatibility, retrieving documentation, code examples, migration guides, changelogs, and resolving library names. There are no obvious gaps for its stated purpose of assisting with code analysis and library documentation.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Cortex C
io.cortex.mcp
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.
Developer Tools Monitoring Observability
312
driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211

Related MCP Servers

Repo Interrogator
Code Analysis Search
taggedzi
A
license
A
quality
A
maintenance
A local-first MCP server that enables AI tools to safely inspect and search code repositories, providing indexing, deterministic BM25 search, code outlining, and context bundles without code modification.
Updated 2 months ago (2026-07-01 21:57 UTC)
9
1
MIT
docpilot-mcp
Developer Tools Documentation Access
neromtoobad
A
license
Not graded
quality
C
maintenance
An MCP server that provides tools to fetch live, version-accurate documentation, changelogs, examples, and method signatures for npm and PyPI packages, preventing AI coding agents from hallucinating stale APIs.
Updated 3 months ago (2026-06-17 10:03 UTC)
21
ISC
docs-mcp
Documentation Access Developer Tools
base-kit
A
license
Not graded
quality
A
maintenance
Provides a local MCP server for searching and retrieving documentation from 22+ open-source projects, enabling AI coding assistants to access up-to-date docs without network dependency.
Updated 2 months ago (2026-06-21 09:55 UTC)
11
2
MIT
Enterprise MCP Documentation
Documentation Access Developer Tools
hasecon
A
license
Not graded
quality
D
maintenance
A self-hosted MCP server that provides up-to-date documentation for enterprise and development tools directly to AI coding assistants like Claude Code and Cursor.
Updated a year ago (2025-07-14 21:49 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rm-rf-prod/GroundTruth-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

The problem

Install

Claude Code

Cursor / Claude Desktop / VS Code

Optional: GitHub token

What it does

How to use it

gt_audit — the one that finds what you missed

gt_auto_scan — best practices for your whole stack

gt_search — anything that isn't a specific library

How docs are fetched

Evidence, not vibes

Library coverage

vs. Context7

Environment variables

Contributing

Active development

Reference

Star history

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`gt_audit` — the one that finds what you missed

`gt_auto_scan` — best practices for your whole stack

`gt_search` — anything that isn't a specific library