| search_library_docs | Find docs for a library using PyPI metadata and GitHub repos combined. Returns data in JSON format with token statistics. |
| get_cache_info | Get information about the current cache usage. |
| get_cache_entries | Get detailed information about all cached entries. |
| github_repo_search | Search for GitHub repositories by keyword or topic.
USE THIS WHEN: You need to find repositories for a library, framework, or topic.
BEST FOR: Discovering which repository contains a specific project.
Returns repository names, descriptions, stars, and URLs - but NOT the code itself.
To explore code after finding a repo, use:
- get_repo_tree() to see all files
- list_repo_contents() to browse directories
- get_file_content() to read specific files
Args:
query: Search keywords (e.g., "machine learning", "web framework")
limit: Maximum number of results (default 5)
language: Filter by programming language (default "Python")
Example: github_repo_search("requests") → Finds psf/requests repository
|
| github_code_search | Search for code snippets across GitHub or within a specific repository.
USE THIS WHEN: You need to find code examples, function definitions, or usage patterns.
RETURNS: File paths and locations where code was found - NOT the actual file contents.
To read the files, use get_file_content() with the returned paths.
NOTE: Requires authentication - rate limited without GITHUB_TOKEN.
Args:
query: Code search query (e.g., "def parse_args", "class HTTPClient")
repo: Optional repository filter in "owner/repo" format
limit: Maximum number of results (default 5)
Example: github_code_search("async def fetch", repo="psf/requests")
|
| list_github_packages | List packages (including GHCR images) for a GitHub user or organization.
USE THIS WHEN: You want to find Docker images or other packages hosted on GitHub for a specific user/org.
Note: GitHub does not support global package search; you must provide an owner.
Args:
owner: GitHub username or organization name (e.g. "github", "octocat")
package_type: Type of package to list. Defaults to "container" (GHCR).
Options: "container", "npm", "maven", "rubygems", "nuget", "docker" (legacy)
Returns:
JSON list of packages with metadata (name, repository, version count, etc.)
|
| get_package_versions | Get versions for a specific GitHub package.
USE THIS WHEN: You found a package using list_github_packages and want to see available tags/versions.
Args:
owner: GitHub username or organization name
package_type: Type of package (e.g., "container")
package_name: Name of the package (e.g., "rtfd")
Returns:
JSON list of versions/tags.
|
| fetch_github_readme | Fetch README file from a GitHub repository.
USE THIS WHEN: You need the project overview, quick start, or basic documentation.
BEST FOR: Getting a high-level understanding of a project.
The README typically contains installation, usage examples, and project description.
For deeper code exploration, use:
- get_repo_tree() to see the complete file structure
- get_file_content() to read specific source files
Args:
repo: Repository in "owner/repo" format (e.g., "psf/requests")
max_bytes: Maximum content size, default 20KB
Returns: JSON with README content, size, and metadata
Example: fetch_github_readme("psf/requests") → Returns the requests README
|
| list_repo_contents | List contents of a directory in a GitHub repository.
USE THIS WHEN: You need to browse or explore the structure of a repository directory.
BEST FOR: Discovering what files and folders exist in a specific location.
Returns names, paths, types (file/dir), sizes for each item.
Common workflow:
1. Use github_repo_search() to find the repository
2. Use get_repo_tree() to see the overall structure
3. Use list_repo_contents() to browse specific directories
4. Use get_file_content() to read individual files
Args:
repo: Repository in format "owner/repo" (e.g., "psf/requests")
path: Path to directory (empty string for root, e.g., "src/utils")
Returns:
JSON with list of files and directories with metadata
Example: list_repo_contents("psf/requests", "requests") → Lists files in requests/ directory
|
| get_file_content | Get content of a specific file from a GitHub repository.
USE THIS WHEN: You need to read the actual source code or contents of a specific file.
BEST FOR: Examining implementation details, understanding how code works, or reading configuration files.
Returns the full file content (UTF-8 text only, binary files are rejected).
Automatically handles:
- Base64 decoding from GitHub API
- UTF-8 conversion with safe truncation
- Binary file detection
Args:
repo: Repository in format "owner/repo" (e.g., "psf/requests")
path: Path to file (e.g., "requests/api.py")
max_bytes: Maximum content size (default 100KB, increase for large files)
Returns:
JSON with file content, size, truncation status, and metadata
Example: get_file_content("psf/requests", "requests/api.py") → Returns source code of api.py
|
| get_repo_tree | Get the full file tree of a GitHub repository.
USE THIS WHEN: You need to see the overall structure and organization of a repository.
BEST FOR: Understanding project layout, finding specific files, or getting a complete directory listing.
Returns all file paths, types (file/directory), and sizes in a single call.
Use recursive=True for complete tree (all files in all subdirectories).
Use recursive=False for just top-level overview (faster, less data).
After getting the tree, use:
- get_file_content() to read specific files you identified
- list_repo_contents() to browse specific directories in detail
Args:
repo: Repository in format "owner/repo" (e.g., "psf/requests")
recursive: Whether to get full tree recursively (default False)
max_items: Maximum number of items to return (default 1000)
Returns:
JSON with complete file tree structure, branch, and count
Example: get_repo_tree("psf/requests", recursive=True) → Returns complete file listing
|
| get_commit_diff | Get the diff between two commits, branches, or tags in a GitHub repository.
USE THIS WHEN: You need to see what changed between two versions of code.
BEST FOR: Analyzing changes, reviewing pull requests (by comparing branches), or checking version differences.
Returns the raw git diff output.
Args:
repo: Repository in format "owner/repo" (e.g., "psf/requests")
base: Base commit SHA, branch name, or tag (e.g., "main", "v1.0.0", "a1b2c3d")
head: Head commit SHA, branch name, or tag (e.g., "feature-branch", "v1.1.0", "e5f6g7h")
Returns:
JSON with the raw git diff content.
Example: get_commit_diff("psf/requests", "v2.28.0", "v2.28.1") → Returns diff between versions
|
| search_crates | Search for Rust crates on crates.io by name or keywords.
USE THIS WHEN: You need to find Rust packages/crates for a specific purpose or library.
BEST FOR: Discovering which Rust crates exist for a topic or functionality.
Returns multiple matching crates with names, versions, descriptions, download counts, and URLs.
After finding a crate, use:
- crates_metadata() to get detailed information about a specific crate
- The documentation URL to read full docs (use WebFetch)
Args:
query: Search keywords (e.g., "http client", "web framework", "serde")
limit: Maximum number of results (default 5, max 100)
Returns:
JSON with list of matching crates, total results, and metadata
Example: search_crates("web framework") → Finds actix-web, rocket, axum, etc.
|
| crates_metadata | Get detailed metadata for a specific Rust crate from crates.io.
USE THIS WHEN: You need comprehensive information about a specific Rust crate.
RETURNS: Detailed crate metadata including version, URLs, downloads, and license.
Does NOT include full documentation content.
The response includes:
- Crate name, version, description
- Documentation URL (docs.rs) - can be passed to WebFetch for full API docs
- Repository URL (usually GitHub) - can be used with GitHub provider
- Homepage, license, categories, keywords
- Download statistics, creation/update dates
- Minimum Rust version required
Args:
crate: Crate name (e.g., "serde", "tokio", "actix-web")
Returns:
JSON with comprehensive crate metadata
Example: crates_metadata("serde") → Returns metadata with docs.rs link and GitHub repo
|
| npm_metadata | Get npm package metadata (name, version, URLs, maintainers).
USE THIS WHEN: You need basic package info, version numbers, or links to external documentation.
RETURNS: Package metadata ONLY - does NOT include actual documentation content.
For full documentation, use fetch_npm_docs instead.
The response includes:
- Package name, version, description
- Documentation URL (docs_url/homepage) - can be passed to WebFetch for external docs
- Repository URL (usually GitHub)
- License, keywords, maintainers
Args:
package: npm package name (e.g., "express", "react", "lodash")
Example: npm_metadata("express") → Returns metadata with links to expressjs.com
|
| fetch_npm_docs | Fetch actual npm package documentation from npm registry README.
USE THIS WHEN: You need installation instructions, usage examples, API reference, or quickstart guides.
BEST FOR: Getting complete, formatted documentation for JavaScript/Node.js packages.
Better than using curl or WebFetch because it:
- Automatically extracts relevant sections (Installation, Usage, Examples, API)
- Prioritizes most useful content sections
- Already in Markdown format (npm requires Markdown READMEs)
NOT SUITABLE FOR: External documentation sites (use docs_url from npm_metadata + WebFetch)
Args:
package: npm package name (e.g., "express", "react", "axios")
max_bytes: Maximum content size, default 20KB (increase for large packages)
Returns:
JSON with actual documentation content, size, truncation status, version
Example: fetch_npm_docs("express") → Returns formatted README with installation and usage
|
| search_gcp_services | Search for GCP (Google Cloud Platform) services and documentation.
USE THIS WHEN: You need to find Google Cloud services, APIs, or documentation for a specific GCP topic.
BEST FOR: Discovering which GCP services exist for a use case or finding service documentation.
Returns multiple matching services with names, descriptions, API endpoints, and docs URLs.
Searches:
1. Local service mapping (exact and partial matches)
2. cloud.google.com website (fallback for specific queries)
3. googleapis GitHub repository (API definitions)
After finding a service, use:
- fetch_gcp_service_docs() to get full documentation content
- The docs_url with WebFetch for external documentation
Note: GitHub API search (fallback) is limited to 60 requests/hour without GITHUB_TOKEN.
Args:
query: Service name or keywords (e.g., "storage", "vertex ai", "gke audit", "bigquery")
limit: Maximum number of results (default 5)
Returns:
JSON with list of matching services including name, description, API endpoint, docs URL
Example: search_gcp_services("vertex ai") → Finds Vertex AI service with docs links
|
| fetch_gcp_service_docs | Fetch actual documentation content for a GCP (Google Cloud Platform) service.
USE THIS WHEN: You need detailed documentation, guides, tutorials, or API reference for a GCP service.
BEST FOR: Getting complete documentation with setup instructions, usage examples, and API details.
Better than using curl or WebFetch because it:
- Automatically extracts relevant content from cloud.google.com
- Converts HTML to clean Markdown format
- Prioritizes important sections (Overview, Quickstart, API Reference)
- Removes navigation, ads, and other non-content elements
- Handles multi-word service names (e.g., "gke audit policy")
Works with:
- Exact service names (e.g., "Cloud Storage", "Compute Engine")
- Common abbreviations (e.g., "GCS", "GKE", "BigQuery")
- Multi-word queries (e.g., "gke audit policy configuration")
Args:
service: Service name or topic (e.g., "Cloud Storage", "vertex ai", "gke audit")
max_bytes: Maximum content size, default 20KB (increase for comprehensive docs)
Returns:
JSON with documentation content, size, source URL, truncation status
Example: fetch_gcp_service_docs("vertex ai") → Returns formatted documentation from cloud.google.com
|
| pypi_metadata | Get Python package metadata from PyPI (name, version, URLs, summary).
USE THIS WHEN: You need basic package info, version numbers, or links to external documentation.
RETURNS: Package metadata ONLY - does NOT include actual documentation content.
For full documentation, use fetch_pypi_docs instead.
The response includes:
- Package name, version, summary
- Documentation URL (docs_url) - can be passed to WebFetch for external docs
- Project URLs (homepage, repository, etc.)
Args:
package: PyPI package name (e.g., "requests", "flask", "django")
ignore_verification: Skip PyPI verification check if VERIFIED_BY_PYPI is enabled
Example: pypi_metadata("requests") → Returns metadata with docs_url pointing to readthedocs
|
| fetch_pypi_docs | Fetch actual Python package documentation from PyPI README/description.
USE THIS WHEN: You need installation instructions, usage examples, API reference, or quickstart guides.
BEST FOR: Getting complete, formatted documentation for Python packages.
Better than using curl or WebFetch because it:
- Automatically extracts relevant sections (Installation, Usage, Examples)
- Converts reStructuredText to Markdown
- Prioritizes most useful content sections
- Falls back to GitHub README if PyPI description is minimal
NOT SUITABLE FOR: External documentation sites (use docs_url from pypi_metadata + WebFetch)
Args:
package: PyPI package name (e.g., "requests", "numpy", "pandas")
max_bytes: Maximum content size, default 20KB (increase for large packages)
ignore_verification: Skip PyPI verification check if VERIFIED_BY_PYPI is enabled
Returns: JSON with actual documentation content, size, truncation status
Example: fetch_pypi_docs("requests") → Returns formatted README with installation and usage
|
| zig_docs | Search Zig programming language documentation.
USE THIS WHEN: You need information about Zig language features, syntax, stdlib, or concepts.
BEST FOR: Learning Zig language specifics and finding relevant documentation sections.
Searches the official Zig documentation (ziglang.org/documentation/master/) and returns
matching sections with titles, summaries, and relevance scores.
Good for queries about:
- Language features (e.g., "comptime", "async", "optionals")
- Standard library (e.g., "ArrayList", "HashMap", "allocators")
- Memory management (e.g., "allocator", "defer", "errdefer")
- Error handling (e.g., "error sets", "try", "catch")
- Build system (e.g., "build.zig", "zig build")
NOT SUITABLE FOR: Third-party Zig packages (use GitHub provider for that)
Args:
query: Search keywords (e.g., "comptime", "async", "ArrayList", "error handling")
Returns:
JSON with matching documentation sections, relevance scores, and source URL
Example: zig_docs("comptime") → Returns sections about compile-time code execution
|
| godocs_metadata | Get Go package metadata from godocs.io (name, summary, URLs).
USE THIS WHEN: You need basic package info or links to documentation sites.
RETURNS: Package metadata ONLY - does NOT include actual documentation content.
For full documentation, use fetch_godocs_docs instead.
The response includes:
- Package name and summary/description
- godocs.io URL
- pkg.go.dev source URL
Args:
package: Go package path (e.g., "github.com/gin-gonic/gin", "golang.org/x/tools")
Example: godocs_metadata("github.com/gin-gonic/gin") → Returns metadata with summary
|
| fetch_godocs_docs | Fetch actual Go package documentation from godocs.io.
USE THIS WHEN: You need package overview, function signatures, type definitions, or API reference.
BEST FOR: Getting complete documentation for Go packages.
Better than using curl or WebFetch because it:
- Extracts package overview and descriptions
- Includes function and type documentation
- Formats content in readable text format
- Limits output to avoid overwhelming context
NOT SUITABLE FOR: Source code (use GitHub provider for that)
Args:
package: Go package path (e.g., "github.com/gin-gonic/gin", "golang.org/x/sync")
max_bytes: Maximum content size, default 20KB (increase for large packages)
Returns:
JSON with documentation content, size, truncation status, and source info
Example: fetch_godocs_docs("github.com/gin-gonic/gin") → Returns overview and API docs
|
| search_docker_images | Search for Docker images on DockerHub by name or keywords.
USE THIS WHEN: You need to find Docker container images for a specific service, application, or technology.
BEST FOR: Discovering official and community Docker images.
Returns multiple matching images with names, descriptions, star counts, pull counts, and whether they're official.
After finding an image, use:
- docker_image_metadata() for detailed information
- fetch_docker_image_docs() for README and usage instructions
- fetch_dockerfile() to see how the image is built
Args:
query: Search query (e.g., "nginx", "postgres", "machine learning", "python")
limit: Maximum number of results (default 5)
Returns:
JSON with list of matching images including name, description, stars, pulls, official status
Example: search_docker_images("postgres") → Finds official postgres image and alternatives
|
| docker_image_metadata | Get detailed metadata for a specific Docker image from DockerHub.
USE THIS WHEN: You need comprehensive information about a Docker image (stats, description, tags).
RETURNS: Image metadata including popularity metrics and description.
Does NOT include full README documentation.
The response includes:
- Image name, namespace, description
- Star count (popularity)
- Pull count (total downloads)
- Last updated timestamp
- Official/community status
Args:
image: Docker image name (e.g., "nginx", "postgres", "username/custom-image")
Returns:
JSON with comprehensive image metadata
Example: docker_image_metadata("nginx") → Returns stars, pulls, description for nginx image
|
| fetch_docker_image_docs | Fetch actual Docker image documentation and README from DockerHub.
USE THIS WHEN: You need usage instructions, environment variables, volume mounts, or examples.
BEST FOR: Understanding how to use a Docker image and configure it properly.
Better than using curl or WebFetch because it:
- Extracts README content from DockerHub
- Includes image description and key details
- Formats content in readable Markdown
- Prioritizes important sections (Usage, Environment Variables, Examples)
Typical content includes:
- How to run the container
- Available environment variables
- Volume mount points
- Port configurations
- Usage examples and docker-compose snippets
Args:
image: Docker image name (e.g., "nginx", "postgres", "redis")
max_bytes: Maximum content size, default 20KB (increase for detailed docs)
Returns:
JSON with README content, size, and source info
Example: fetch_docker_image_docs("nginx") → Returns README with usage instructions
|
| fetch_dockerfile | Fetch the actual Dockerfile used to build a Docker image.
USE THIS WHEN: You need to see exactly how an image is built (base image, installed packages, configuration).
BEST FOR: Understanding image composition, security analysis, or learning how to build similar images.
Attempts to find Dockerfile link in DockerHub description and fetches from source (usually GitHub).
Useful for:
- Seeing what base image is used
- Identifying installed packages and dependencies
- Understanding build process and optimizations
- Security auditing (what's included in the image)
- Learning Dockerfile best practices from official images
Note: Not all images have publicly accessible Dockerfiles. Many official images do.
Args:
image: Docker image name (e.g., "nginx", "python", "postgres")
Returns:
JSON with Dockerfile content, source URL, and metadata (or error if not found)
Example: fetch_dockerfile("nginx") → Returns Dockerfile from nginx GitHub repository
|
