Skip to main content
Glama

configure_server

Destructive

Install an MCP server package, add it to your client configuration, and validate it works. Supports npm, pip, Docker, and HTTP transport servers. Performs preflight checks with dry-run option to avoid broken configs.

Instructions

Install an MCP server package, add it to your client config, and verify it works.

This is the main action tool. It handles the complete setup flow:

  1. Installs the package via npm/pip/docker (fails fast if install fails)

  2. Validates by spawning the server and calling list_tools()

  3. Writes the server entry to your MCP client config file(s) only if validation passes

For HTTP transport servers (streamable-http, SSE), the install step is skipped and the server is configured via the mcp-remote bridge. Pass the server URL as package_identifier (e.g. https://mcp.vercel.com) or set registry_type to "streamable-http", "http", or "sse".

Get the package_identifier and registry_type from search_servers results or scan_project recommendations.

If validation fails, the config is NOT written to avoid broken entries. The user should fix the issue and retry.

When dry_run=True, mcp-tap performs install + validation preflight but does NOT write any client config, lockfile, or telemetry acceptance event.

Args: server_name: Name for this server in the config (e.g. "postgres"). This is how it appears in list_installed and other tools. package_identifier: The package to install and run. Get this from search_servers results (e.g. "@modelcontextprotocol/server-postgres" for npm, "mcp-server-git" for pypi), or a URL for HTTP transport servers (e.g. "https://mcp.vercel.com"). clients: Target MCP client(s). Comma-separated names like "claude_desktop,cursor", "all" for every detected client, or empty to auto-detect the first available. registry_type: Package source — "npm" (default), "pypi", "oci", "streamable-http", "http", or "sse". version: Package version. Defaults to "latest". env_vars: Environment variables the server needs, as comma-separated KEY=VALUE pairs (e.g. "POSTGRES_URL=postgresql://...,API_KEY=sk-..."). Check search_servers results for env_vars_required. scope: "user" for global config (default), "project" for project-scoped config (e.g. .cursor/mcp.json in the project dir). project_path: Project directory path. Required when scope="project". feedback_query_id: Optional query_id from scan/search telemetry event so accepted recommendations can be linked to shown rankings. dry_run: When True, run preflight only (install/validate) and return what would be written without touching client config files.

Returns: Result with: success, install_status, config_written, validation_passed, tools_discovered. Multi-client calls also include per_client_results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
server_nameYes
package_identifierYes
clientsNo
registry_typeNonpm
versionNolatest
env_varsNo
scopeNouser
project_pathNo
feedback_query_idNo
dry_runNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

The description details the three-step process, validation on failure, dry-run behavior, and HTTP transport behavior, far exceeding the single destructiveHint annotation.

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 long but well-organized with numbered steps and parameter bullets. Some redundancy exists, but overall it is efficient and 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?

The description covers the complete workflow, edge cases (dry run, HTTP transport, validation failure), parameter usage, and return values, making it self-sufficient for a complex 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?

With 0% schema coverage, the description fully explains all 10 parameters, including sources and defaults, providing everything an agent needs to invoke the tool correctly.

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 installs an MCP server package, adds it to client config, and verifies it. It calls itself 'the main action tool', which distinguishes it from sibling tools like remove_server or list_installed.

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

Usage Guidelines4/5

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

The description explains when to use this tool (for complete setup) and provides context for HTTP servers, but does not explicitly contrast with alternatives or state when not to use it.

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

Install Server

Other Tools

Latest Blog Posts

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/felipestenzel/mcp-tap'

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