How do I use mcp-server-mcdev?

1. Click on "Install 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., "@mcp-server-mcdev search the wiki for data extensions" 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.

mcp-server-mcdev

by JoernBerkefeld

Overview Schema Related Servers Score Discussions

JavaScript

Local

mcp-server-mcdev

MCP (Model Context Protocol) server for Accenture SFMC DevTools (mcdev): search the project wiki offline, learn .mcdevrc.json concepts (markets, marketList, createDeltaPkg, validations), walk component checklists (e.g. journeys), and list metadata types via the installed mcdev package.

Pair with mcp-server-sfmc for AMPscript / SSJS language validation and lookups.

MCP Registry

Registered as io.github.JoernBerkefeld/mcp-server-mcdev (quickstart). Registry hosts metadata only; the server runs locally via stdio.

Verify after publish:

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.JoernBerkefeld/mcp-server-mcdev"

CI publishes npm artifacts and registry metadata using GitHub OIDC (Actions doc) — see .github/workflows/npm-publish.yml.

Related MCP server: DevDocs MCP Server

Tools

Tool	Purpose
`mcdev_search_docs`	Search bundled sfmc-devtools wiki Markdown
`mcdev_explain_config_key`	Short explanations for config topics (`markets`, `marketList`, `createDeltaPkg`, …)
`mcdev_component_checklist`	Questions + dependent metadata types (`journey`, `automation`, …)
`mcdev_list_metadata_types`	Types from `Mcdev.explainTypes()` (silent JSON mode — safe for MCP stdio)
`read_mcdev_project_config`	Read `.mcdevrc.json` with `credentials` stripped (never reads `.mcdev-auth.json`)

Connecting AI clients

VS Code (1.99+) — `.vscode/mcp.json`

{
  "servers": {
    "mcdev": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-server-mcdev@latest"]
    }
  }
}

Cursor — `~/.cursor/mcp.json` or project `.cursor/mcp.json`

{
  "mcpServers": {
    "mcdev": {
      "command": "npx",
      "args": ["-y", "mcp-server-mcdev@latest"]
    }
  }
}

Claude Desktop

~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows) — use the same mcpServers object shape as Cursor.

Windsurf

~/.codeium/windsurf/mcp_config.json — same mcpServers shape as Cursor.

Global install (faster startup)

npm install -g mcp-server-mcdev

Then use "command": "mcp-server-mcdev", "args": [] (or the binary name from this package’s bin field).

SFMC DevTools VS Code extension

The SFMC DevTools extension documents optional MCP setup for AI-assisted mcdev workflows (see that repo’s README).

Refresh bundled wiki

From this package directory, with the wiki checkout next to the repo (or set SFMC_DEVTOOLS_WIKI):

npm run bundle-wiki
npm run build

License

MIT © Jörn Berkefeld

Available Tools

5 tools

mcdev_component_checklistA

Return a structured checklist of questions and dependent metadata types for authoring or migrating SFMC components with mcdev (e.g. journey, automation).

ParametersJSON Schema

Name	Required	Description	Default
`component`	Yes	Component key, e.g. "journey", "automation".

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description bears full burden. It states the output but does not disclose read-only nature, idempotency, auth requirements, or potential side effects. As a read-only checklist, more transparency is expected.

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?

The description is a single, well-structured sentence that front-loads the purpose and includes examples. It is concise with no wasted words.

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?

Given the simple parameter and no output schema, the description is nearly complete. It specifies the return type (structured checklist) and mentions it contains questions and metadata types. A minor gap is not describing the output format further.

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?

Parameter schema coverage is 100% and includes a description. The tool description adds example values ('journey', 'automation'), which is helpful but not essential. Overall, the description adds little beyond the schema.

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 returns a structured checklist of questions and dependent metadata types for authoring/migrating SFMC components, with examples like 'journey' and 'automation'. This distinguishes it from sibling tools such as search_docs or list_metadata_types.

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 implied by the description (use when needing a checklist for a component), but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

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

mcdev_explain_config_keyA

Explain a .mcdevrc.json concept (markets, marketList, createDeltaPkg, deployment, validations, etc.) with a short summary and wiki file hints.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	Topic key or phrase. Known keys: build, createDeltaPkg, credentials, deployment, directories, marketList, markets, metaDataTypes, validations

TDQS

A3.5/5.0

Behavior3/5

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

No annotations provided; description implies a read-only, informational tool but does not detail output format, potential side effects, or access requirements. Adequate but not fully transparent.

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?

Single sentence of ~20 words, direct and no superfluous content. Efficiently conveys purpose and output.

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?

For a simple lookup tool with one parameter and no output schema, the description adequately specifies the outcome ('short summary and wiki file hints'). Minor gap: does not clarify whether output is structured or plain text.

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?

Input schema already covers parameter description with known keys; description repeats examples ('markets, marketList, etc.') but adds little new semantic value. Schema coverage is 100% so baseline 3 is appropriate.

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 uses the specific verb 'explain' and clearly identifies the resource as a '.mcdevrc.json concept' with illustrative examples. It distinguishes from siblings like mcdev_search_docs by focusing on config key explanations.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings like mcdev_search_docs or read_mcdev_project_config. Description lacks explicit context for selection or exclusions.

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

mcdev_list_metadata_typesB

List metadata types supported by the installed mcdev package (from Mcdev.explainTypes). Optional filter substring.

ParametersJSON Schema

Name	Required	Description	Default
`filter`	No	Case-insensitive filter on name or apiName.

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits like idempotency, authentication needs, output format, or any side effects. The tool is likely read-only but this is not stated.

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 a single sentence that front-loads the purpose and includes key details (source, filter). It is concise without wasted words, but could be slightly more informative.

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?

For a simple tool with one optional parameter and no output schema, the description covers the main action and filter. However, it omits what the output contains (e.g., names, descriptions), leaving the agent to infer.

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 100% with a clear description for 'filter'. The description adds 'Optional filter substring' which adds minimal value beyond the schema. Baseline of 3 is appropriate.

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 lists metadata types from the mcdev package, specifies the source (Mcdev.explainTypes), and mentions an optional filter. It distinguishes from siblings like search_docs or read_mcdev_project_config.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus its siblings, nor any when-not-to-use instructions. The description only states what it does without contextual usage advice.

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

mcdev_search_docsB

Search bundled sfmc-devtools wiki Markdown (from GitHub wiki) for mcdev configuration, commands, markets, createDeltaPkg, build, validations.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results (default 8).
`query`	Yes	Search query (keywords).

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description bears full burden. Only states 'Search ... for ...' without disclosing read-only nature, result format, or any side effects. Minimal behavioral insight beyond the action itself.

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?

Single sentence of 19 words, no redundancy. Front-loaded with action and resource. Lists examples but remains focused; could be slightly improved by removing the inline example list for brevity.

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

Completeness2/5

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

Given no output schema and simple parameters, description fails to explain what results look like, how to interpret them, or any pagination. For a search tool, more detail on output would be expected.

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 already fully describes both parameters (query and limit) with types and constraints, so description adds no additional semantic value. Baseline score of 3 is appropriate.

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?

Clearly states 'Search' verb and specifies the resource 'bundled sfmc-devtools wiki Markdown'. Lists specific topics (configuration, commands, etc.), distinguishing it from sibling tools that target individual config keys or component checklists.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings like mcdev_explain_config_key or mcdev_component_checklist. Does not mention when not to use it or any prerequisite conditions.

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

read_mcdev_project_configA

Read .mcdevrc.json from a workspace path (never reads .mcdev-auth.json). Use to inspect markets and marketList with the assistant.

ParametersJSON Schema

Name	Required	Description	Default
`workspaceRoot`	Yes	Absolute path to the mcdev project root containing `.mcdevrc.json`.

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states the file read and excludes another, but lacks details on return structure, error handling, or side effects. Minimal behavioral disclosure.

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?

Two sentences, front-loaded with core action, no redundant information.

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?

Given no output schema, description could state what the tool returns (e.g., parsed JSON). It adequately covers the basic purpose but lacks completeness on return value and error cases.

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 100% and the single parameter is well-described in the schema. Description adds context about file usage but no additional parameter semantics beyond 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?

Description clearly states 'Read `.mcdevrc.json`' with resource and scope, and clarifies it never reads `.mcdev-auth.json`. It specifies usage to inspect markets and marketList, but does not explicitly differentiate from sibling tools.

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?

Provides clear context on when to use (inspect markets/marketList) and what it does not read (avoiding auth file), but does not mention alternatives or when not to use among siblings.

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.

5 tool updatesv0.1.1Jul 25, 2026
- First observedmcdev_component_checklist
- First observedmcdev_explain_config_key
- First observedmcdev_list_metadata_types
- First observedmcdev_search_docs
- First observedread_mcdev_project_config

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: searching docs, explaining config keys, providing component checklists, listing metadata types, and reading project config. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent 'mcdev_verb_noun' pattern using snake_case, making it predictable and easy to understand.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose (mcdev assistant). Each tool covers a key functionality without being excessive or insufficient.

Completeness4/5

Coverage is solid for the intended domain: documentation, config explanation, metadata listing, component checklists, and file reading. A minor gap could be a tool for writing or validating config, but overall it's comprehensive.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

LLMemoryOAuth
io.github.meir-may
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Search Knowledge & Memory
2
agent-wikiOAuth
com.getagentwiki
Hosted markdown project wikis your team's AI assistants read, search, and update over MCP.
Documentation Access Note Taking Workplace & Productivity
1
Hint-Services-obsidian-github-mcp
ai.smithery
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Note Taking Version Control File Systems
29
mcp
com.skopik
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Agent Orchestration Knowledge & Memory Search
2

Related MCP Servers

Seta MCP
Developer Tools Documentation Access Search
techformist
A
license
Not graded
quality
C
maintenance
Enables Salesforce developers to create code and configuration using local documentation, with optional semantic search.
Updated a year ago (2025-06-14 06:25 UTC)
15
1
MIT
DevDocs MCP Server
Documentation Access Search
emaland
A
license
Not graded
quality
C
maintenance
Enables AI assistants like Claude to search and retrieve technical documentation from a local DevDocs instance for hundreds of programming languages and frameworks.
Updated a year ago (2025-08-26 17:30 UTC)
1
MIT
sfskills-mcp
Developer Tools Knowledge & Memory Documentation Access
PranavNagrecha
F
license
Not graded
quality
C
maintenance
Provides live-org context for AI assistants with tools to search skills, agents, templates, decision trees, and query Salesforce metadata (Apex, LWC, objects, fields, etc.) via MCP.
Updated 3 days ago (2026-09-03 21:46 UTC)
16
-
sf-architect-mcp
RAG Systems Web Scraping Documentation Access
morettimarco
F
license
Not graded
quality
D
maintenance
Scrapes, indexes, and serves Salesforce Architect documentation locally, enabling fast offline RAG-powered search and retrieval for AI coding assistants.
Updated 5 months ago (2026-04-04 11:49 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/JoernBerkefeld/mcp-server-mcdev'

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

mcp-server-mcdev

MCP Registry

Tools

Connecting AI clients

VS Code (1.99+) — .vscode/mcp.json

Cursor — ~/.cursor/mcp.json or project .cursor/mcp.json

Claude Desktop

Windsurf

Global install (faster startup)

SFMC DevTools VS Code extension

Refresh bundled wiki

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

VS Code (1.99+) — `.vscode/mcp.json`

Cursor — `~/.cursor/mcp.json` or project `.cursor/mcp.json`