feat: allow reading config from a file and support toolMetadataOverrides MCP-292 MCP-300

[himanshusinghs]

Proposed changes

This PR introduces support for reading configuration from a file specified either by command line argument --config or by environment variable MDB_MCP_CONFIG. The configuration from the file is used as the base on top of which configuration from environment variables are applied and then config from CLI arguments. The precedence order is provided and maintained by yargs-parser itself.

Furthermore, we've added a new config property called toolMetadataOverrides which allows specifying name and description overrides for tool. It is basically a map of internal tool name to the override object.

{
  "toolMetadataOverrides": {
    "insert-many": {
      "name": "insertMany",
      "description": "..."
    },
    "delete-many": {
      "name: "deleteMany"
      // either property (name, description) is optional
    }
  }
}

We expect users to be using config file for specifying this configuration and ensuring that access to the config is locked down to the user running the MongoDB MCP Server. Doing the same through command line arguments is gruesome but possible and not encouraged at all. An example:

CLI Arguments (nested keys separated by dot)

npx mongodb-mcp-server \
--toolMetadataOverrides.insert-many.name="insertMany" \
--toolMetadataOverrides.insert-many.description="..."

Checklist

• I have signed the MongoDB CLA

[Copilot]

Pull Request Overview

This PR introduces support for reading configuration from a file and adds the ability to override tool metadata (name and description) through user configuration. The changes enable users to customize tool names and descriptions while maintaining internal tool identification.

Key Changes:

• Added toolMetadataOverrides configuration option to UserConfig schema
• Refactored all tools to use internalName and internalDescription properties alongside computed name and description getters
• Implemented config file loading via CLI argument (--config) and environment variable (MDB_MCP_CONFIG)

Reviewed Changes

Copilot reviewed 49 out of 49 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/common/config/userConfig.ts	Added toolMetadataOverrides field to UserConfig schema
src/common/config/createUserConfig.ts	Added config file loading support via yargs-parser
src/tools/tool.ts	Refactored to support internal vs configured tool metadata with getters
src/tools/mongodb/connect/connect.ts	Updated to use new internal metadata properties and override logic
tests/unit/common/config.test.ts	Added comprehensive tests for config file loading and precedence
tests/integration/tools/mongodb/connect/connect.test.ts	Added integration tests for metadata override functionality
tests/fixtures/*.json	Added fixture files for config loading tests
src/tools/mongodb/**/*.ts	Updated all MongoDB tools to use internalName/internalDescription
src/tools/atlas/**/*.ts	Updated all Atlas tools to use internalName/internalDescription
src/tools/atlasLocal/**/*.ts	Updated all Atlas Local tools to use internalName/internalDescription
tests/unit/toolBase.test.ts	Updated test tool to use new property names
tests/integration/**/*.ts	Updated test tools to use new property names

[coveralls]

Pull Request Test Coverage Report for Build 19627566401

Details

• 137 of 137 (100.0%) changed or added relevant lines in 44 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.3%) to 80.395%

---

Totals
Change from base Build 19575600461:	0.3%
Covered Lines:	6446
Relevant Lines:	7922

---

💛 - Coveralls

[fmenezes]

please update README.md

[fmenezes]

please add validation to guard rail for name collision

[gagik]

do we really want to make it possible to rename tool mid-way?
This really makes our state less mutable and more messy. If someone wants to do this, they should look into using our tool-related hooks and defining custom tools as they likely need custom behavior at this point.
I'd prefer an approach where we only set the overrides on initalization, in which case we don't have getters and separate "internal"/"default" fields.

[himanshusinghs]

We are already renaming tools midway. What the change is suggesting is that the rename should respect the tool metadata overrides.

[gagik]

subjective but i like this is in README, I really hate having to click extra things to find more crucial information, it's also worse for the LLM agents that might be reading this. I think we can make the table more compact by combining the ENV and -- variable options into 1 column

[himanshusinghs]

Tabling this PR for now until we have more clarity on how we want to proceed with this.