How do I use mcp-server-mcdev?

1. Click on "Deploy 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 Source Related Servers Discussions Admin

TypeScript

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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-09-09 18:05 across 5 tools

Disambiguation4/5

Each tool has a distinct core purpose, but mcdev_search_docs and mcdev_explain_config_key both cover configuration concepts like markets and createDeltaPkg, so an agent could occasionally hesitate between them. The other tools are clearly separated by function: checklist, metadata types, and project config reading.

Naming Consistency4/5

Most tools follow a clear mcdev_verb_noun pattern, which is predictable and readable. Minor deviations exist: read_mcdev_project_config breaks the prefix convention, and mcdev_component_checklist is a noun phrase rather than a verb-led name.

Tool Count5/5

Five tools is a well-scoped set for a documentation and configuration-assistance server. Each tool covers a meaningful capability without bloat or redundancy.

Completeness4/5

The tool surface covers the main assistant workflows: searching docs, explaining config keys, getting authoring checklists, listing metadata types, and reading project config. It lacks direct execution or write operations, but that appears outside the server's stated purpose as a knowledge and inspection helper.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

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)
6 npm
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 16 days ago (2026-09-03 21:46 UTC)
17
-
sf-architect-mcp
RAG Systems Web Scraping Documentation Access
morettimarco
F
license
A
quality
C
maintenance
Scrapes, indexes, and serves Salesforce Architect documentation locally, enabling fast offline RAG-powered search and retrieval for AI coding assistants.
Updated 6 months ago (2026-04-04 11:49 UTC)
9
-

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

Related MCP Connectors

Related MCP Servers

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

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