ProDisco
ProDisco is a progressive-disclosure MCP server framework that indexes TypeScript library APIs for discovery and executes code in a sandboxed environment, returning console output to agents.
Core Capabilities:
Dynamic API Discovery - Search and browse API documentation (methods, types, functions, cached scripts) extracted from TypeScript libraries via
.d.tsfiles or ESM JavaScript fallbackSandboxed Code Execution - Execute TypeScript code in an isolated environment with restricted access to only pre-configured npm packages and environment variables
Multiple Execution Modes - Supports blocking, real-time streaming, async (background), and cached script execution, with status checking and cancellation
Flexible Library Configuration - Configure which npm packages to index and allow via YAML/JSON files, with optional auto-installation into
.cache/depsVersatile Deployment - Supports stdio (default) and HTTP transport with session management, SSE streaming, and containerized sandbox deployment (e.g., Kubernetes) using TCP/gRPC communication
Security Options - TLS and mutual TLS (mTLS) support for production deployments
Advanced Analytics - Statistical analysis, machine learning, linear algebra, and signal processing via libraries like
simple-statistics,ml-regression,mathjs, andfft-jsZero Maintenance - Automatically extracts methods from library type definitions, staying current with dependency upgrades
Key Tools:
prodisco.searchTools- Search extracted API documentation by method name, type, library, or categoryprodisco.runSandbox- Execute TypeScript code with captured console output
Example Use Cases:
Query Kubernetes clusters via
@kubernetes/client-nodeAnalyze Prometheus metrics with PromQL execution
Query Loki logs using LogQL
Detect anomalies, memory leaks, and capacity issues
Perform trend forecasting and correlation analysis on operational data
Provides tools for managing and inspecting Kubernetes clusters, including listing nodes, pods, and other resources across namespaces, viewing logs, and executing operations through TypeScript modules that agents discover and use progressively.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ProDiscolist all pods in the default namespace with their status"
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.
ProDisco (Progressive Disclosure MCP Server)
ProDisco is a progressive-disclosure MCP server framework: you provide a list of TypeScript libraries, ProDisco indexes their APIs for discovery, and a sandbox executes code that uses only those libraries. It follows Anthropic's Progressive Disclosure pattern: the MCP server exposes search tools which surface library APIs, agents discover them to write code, execute it in a sandbox, and only the final console output returns to the agent.
Kubernetes/observability is just one example configuration (see examples/). You can equally build an MCP server around AWS/GCP SDKs, Postgres clients, internal TypeScript SDKs, etc.
Note: ProDisco prefers indexing APIs from TypeScript declaration files (
.d.ts). If a library ships no.d.ts, ProDisco can fall back to indexing ESM JavaScript exports (best-effort; types default toany). CommonJS-only JavaScript packages without typings are not supported.
Demo use-cases (optional):
Kubernetes access via
@kubernetes/client-nodePrometheus metrics via
@prodisco/prometheus-clientLoki logs via
@prodisco/loki-clientAnalytics via
simple-statistics

Architecture

Each MCP client session gets its own isolated Sandbox CRD (Kata VM), with per-session gRPC connections, idle timeout cleanup, and max session limits. See docs/grpc-sandbox-architecture.md for details.
Related MCP server: Kube MCP
Table of Contents
Why Progressive Disclosure?
Anthropic's latest guidance explains why MCP servers should progressively reveal capabilities instead of dumping every tool definition into the model context. When agents explore a filesystem of TypeScript modules, they only load what they need and process data inside the execution environment, then return a concise result to the chat. This keeps token usage low, improves latency, and avoids copying large intermediate payloads through the model (source).
ProDisco goes a step further: instead of exposing custom TypeScript modules, it provides a structured parameter search tool that dynamically extracts methods from upstream libraries using TypeScript AST parsing. This means:
Zero maintenance - Methods are extracted directly from library
.d.tsfilesAlways current - Upgrading a dependency automatically exposes new methods
Type-safe - Full parameter types and return types included
Quick Start
Add to Claude Code
Kubernetes + Observability:
curl -O https://raw.githubusercontent.com/harche/ProDisco/main/examples/prodisco.kubernetes.yaml
claude mcp add ProDisco --env KUBECONFIG="${HOME}/.kube/config" -- npx -y @prodisco/mcp-server --config prodisco.kubernetes.yamlPostgreSQL (in-memory testing):
curl -O https://raw.githubusercontent.com/harche/ProDisco/main/examples/prodisco.postgres.yaml
claude mcp add ProDisco -- npx -y @prodisco/mcp-server --config prodisco.postgres.yamlRemove if needed:
claude mcp remove ProDiscoEnvironment Variables
Variable | Required | Description |
| No | Path to the libraries config file (same as |
| No | (If using |
| No | (If using |
| No | (If using |
Important: Export environment variables before running
claude mcp add. The--envflag may not reliably pass variables to the MCP server process.
Tip: If you're using a kind cluster for local testing, you can port-forward to Prometheus:
kubectl port-forward -n monitoring svc/prometheus-server 9090:80Then set
PROMETHEUS_URL="http://localhost:9090"
Development Setup
For local development:
git clone https://github.com/harche/ProDisco.git
cd ProDisco
npm install
npm run build
claude mcp add --transport stdio prodisco -- node dist/server.js
claude mcp remove prodisco # remove when you're doneStartup Options:
Flag | Description |
| Clear the scripts cache before starting |
| Path to YAML/JSON config listing libraries to index/allow |
| Transport mode: |
| HTTP host to bind to (default: |
| HTTP port (default: |
node dist/server.js --clear-cacheDynamic Libraries Configuration
ProDisco can be started with a config file that determines which npm packages are:
Indexed by
prodisco.searchToolsAllowed in the sandbox via
require()(kept in lockstep with indexing)
See examples/ for ready-to-use configs (Kubernetes, PostgreSQL, etc.).
Example prodisco.config.yaml:
libraries:
- name: "@kubernetes/client-node"
description: "Kubernetes API client"
- name: "@prodisco/prometheus-client"
description: "Prometheus queries + metric discovery"
- name: "@prodisco/loki-client"
description: "Loki LogQL querying"
- name: "simple-statistics"
description: "Statistics helpers"Start with a config file:
node dist/server.js --config prodisco.config.yamlMissing packages are automatically installed into .cache/deps on startup.
Environment variables:
Variable | Description |
| Path to YAML/JSON config listing libraries |
Build Docker Images From Config
If you want images that already contain the configured libraries (for deploying MCP and sandbox separately), you can build them directly from the same config file:
npm run docker:build:config -- --config prodisco.config.yamlThis builds:
prodisco/mcp-server:<configSha8>using the rootDockerfileprodisco/sandbox-server:<configSha8>usingpackages/sandbox-server/Dockerfile
You can override image names/tags:
npm run docker:build:config -- --config prodisco.config.yaml --tag dev --mcp-image myorg/prodisco-mcp --sandbox-image myorg/prodisco-sandboxHTTP Transport
ProDisco supports HTTP transport for network-based MCP connections, enabling remote access and containerized deployments.
Start in HTTP mode:
# HTTP mode on default port (3000)
node dist/server.js --transport http
# HTTP mode on custom port
node dist/server.js --port 8080
# HTTP mode on all interfaces (for network access)
node dist/server.js --host 0.0.0.0 --port 3000Environment Variables:
Variable | Default | Description |
|
| Transport mode ( |
|
| HTTP host to bind to |
|
| HTTP port to listen on |
HTTP Endpoints:
Endpoint | Method | Description |
| GET | Health check, returns |
| POST | MCP JSON-RPC endpoint (Streamable HTTP) |
Example: Connect with curl
# Health check
curl http://localhost:3000/health
# Initialize MCP session
curl -X POST http://localhost:3000/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0.0"}}}'
# Use session ID from response header for subsequent requests
curl -X POST http://localhost:3000/mcp \
-H "Content-Type: application/json" \
-H "mcp-session-id: <session-id-from-init>" \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'The HTTP transport uses the MCP SDK's StreamableHTTPServerTransport, which supports session management via mcp-session-id headers and Server-Sent Events (SSE) for streaming responses.
Available Tools
ProDisco exposes two tools:
prodisco.searchTools
Search and browse extracted API documentation for your startup-configured TypeScript libraries (from .d.ts). Use it to discover the correct method/type/function signatures before calling prodisco.runSandbox.
Document Types:
Type | Description |
| Class methods / instance APIs extracted from configured libraries |
| TypeScript types (interfaces/classes/enums/type aliases) |
| Standalone exported functions |
| Cached sandbox scripts |
| Search everything above (default) |
Examples:
// Search broadly by name (methods/types/functions/scripts)
// Replace the placeholders with terms relevant to your configured libraries.
{ methodName: "<search-term>" }
// Filter by document type (methods/types/functions/scripts)
{ methodName: "<search-term>", documentType: "method" }
// Find Loki query methods
{ documentType: "method", library: "@prodisco/loki-client", category: "query" }
// Find Prometheus methods
{ methodName: "executeRange", library: "@prodisco/prometheus-client" }
// Find analytics functions
{ documentType: "function", library: "simple-statistics" }
// Search cached scripts
{ documentType: "script", methodName: "deployment" }
// Get TypeScript type definitions (classes/interfaces/enums/type aliases)
{ methodName: "<type-or-class-name>", documentType: "type" }
// Exclude certain categories/libraries
{ methodName: "query", exclude: { categories: ["delete"], libraries: ["some-library"] } }For comprehensive documentation, see docs/search-tools.md.
prodisco.runSandbox
Execute TypeScript code in a sandboxed environment using the same configured library allowlist as prodisco.searchTools.
Execution Modes:
Mode | Purpose | Key Parameters |
| Blocking execution |
|
| Real-time output streaming |
|
| Background execution |
|
| Check async execution |
|
| Cancel running execution |
|
| List active executions |
|
Sandbox Environment:
console- Captured output (log, error, warn, info)require()- Restricted to configured npm packages (and their subpaths)process.env- Environment variables
Examples:
// Execute code (default mode)
{
code: `
const k8s = require("@kubernetes/client-node");
const kc = new k8s.KubeConfig();
kc.loadFromDefault();
const api = kc.makeApiClient(k8s.CoreV1Api);
const pods = await api.listNamespacedPod("default");
console.log(\`Found \${pods.body.items.length} pods\`);
`
}
// Run a cached script
{ cached: "script-2025-01-01T12-00-00-abc123.ts" }
// Stream mode - real-time output
{ mode: "stream", code: "for(let i=0; i<5; i++) console.log(i)" }
// Async mode - start long-running task
{ mode: "async", code: "longRunningTask()" }
// Check async execution status
{ mode: "status", executionId: "abc-123", wait: true }
// Cancel a running execution
{ mode: "cancel", executionId: "abc-123" }
// Query Prometheus metrics
{
code: `
const { PrometheusClient, MetricSearchEngine } = require('@prodisco/prometheus-client');
const client = new PrometheusClient({ endpoint: process.env.PROMETHEUS_URL });
// Discover metrics semantically
const search = new MetricSearchEngine(client);
const metrics = await search.search("memory usage");
console.log('Found metrics:', metrics.map(m => m.name));
// Execute PromQL query
const end = new Date();
const start = new Date(end.getTime() - 60 * 60 * 1000);
const result = await client.executeRange('node_memory_MemAvailable_bytes', { start, end, step: '1m' });
console.log(\`Got \${result.data.length} time series\`);
`
}
// Query Loki logs
{
code: `
const { LokiClient } = require('@prodisco/loki-client');
const client = new LokiClient({ baseUrl: process.env.LOKI_URL });
const result = await client.queryRange('{namespace="default"}', { since: '1h', limit: 100 });
result.logs.forEach(log => console.log(\`[\${log.timestamp.toISOString()}] \${log.line}\`));
`
}For architecture details, see docs/grpc-sandbox-architecture.md.
Advanced Analytics
ProDisco goes beyond simple resource fetching - it provides statistical analysis, machine learning, and signal processing capabilities for deep cluster observability.
Available Libraries:
Library | Purpose |
| Mean, median, std dev, z-scores, percentiles, linear regression, correlation |
| Polynomial, exponential, and power regression for trend forecasting |
| Matrix operations, linear algebra, symbolic math |
| Fast Fourier Transform for detecting periodic patterns |
Example Prompts:
Use Case | Prompt |
Log Analysis | "Query Loki for error logs from the nginx app in the last hour. Show me the most common error patterns." |
Cluster Health | "Analyze CPU and memory usage across all pods. Calculate mean, median, standard deviation, and identify outliers using z-scores. Show pods above the 95th percentile." |
Memory Leaks | "Check for memory leaks. Fetch memory usage over 2 hours and use linear regression to identify pods with increasing memory." |
Anomaly Detection | "Analyze network traffic and detect anomalies. Find receive/transmit rates more than 2 standard deviations from normal." |
Correlation | "Find correlations between CPU and memory usage. Tell me if high CPU correlates with high memory." |
Periodic Patterns | "Use FFT analysis on node CPU to detect periodic patterns. Are there dominant frequencies suggesting scheduled jobs?" |
Capacity Planning | "Analyze resource trends and use polynomial regression to forecast when we might hit resource limits." |
For detailed examples with code and output, see docs/analytics.md.
Advanced Deployment
Container Isolation
For stronger isolation, run the sandbox server in a Kubernetes cluster and connect via TCP.
1. Deploy the sandbox server:
# Build and load the image (for kind clusters)
docker build -f packages/sandbox-server/Dockerfile -t prodisco/sandbox-server:latest .
kind load docker-image prodisco/sandbox-server:latest
# Deploy
kubectl apply -f packages/sandbox-server/k8s/deployment.yaml
# Port-forward to access locally
kubectl -n prodisco port-forward service/sandbox-server 50051:500512. Configure the MCP server to use TCP:
export KUBECONFIG="${HOME}/.kube/config"
export SANDBOX_USE_TCP=true
export SANDBOX_TCP_HOST=localhost
export SANDBOX_TCP_PORT=50051
claude mcp add --transport stdio prodisco -- node dist/server.js --config examples/prodisco.kubernetes.yamlTransport Environment Variables:
Variable | Default | Description |
|
| Use TCP instead of local subprocess |
|
| Sandbox server host |
|
| Sandbox server port |
Transport Security (TLS/mTLS)
For production deployments, the sandbox server supports TLS and mutual TLS (mTLS):
Mode | Description |
| No encryption (default, for local development) |
| Server-side TLS (client verifies server identity) |
| Mutual TLS (both client and server authenticate) |
Configuration:
# Server-side TLS
export SANDBOX_TRANSPORT_MODE=tls
export SANDBOX_TLS_CERT_PATH=/path/to/server.crt
export SANDBOX_TLS_KEY_PATH=/path/to/server.key
# Client-side (MCP server)
export SANDBOX_TRANSPORT_MODE=tls
export SANDBOX_TLS_CA_PATH=/path/to/ca.crtFor Kubernetes deployments, use cert-manager to automate certificate management. See the k8s/cert-manager directory for ready-to-use manifests.
For full architecture and security details, see docs/grpc-sandbox-architecture.md.
Testing
Integration Tests
End-to-end testing with KIND cluster + Claude Agent SDK:
npm run test:integrationFor detailed testing instructions, see docs/integration-testing.md.
Additional Documentation
Document | Description |
Advanced analytics guide - anomaly detection, forecasting, correlation, FFT analysis | |
Complete searchTools reference with examples and technical architecture | |
Practical examples + runnable library config files ( | |
Sandbox architecture, gRPC protocol, and security configuration | |
Integration test workflow and container tests |
License
MIT
Available Tools
2 toolsprodisco_runSandboxProDisco Run SandboxA
PREREQUISITE: Call searchTools first to discover correct API methods and parameters. Do NOT guess - search to find available APIs before writing code.
Execute TypeScript code in a sandboxed environment.
IMPORTANT: When executing new code, ALWAYS provide a scriptName to cache the script for future reuse. Use descriptive kebab-case names (e.g., "list-pods", "get-etcd-details", "check-node-resources"). Scripts are only cached when scriptName is provided.
BEST PRACTICE: When writing complex logic, data transformations, or code you are uncertain about, use mode: "test" first to validate your implementation with unit tests before running in production. This helps catch bugs early and ensures correctness.
MODES: • execute (default): Blocking execution, waits for completion. Params: code OR cached (required), scriptName (required for caching), timeout. • stream: Real-time output streaming. Params: code OR cached (required), scriptName (required for caching), timeout. • async: Start execution and return immediately with execution ID. Params: code OR cached (required), scriptName (required for caching), timeout. • status: Get status of async execution. Params: executionId (required), wait (optional). • cancel: Cancel a running execution. Params: executionId (required). • list: List active/recent executions. Params: states (optional), limit (optional). • test: Run unit tests with structured results. Params: tests (required), code (optional implementation to test), timeout. CRITICAL: test() and assert are pre-injected globals - do NOT import them, do NOT call test.run(). Just write: test("name", () => { assert.is(actual, expected); }); Available assertions: assert.is(a,b), assert.ok(val), assert.equal(obj1,obj2), assert.not(val), assert.throws(fn).
Sandbox provides console + process.env and restricts require() to an allowlist. ALLOWED IMPORTS:
require("@kubernetes/client-node") - Kubernetes API client
require("@prodisco/prometheus-client") - Prometheus queries & metric discovery
require("@prodisco/loki-client") - Loki LogQL querying
require("simple-statistics") - Statistics helpers
require("uvu") - Lightweight test runner for sandbox testing
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Execution mode: "execute" (default) - blocking execution, waits for completion; "stream" - real-time output streaming; "async" - start execution and return immediately with execution ID; "status" - get status and output of an async execution; "cancel" - cancel a running execution; "list" - list active and recent executions; "test" - run tests using uvu framework with structured results | execute |
| code | No | (execute/stream/async mode) TypeScript code to execute | |
| cached | No | (execute/stream/async mode) Name of a cached script to execute (from searchTools results) | |
| scriptName | No | (execute/stream/async mode) **REQUIRED for caching**. Name for the script (e.g., "list-pods", "get-etcd-details"). Use descriptive kebab-case names. Scripts without scriptName are NOT cached. | |
| timeout | No | (execute/stream/async mode) Execution timeout in milliseconds (default: 30000, max: 120000) | |
| executionId | No | (status/cancel mode) Execution ID from async mode response | |
| wait | No | (status mode) If true, wait for completion (long-poll) | |
| outputOffset | No | (status mode) Offset in output buffer for incremental reads | |
| states | No | (list mode) Filter by execution states | |
| limit | No | (list mode) Maximum number of results | |
| includeCompletedWithinMs | No | (list mode) Include completed executions from last N milliseconds | |
| tests | No | (test mode) Test code using pre-injected test() and assert. IMPORTANT: Do NOT import test/assert, do NOT call test.run() - they are already provided. Example: test("adds numbers", () => { assert.is(add(1,2), 3); }); Available: assert.is(a,b), assert.ok(val), assert.equal(obj1,obj2), assert.not(val), assert.throws(fn) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses sandbox restrictions, allowed imports, pre-injected globals, caching behavior, and details of each mode (blocking, streaming, async, etc.). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (PREREQUISITE, IMPORTANT, BEST PRACTICE, MODES, ALLOWED IMPORTS). Front-loaded with critical info. Some repetition of test details from schema, but overall each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage of prerequisites, usage, parameters, and restrictions for a complex tool. Lacks output examples, but no output schema is provided. Completeness is high given the constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by reinforcing caching requirement for scriptName, providing naming conventions, and detailing test globals (test, assert) beyond schema. This extra guidance elevates it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it executes TypeScript code in a sandboxed environment, specifies multiple modes, and explicitly mentions prerequisite call to searchTools, distinguishing it from the sibling tool. Verb and resource are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call searchTools first, provides best practices for caching and testing, and describes when to use each mode. No ambiguity about when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prodisco_searchToolsProDisco Search ToolsA
BROWSE API DOCUMENTATION. Find methods/types/functions by name from indexed TypeScript libraries. Use methodName to search (this searches indexed TypeScript typings only; it does NOT execute code or call external services).
INDEXED: - @kubernetes/client-node: Kubernetes API client
@prodisco/prometheus-client: Prometheus queries & metric discovery
@prodisco/loki-client: Loki LogQL querying
simple-statistics: Statistics helpers
uvu: Lightweight test runner for sandbox testing.
FILTERS: library, documentType (method|type|function|script), category
| Name | Required | Description | Default |
|---|---|---|---|
| methodName | No | Search for API members by name (methods/types/functions/scripts). Use a class/type/function/method name or keyword relevant to the libraries you configured. Searches indexed library APIs (prefers TypeScript typings; falls back to ESM JavaScript exports when typings are absent). No code execution. | |
| documentType | No | Filter by document type: "method" (class methods), "type" (classes, interfaces, enums), "function" (standalone functions), "script" (cached scripts), or "all" | all |
| category | No | Filter by category (e.g., list, create, read, delete, patch for methods; class, interface, enum for types) | |
| library | No | Filter by library: - "@kubernetes/client-node": Kubernetes API client - "@prodisco/prometheus-client": Prometheus queries & metric discovery - "@prodisco/loki-client": Loki LogQL querying - "simple-statistics": Statistics helpers - "uvu": Lightweight test runner for sandbox testing, or "all" | all |
| exclude | No | Exclusion criteria | |
| limit | No | Maximum number of results to return | |
| offset | No | Number of results to skip for pagination (default: 0) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool searches indexed TypeScript typings or falls back to ESM exports, and that it does not execute code or call external services. The behavior is transparent, though it does not describe the return format or pagination details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a bold main statement and bullet points for libraries. It is somewhat redundant because the library list appears both in the description and in the library parameter description, but overall it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no output schema), the description covers the search scope, indexed libraries, filter options, and explicitly states it does not execute code. It is sufficiently complete for an agent to understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by listing indexed libraries and explaining filter categories, but the schema already provides detailed parameter descriptions. The added value is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses API documentation for TypeScript libraries, using specific verb 'browse' and resource 'API documentation'. It differentiates from the only sibling tool by explicitly stating it does not execute code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to search for methods/types/functions by name) and implicitly contrasts with the sibling by stating no code execution. It could be more explicit about when to use the alternative tool, but the context is clear.
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. Dates show when Glama detected each change.
3 tool updates
v0.1.1- Removed
kubernetes.searchTools - Added
prodisco_runSandbox - Added
prodisco_searchTools
1 tool update
v1.0.0- First observed
kubernetes.searchTools
TDQS
The two tools have entirely distinct purposes: one searches API documentation, the other executes code. No overlapping functionality.
Both tools follow a consistent verb_noun camelCase pattern (prodisco_runSandbox, prodisco_searchTools).
Two tools is minimal, but the server's scope is narrow (sandbox execution + API discovery). The runSandbox tool is complex with many modes, justifying a small set.
The sandbox execution covers all major modes (execute, stream, async, test) and the search tool is present. Minor gaps like script management are missing, but the core workflow is complete.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Fail-closed policy guardrails for AI agents running kubectl, terraform, helm, and argocd.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
AI agent infrastructure for discovery, authorization, execution, identity, and signed receipts.
- FullmaktOAuthai.fullmakt
Credential broker for AI agents: scoped, revocable API access with policy enforcement and audit.
Related MCP Servers
- FlicenseBqualityDmaintenanceEnables managing Kubernetes clusters through natural language by providing tools to list resources, view logs, port-forward services, scale deployments, and execute kubectl operations via AI assistants.81-
- AlicenseAqualityCmaintenanceEnables AI assistants to interact with and manage Kubernetes clusters, supporting operations on pods, deployments, services, configmaps, secrets, namespaces, metrics, and events with built-in safety features for destructive actions.9181MIT
- AlicenseBqualityDmaintenanceEnables AI assistants to interact with Kubernetes clusters through 50 specialized tools for comprehensive cluster management. Supports both local kubectl and remote SSH-based execution for managing pods, deployments, services, and other Kubernetes resources.49MIT
- AlicenseBqualityBmaintenanceEnables AI agents to inspect and operate a Kubernetes cluster safely, with read-only mode and namespace allowlist for mutations.102MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/harche/ProDisco'
If you have feedback or need assistance with the MCP directory API, please join our Discord server