Verify it actually loaded: config that fails silently

Claude Code

The Claude Code is actually two commands that address most of the needs, each of them answers a separate question.

claude mcp list

The first command lists all the servers you configured and runs health-check on those that are approved (more on that in a sec). If the configuration file can't be parsed, it also prints diagnostic information with the name of the file:

MCP config diagnostics ✘
…
[Failed to parse] Project config (shared via .mcp.json)
Location: /path/to/repo/.mcp.json
 └ [Error] MCP config is not a valid JSON

In such scenario the CLI returns exit code 0 (as it's not really an error) and so if you run it from CI for example, it won't return an error. The only thing that is missing from the output of the first command is the scope — if you want to know what it is on a specific server, the second command claude mcp get <name> can help with that.

In the docs, we also have a few slash commands that are connected with the configuration:

• /doctor — according to the docs it "checks installation health, including duplicate or leftover installs, PATH problems, and unparseable settings files"

• /context — returns information about what's in the context window and how much memory is used

• /memory — shows memory files that are being used

• /hooks — shows hook configuration for tool events

There's also separate claude doctor command that's actually more narrow than /doctor, it seems to be about the auto-updater checking only (its help says "Check the health of your Claude Code auto-updater"), but when we run it with piped output it doesn't print anything so it's not really useful.

It's also worth to know that in case of a syntactically valid .mcp.json file, there are no tools until you approve it (which makes sense because if you have a shared config in the repo, it shouldn't have permissions to run processes on its own). The first command prints then for example:

demo: echo hi - ⏸ Pending approval (run `claude` to approve)

It's not an error, it's just a security feature so you won't accidentally approve the config file that lives in the project repo. But if you want to proceed with this server, you need to run the CLI interactively and approve the config there, or use the separate reset command to clear the project's decisions so you can start fresh:

claude mcp reset-project-choices

Codex CLI

6 tools compared, and the only one that comes with a specific flag for it is Codex's CLI with its doctor subcommand (you run it with codex doctor).

codex doctor

It lists the configuration file it read, tells if parsing was successful and what model (and provider) it resolved to at the end.

Configuration
  ✓ config       loaded
      model                    gpt-5.1-codex · openai
      …
      config.toml              ~/.codex/config.toml
      config.toml parse        ok

But don't be too happy about the "ok" message, the "parse" part can be a bit too lenient — for example we changed the configuration file to have modl instead of model in the key and still the doctor said it's ok (the configuration is valid TOML, it just ignored an unknown key). But that's why there's --strict-config, which by help output will "error out when config.toml contains fields that are not recognized by this version of Codex" — and it works as advertised:

codex exec --strict-config "say hi"

Error loading config.toml:
~/.codex/config.toml:4:1: unknown configuration field `modl`
  |
4 | modl = "typo-key"
  | ^^^^

It points to the file, line, column and even draws a caret under the offending key — so after every configuration change you can just run it once to make sure you didn't miss a setting that has been removed without a notice. Just keep in mind that this flag is not supported by all subcommands:

$ codex doctor --strict-config
error: unexpected argument '--strict-config' found

$ codex mcp list --strict-config
error: unexpected argument '--strict-config' found

$ codex --strict-config mcp list
Error: `--strict-config` is not supported for `codex mcp`

So you need to use codex exec. Also, when you run it — before it does any work — it shows you what model (and provider) it resolved to, what approval policy was applied and if it runs in a sandbox mode. That way, if a profile or -c option doesn't work you can see that in the beginning instead of seeing three tool calls.

GitHub Copilot CLI

Copilot was the most transparent of the 6 tools we compared in terms of what it couldn't use. There are 2 commands responsible for that:

• listing skills:

copilot skill list

• listing MCP servers:

copilot mcp list

The first one is smart enough to not only show the skills but also present a structure, grouping them by the scope (project, personal, and built-in) and listing the files it doesn't want to include with their paths. For example:

✖ The following skills failed to load:
  • .github/skills/nofrontmatter/SKILL.md: missing or malformed YAML frontmatter

And here's the most important part — help command is very transparent too and lists all the locations it looks in to find skills:

Project   .github/skills/, .agents/skills/, or .claude/skills/
Personal  ~/.copilot/skills/ or ~/.agents/skills/

The second command is smart enough to split the output into "User servers" and "Workspace servers" sections. So if you go wrong with the scope, you'll be able to see it as a server under the wrong section. And if you have a broken workspace config, it will inform you about that and then just ignore it:

Warning: skipping workspace MCP config "/path/to/repo/.mcp.json" because it is malformed:
Invalid JSON: trailing comma at line 3 column 50

If you look at the example above, you can see it complains about .mcp.json file and provides the JSON parse error with line and column number. But what's crucial here is that you should focus on the message itself and not on the exit code — it's 0 so the command exits successfully. In other words — it doesn't just ignore the single entry but the entire "Workspace servers" section, so the absence is the other half of this signal

The sources for the MCP configuration are:

• ~/.copilot/mcp-config.json (for the user)

• .mcp.json or .github/mcp.json (for the workspace)

But it doesn't mean that if it's loaded, it's good. We've tried to load a skill with an unclosed quote in its description and it was loaded anyway — with the mangled description:

broken-yaml - unterminated "quote

— no warning whatsoever. Which means that this is how the skills silently stop working, so keep an eye on their descriptions when using the skill list command, instead of counting rows

Finally — the help for the plugins command is a bit misleading as it describes plugins as a unified view of plugins, MCP servers, skills, instructions, and language servers. On version 1.0.77, it says this feature isn't implemented:

$ copilot plugins list
The plugins command is not available.

$ copilot --experimental plugins list
The plugins command is not available.

So for now, if you want to explore this "unified view", you'll need to use skill list and mcp list commands

Cursor

There's an mcp command which you can run in your terminal to list all the MCP servers available.

cursor-agent mcp list

It will output one line per server with its state, for example:

demo: not loaded (needs approval)

The approval gate is a real one here, similar to how it works in Claude Code. You have an mcp enable command which approves a server on your machine and an mcp disable command which removes it from consideration so that it doesn't appear in the prompt ever. When it comes to the mcp list-tools command, it will list all the tools that a server has with their argument names, but if you were to run it against a non-approved server, it will just tell you that the server is not approved.

Which, if you ask us, is the sharpest gotcha of using MCP in Cursor, we tried it against 4 configurations:

• a proper .cursor/mcp.json

• the same file but with closing braces removed

• a file in which the mcpServers key was replaced with servers

• no config file at all

And what's interesting is that in the last two cases it displays exactly the same output saying that there are no MCP servers configured and that it looks in .cursor/mcp.json and ~/.cursor/mcp.json.

No MCP servers configured (expected in .cursor/mcp.json or ~/.cursor/mcp.json)

So, it's a single string which covers both a situation of having a malformed config file and one of not having any config at all. If you ever see this message in your terminal, be sure to treat it as a hint that you should investigate rather than a verdict, maybe the file is there but you've used a different key name or have put it in a different location. Another thing worth noting is that if you remove the closing braces from the config file, the tool will still find the server and not say anything.

We also wanted to touch the rules, we don't have a CLI command for them so there's no way to know which ones are loaded from the terminal. To check it you need to:

• make sure that the files are really .mdc by replacing the extension with .mdc (according to the docs files under .cursor/rules directory ending with .md are ignored as they don't have a frontmatter)

• make sure you haven't changed any keys in the frontmatter, it should be alwaysApply: true for session-wide rules, globs for rules bound to files, and some description for relevance-based rules; if none of these is in place, the rule will only run on an explicit @-mention

If you want to make sure that everything's all good, you can check the Customize → Rules panel in your editor which lists every rule with its status; from the terminal you can always use the canary

Antigravity CLI

You can list the antigravity surfaces through the list subcommands, there's no separate view for it, if you see an agent there it means it works. For example:

agy agents
agy plugin list

Basically you need to just run one of these and check if what you expect is there. In our tests we checked it on 1.1.9 version and it worked as follows:

• We created a subagent (with the correct syntax) in .agents/agents/

Then we run agy agents and we can see that there's a header and then there's nothing, no error being thrown, not even a message about this file, just an empty line where the agent should be. This is the indication you need to understand that if you don't see something in the output of these commands it means it's not loaded, so you should check the path rather than the content of the file. In terms of paths, they're all described in the tool's own bundled docs:

• customisations — .agents/ for project-level agents customisations

• skills — inside .agents/, skills/{skill_name}/

• rules — inside .agents/, rules/ (or GEMINI.md / AGENTS.md as freestanding files); the rule paths it names are GEMINI.md, AGENTS.md and .agents/rules/*.md

• plugins — inside .agents/, plugins/{plugin_name}/

The gotcha: 1.1.9 has no mcp subcommand at all, if you try to get help for it you'll see the general help instead of an error, which can be misleading, so you might think it exists and you use the flags incorrectly. The subcommands that actually exist:

• agent

• agents

• changelog

• help

• install

• models

• plugin

• plugins

• update

Also you can use --log-file flag to change where the CLI's logs are saved and then just tail it during the session. Personally we haven't tested any scenarios with a messed-up configuration, so how it behaves in such case we don't know; we were only testing the above-listed listing commands

Kimi Code CLI

kimi mcp list

MCP config file: /Users/you/.kimi/mcp.json
No MCP servers configured.

As you can see in the output above the MCP server list of Kimi Code is the only subcommand that shows what file it uses before outputting its content. It outputs the path of the MCP config file and then "No MCP servers configured." message. The path is important because once you know from where a file comes it's often half of the battle:

• if you see that the output is empty next to the file you were modifying, that means you need to examine its content to find the issue

• if you see that the output is empty next to an unknown path you probably edited a wrong file

kimi mcp test <server>

There's also the mcp test subcommand which is a per-server test; as described in the help it checks if there's a connection with the server and lists all of the available tools. It might be useful when for example you see that Kimi Code listed a server but the model never uses its tools, then it'd be good to run this command against it to make sure everything is fine with this server.

When it comes to the in-session experience, there's a slash command which lists all connected servers and all of their tools as well, you can use it if you want to check sth similar during a session. But remember that as mentioned in the docs, servers are being initialised asynchronously after starting the shell UI so make sure to wait for some time before you can be certain that the list is actually empty.

The MCP config lives at ~/.kimi/mcp.json; the general config is a separate TOML file, ~/.kimi/config.toml. You can also point Kimi Code to a different one using --config-file flag or even use an inline configuration providing it with TOML or JSON directly (using --config) which is useful if you want to try some change without altering the file you're using on a daily basis. There's also a debug flag that enables verbose output.

Before proceeding just make sure what software you have installed as they both are called kimi-cli:

• Python package which is being deprecated, work in progress on a new version of Kimi Code CLI

• new version of Kimi Code CLI which is a complete rewrite

This means that both of them use the same config directory so if you examine ~/.kimi contents it doesn't tell anything about which one you have installed. The info subcommand outputs the version and the protocol number so make sure to run it before doing anything else to find that out.

• for Python package (1.48.0):

  • kimi-cli --version

  • kimi-cli info

  • kimi-cli mcp list

  • kimi-cli --help

• from the above help and Kimi Code CLI docs:

  • kimi-cli mcp test

  • in-session slash command

  • --config flag

  • --config-file flag

  • --debug flag

• for Kimi Code CLI (which we didn't use during this process so no version number attached):

  • kimi --version

  • kimi info