How do I use The Toolbox MCP?

1. Click on "Deploy 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., "@The Toolbox MCP search for sqlmap and tell me what it does" 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.

The Toolbox MCP

by Protocol-X-01

Overview Schema Source Related Servers Discussions Admin

Python

Local

The Toolbox MCP

🚀 AI Agent Tool Discovery via Librarian + Tavily

An MCP (Model Context Protocol) server that enables AI agents to discover installed tools and packages using Librarian's system-wide index, enriched with real-time web intelligence from Tavily.

✨ Features

Tool Discovery: Query 9,236+ tools across 14 package managers
Full-Text Search: Millisecond-fast FTS5 queries
Tavily Integration: Real-time tool research and descriptions
Safe: Read-only, bounded, no tool execution
MCP Native: Works with Claude, Bifang, and other MCP clients

Related MCP server: fossick-mcp

🛠️ Tools Provided

1. `toolbox_search`

Search for tools by keywords with pagination.

2. `toolbox_describe`

Get detailed info for a specific tool.

3. `toolbox_inventory`

Overview of indexed tools, sources, and categories.

4. `toolbox_research` 🆕 (Tavily)

Enrich tool information with real-time web search via Tavily.

🚀 Quick Start

Prerequisites

Python 3.11+
uv package manager
Librarian index database
Tavily API key (optional, for enrichment)

Setup

# Clone this repo
git clone https://github.com/Protocol-X-01/toolbox-mcp.git
cd toolbox-mcp

# Install dependencies
uv sync --locked

# Set environment variables
export TAVILY_API_KEY='tvly_your_key_here'

# Run the server
uv run --frozen the-toolbox --db /path/to/librarian/index.db

🔍 Tavily Integration

The Toolbox MCP uses Tavily instead of Bright Data for tool enrichment:

Benefits

✅ Real-time Research: Current documentation and examples
✅ High Quality: LLM-optimized results
✅ Affordable: Pay-per-use, no subscription
✅ Simple: One API key, works everywhere
✅ Transparent: Clear sources and citations

How It Works

When toolbox_research is called:

Search Librarian index for tool
Query Tavily for latest info
Combine indexed + web data
Return enriched result

Example

# Search for a tool
result = toolbox_search("sql injection")

# Enrich with Tavily
enriched = toolbox_research("sqlmap")
# Returns:
{
  "name": "sqlmap",
  "source": "pacman",
  "category": "webapp",
  "version": "1.10.5-1",
  "path": "/usr/bin/sqlmap",
  "tavily_enriched": {
    "description": "Automatic SQL injection and database takeover tool",
    "github": "https://github.com/sqlmapproject/sqlmap",
    "documentation": "https://sqlmap.org",
    "last_updated": "2026-10-29"
  }
}

📊 Stats

Current Index (as of 2026-10-29):

Total Tools: 9,236
Sources: 14 package managers
Categories: 60+ types
Query Time: <8ms average

🔗 Integration

With Bifang

export BIFANG_MCP_SERVERS=[{
  "name":"the-toolbox",
  "command":"/path/to/toolbox-mcp/.venv/bin/the-toolbox",
  "args":["--db","/var/lib/librarian/index.db"]
}]

With Claude Desktop

{
  "mcpServers": {
    "the-toolbox": {
      "command": "/path/to/toolbox-mcp/.venv/bin/the-toolbox",
      "args": ["--db", "/var/lib/librarian/index.db"],
      "env": {
        "TAVILY_API_KEY": "tvly_your_key_here"
      }
    }
  }
}

🎯 Why Tavily?

vs Bright Data:

Feature	Tavily	Bright Data
Setup	1 API key	Complex proxy
Quality	LLM-optimized	Raw SERP
Cost	Pay-per-use	Subscription
Rate Limits	Generous	Strict
Maintenance	Easy	Complex
Agent-Friendly	✅ Yes	⚠️ Manual

Winner: Tavily for AI agents! 🏆

🔧 Configuration

Environment Variables

# Required for Tavily enrichment
TAVILY_API_KEY=tvly_xxxxx

# Optional: Custom LangSmith tracing
LANGSMITH_API_KEY=lsv2_pt_xxxxx
LANGSMITH_PROJECT=toolbox-mcp
LANGSMITH_ENDPOINT=https://api.smith.langchain.com

Index Path

The Toolbox reads from Librarian's SQLite index:

# Default path
/var/lib/librarian/index.db

# Or specify custom path
uv run the-toolbox --db /custom/path/index.db

📝 API Reference

toolbox_search

toolbox_search(
    query: str,           # Search terms (1-256 chars)
    source: str = None,   # Filter by package manager
    category: str = None, # Filter by category
    limit: int = 15,      # Results per page (1-50)
    offset: int = 0       # Pagination (0-10000)
) -> dict

toolbox_describe

toolbox_describe(
    name: str  # Exact tool name (1-256 chars)
) -> dict

toolbox_inventory

toolbox_inventory() -> dict

toolbox_research 🆕

toolbox_research(
    name: str  # Tool name to enrich via Tavily
) -> dict

🛡️ Safety Features

✅ Read-Only: SQLite opened with mode=ro
✅ Bounded Inputs: Max query length, pagination limits
✅ Timeout Protection: 1-second query deadline
✅ No Execution: Discovers tools, doesn't run them
✅ Untrusted Data: Descriptions are evidence, not instructions

🧪 Testing

# Run tests
uv run pytest tests/ -v

# Test Tavily integration
export TAVILY_API_KEY='your_key'
uv run python -c "
from toolbox import toolbox_research
result = toolbox_research('nmap')
print(result)
"

📦 Supported Sources

Librarian indexes tools from:

pacman (Arch + BlackArch)
aur (AUR packages)
path ($PATH binaries)
cargo (Rust)
pip/pipx (Python)
npm/yarn/pnpm (JavaScript)
docker (Container images)
desktop (GUI apps)
foundry (Solidity)
conda (Data science)
rpm (RPM packages)
And more...

🤝 Integration with Bifang

Built for the Nebius x NVIDIA Hackathon 2026:

Repo: https://github.com/Protocol-X-01/Bifang
Live Test: Nemotron Nano roundtrip verified
Tokens: 8,885 tracked in live demo
Status: Production ready ✅

🎓 Use Cases

1. AI Coding Agents

"Find tools for SQL injection testing" → Returns: sqlmap, jsql-injection, sqlbrute...

2. Security Researchers

"What wireless tools do I have?" → Returns: aircrack-ng, wifite, reaver...

3. DevOps Engineers

"Find container tools" → Returns: docker, podman, buildah...

4. Data Scientists

"What ML libraries are installed?" → Returns: numpy, pandas, scikit-learn...

🔗 Links

Repository: https://github.com/Protocol-X-01/toolbox-mcp
Librarian: https://github.com/Protocol-X-01/librarian
Tavily: https://tavily.com
MCP Protocol: https://modelcontextprotocol.io

📄 License

MIT License - See LICENSE

🙏 Credits

Librarian - System-wide tool indexing
Tavily - Web intelligence API
MCP - Model Context Protocol
Bifang - AI coding agent integration

Built with ❤️ for the Nebius x NVIDIA Hackathon 2026

Available Tools

4 tools

toolbox_describeA

Read-onlyIdempotent

Return up to 50 indexed records for an exact tool name across package managers.

Name	Required	Description	Default
`name`	Yes

Output Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real context with the 50-record cap and per-package-manager aggregation, but says nothing about behavior when the name is not found (empty result vs error) or whether duplicates are collapsed.

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?

One short, front-loaded sentence with no filler. The record cap and the exactness constraint both land before the agent stops reading.

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

Completeness3/5

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

An output schema and rich annotations remove the need to explain return values or safety, and the 1-param surface is small. What remains missing is the lookup-vs-search distinction against three sibling tools and the not-found behavior, which matters for an agent choosing among four similarly scoped tools.

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 0% and the single 'name' parameter has no description, so the description carries the burden. It does compensate by clarifying that matching is EXACT rather than fuzzy or regex, which is the key semantic an agent needs, but it omits format, case sensitivity, and namespace conventions.

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

Purpose4/5

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

States a specific verb (return indexed records) and resource (tool records across package managers) and adds the 'exact tool name' qualifier that separates it from a fuzzy lookup. It does not name any sibling, so the differentiation is implied rather than explicit.

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

Usage Guidelines3/5

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

'Exact tool name' implies the use case: look up a tool whose name you already know, rather than browse or search. However, no sibling is named and there is no statement of when to prefer toolbox_search or toolbox_inventory, so the agent must infer the routing.

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

toolbox_inventoryA

Read-onlyIdempotent

Show inventory size, source scan timestamps/failures, and categories without scanning or executing tools.

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds real context beyond them: this call does not trigger a scan or execute any tool, and it surfaces scan failure timestamps so the agent can judge staleness. That is genuine behavioral disclosure the annotations cannot express.

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?

A single front-loaded sentence with no filler. The verb comes first, the returned data is enumerated, and the negative constraint ('without scanning or executing tools') is appended where it lands hardest. Nothing could be cut without losing information.

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?

An output schema exists, so return-shape explanation is unnecessary, and with no parameters the definitional burden is low. The description covers cost (no scan), contents, and a staleness signal. Only the relationship to the three sibling tools is unaddressed.

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 tool takes zero parameters, so there is nothing for the description to disambiguate — baseline 4 applies. The description correctly avoids inventing parameters or restating the empty schema.

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

Purpose4/5

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

States a specific verb ('Show') and resource ('inventory') and enumerates the three things returned: size, source scan timestamps/failures, and categories. An agent immediately knows this is a metadata snapshot. It stops short of differentiating itself from siblings like toolbox_describe or toolbox_search.

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

Usage Guidelines3/5

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

The clause 'without scanning or executing tools' implies a cheap orientation call, which is meaningful usage guidance. However, it never says when to pick this over toolbox_search or toolbox_describe, nor does it sequence itself as a first step — the routing is left to inference.

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

toolbox_researchB

Read-only

Enrich tool information with real-time web search via Tavily.

Combines Librarian's indexed data with Tavily web search for up-to-date documentation, GitHub links, and usage examples.

Name	Required	Description	Default
`name`	Yes

Output Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, non-idempotent and non-destructive, covering the safety profile. The description adds that results come from an external Tavily call and include docs, GitHub links and examples, but says nothing about latency, cost, or why it is not idempotent.

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?

Two short, front-loaded sentences with no filler; the mechanism and value are stated up front. Minor looseness from the line break and the vague verb 'enrich'.

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

Completeness3/5

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

Return values need not be explained because an output schema exists, and annotations cover safety. Still, for a one-parameter tool the description leaves open whether 'name' is a registry entry, a package, or a URL, and when to prefer a sibling — a meaningful gap.

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 0% on a single required 'name' string with no description. The phrase 'Enrich tool information' hints the parameter is a tool name, but the description never states that explicitly or gives format expectations, so it only partially compensates for the schema gap.

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

Purpose4/5

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

States a specific action with mechanism: enrich tool information using real-time web search via Tavily, combining indexed data with live results. That is clearly distinguishable from toolbox_describe or toolbox_inventory in spirit, but the description never names those siblings, so the boundary is left to inference.

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

Usage Guidelines3/5

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

Usage is only implied by 'for up-to-date documentation' — an agent can infer this is the fallback when indexed data is stale, but no explicit trigger, exclusion, or named alternative (e.g. toolbox_search) is given.

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

toolbox_searchA

Read-onlyIdempotent

Find installed tools by literal words, with optional source/category filters and bounded pagination.

Name	Required	Description	Default
`limit`	No
`query`	Yes
`offset`	No
`source`	No
`category`	No

Output Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile needs no restating. The description adds only that pagination is bounded and filters are optional; it does not say what matching semantics are (substring, token, AND/OR) or what ranking applies to results.

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?

A single front-loaded sentence with no filler or repetition. It is arguably over-compressed for a five-parameter search tool, but nothing in it is wasted.

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?

The output schema covers return values, so the description need not explain results, and the annotations cover the safety profile. What remains missing is matching semantics and filter value domains, which matters given 0% schema coverage on five parameters.

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 0%, so the description carries the full parameter burden, and it does name two of the optional filters (source, category) plus bounded pagination. It says nothing about query syntax, allowed source/category values, or how limit and offset interact, leaving real gaps.

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

Purpose4/5

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

States a specific verb and resource ('Find installed tools') and adds a meaningful qualifier ('by literal words'), which hints at keyword matching. It never names a sibling, so an agent must infer the contrast with toolbox_inventory or toolbox_research rather than being told it.

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

Usage Guidelines3/5

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

'By literal words' implies the tool is for exact-term lookup rather than exploration, which is a usable hint. But there is no explicit when-to-use/when-not statement and no routing to the sibling tools that plainly overlap (inventory, describe, research).

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.2.0Oct 30, 2026
- First observedtoolbox_describe
- First observedtoolbox_inventory
- First observedtoolbox_research
- First observedtoolbox_search

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.7/5.0

Scored 2026-10-30 09:45 across 4 tools

Disambiguation4/5

Each tool has a distinct role: search (fuzzy word lookup), describe (exact-name multi-source lookup), inventory (metadata/status), and research (web enrichment). Search vs describe slightly overlap since both return tool records, but the 'literal words' vs 'exact name' distinction is stated clearly enough to guide selection.

Naming Consistency5/5

All four tools follow a consistent toolbox_<verb> snake_case pattern (search, describe, inventory, research). Predictable and easy to map to intent.

Tool Count4/5

Four tools is on the lean side but each covers a genuine stage of discovery (scan status, find, detail, enrich). No redundant tools, though the surface feels slightly thin for a 'toolbox'.

Completeness4/5

For a discovery/lookup server the lifecycle (inventory status -> search -> describe -> research) is covered without dead ends. Missing install/execute/update operations, but those appear outside the stated read-only scope.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

SCRIPTMASTERLABS — ScriptDocs A
com.scriptmasterlabs
Live npm, PyPI and crates.io package facts, READMEs and vulnerability checks for coding agents.
Developer Tools Documentation Access Security
51
https://scriptdocs-mcp.onrender.com/mcp
developer-tools-mcp-server A
com.thenextgennexus
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Developer Tools Search
3
https://nexgendata-mcp-proxy.steve-corbeil.workers.dev/developer-tools-mcp-server/mcp
Package Intel MCP A
com.datakoot
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Developer Tools Code Analysis
61
https://package.datakoot.com/mcp
Package Intel MCP A
io.github.selflabbs
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Developer Tools Code Analysis
2
https://package.selflabbs.com/mcp

Related MCP Servers

UseKeen Documentation MCP
Documentation Access Search
PromptMixerDev
A
license
Not graded
quality
D
maintenance
Enables AI assistants to search documentation of packages and services to find implementation details, examples, and specifications.
Updated a year ago (2025-05-08 02:00 UTC)
MIT
fossick-mcp
Search Developer Tools Code Analysis
Lipdog
A
license
A
quality
C
maintenance
Enables AI agents to prospect across GitHub, PyPI, and npm, searching repositories, packages, and code patterns with read-only tools.
Updated 7 months ago (2026-04-13 22:34 UTC)
7
69 PyPI
5
MIT
npmlens-mcp
Search Developer Tools
rakeshmenon
A
license
A
quality
C
maintenance
Enables AI coding agents to search the npm registry and retrieve package metadata, READMEs, download stats, GitHub details, and usage snippets via the Model Context Protocol.
Updated a year ago (2025-12-03 15:10 UTC)
9
6 npm
MIT
package-registry-mcp
Developer Tools Search
mikeysrecipes
A
license
Not graded
quality
D
maintenance
Enables AI assistants to search and retrieve detailed package information from multiple package registries (NPM, crates.io, NuGet, PyPI, Go).
Updated a year ago (2025-07-22 07:36 UTC)
5,758 npm
MIT

The Toolbox MCP

✨ Features

🛠️ Tools Provided

1. toolbox_search

2. toolbox_describe

3. toolbox_inventory

4. toolbox_research 🆕 (Tavily)

🚀 Quick Start

Prerequisites

Setup

🔍 Tavily Integration

Benefits

How It Works

Example

📊 Stats

🔗 Integration

With Bifang

With Claude Desktop

🎯 Why Tavily?

🔧 Configuration

Environment Variables

Index Path

📝 API Reference

toolbox_search

toolbox_describe

toolbox_inventory

toolbox_research 🆕

🛡️ Safety Features

🧪 Testing

📦 Supported Sources

🤝 Integration with Bifang

🎓 Use Cases

1. AI Coding Agents

2. Security Researchers

3. DevOps Engineers

4. Data Scientists

🔗 Links

📄 License

🙏 Credits

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. `toolbox_search`

2. `toolbox_describe`

3. `toolbox_inventory`

4. `toolbox_research` 🆕 (Tavily)