Claude Architect · 강의

커뮤니티 서버와 사용자 지정 서버

표준 통합에는 검증된 서버를 우선 사용합니다

커뮤니티 서버와 사용자 지정 서버은(는) CoddyKit의 무료 Claude Architect 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Claude Architect 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Claude Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

The Build-vs-Adopt Decision

Every MCP integration starts with a fork in the road: do you adopt a community server someone already built, or write a custom one from scratch?

The exam-grade default is clear: prefer proven community MCP servers for standard integrations. Reach for a custom server only when your need is genuinely non-standard.

This lesson teaches you to make that call like an architect — weighing maintenance, security, and capability, not just lines of code.

What an MCP Server Actually Provides

Before choosing, recall what a server exposes. MCP servers offer three primitives:

Tools — actions the model can invoke (create an issue, run a query).
Resources — read-only data and context (schemas, catalogs, files).
Prompts — reusable templates.

A "standard integration" — GitHub, Postgres, Slack, filesystem — almost always maps onto these primitives in a way the community has already solved. That overlap is exactly why adopting beats rebuilding.

Why Proven Servers Win for Standard Cases

A widely-used community server is not just code — it's accumulated production hardening:

Edge cases discovered by hundreds of users and already patched.
Auth flows, pagination, and rate-limit handling battle-tested.
Tool descriptions refined over time — and descriptions are the primary mechanism the model uses to select tools.
Ongoing maintenance you don't have to staff.

Rebuilding a GitHub or Postgres server from scratch means re-discovering every bug the community already fixed.

Adopting a Community Server

Adoption is usually a config entry, not an engineering project. You register the server in your MCP config and the model gains its tools and resources.

Note the scope choice: a .mcp.json at project root is shared via version control, so the whole team gets the same integration.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Secrets: Never Commit Tokens

Adopting a server safely means handling credentials correctly. Inject secrets through environment variables like ${GITHUB_TOKEN} — never hard-code a token into .mcp.json, because that file is committed to VCS.

This applies whether the server is community or custom. The config is shared; the secret is not.

# Provide the secret at runtime, not in the committed config
export GITHUB_TOKEN="ghp_your_real_token_here"

# .mcp.json references ${GITHUB_TOKEN} — the literal token never lands in git

Project vs User Scope

Where you register a server changes who gets it:

Project scope — .mcp.json in the repo, shared via VCS. Use it for integrations the whole team needs (the shared Postgres server, the team's GitHub server).
User scope — ~/.claude.json, personal and NOT shared. Use it for your own credentials or experimental servers.

For a standard, team-wide integration, a proven server at project scope is the clean answer.

When Custom Is Justified

Custom is the right call when no proven server fits — usually because the integration is proprietary or non-standard:

An internal in-house API or service no community server targets.
Domain-specific business logic that must live behind the tool.
A need to expose structured, recoverable errors the way only you can model.

The decision rule: standard integration → adopt; proprietary/novel surface → build.

Custom Servers Demand Good Tool Descriptions

When you do build, you inherit responsibilities a mature community server already discharged. Chief among them: tool descriptions, the primary selection mechanism.

A good description states purpose, return values, input formats with examples, and applicability boundaries. Minimal or ambiguous descriptions cause the model to misroute calls.

@tool(
    description=(
        "Fetch an internal order by its UUID. "
        "Returns order status, line items, and total in cents. "
        "Input: order_id as a 36-char UUID, e.g. '3f2a...'. "
        "Use only for internal warehouse orders; not for marketplace orders."
    )
)
def get_internal_order(order_id: str) -> dict:
    ...

Custom Servers Must Return Structured Errors

A generic "Operation failed" blocks recovery — the model can't tell a transient timeout from a permission denial. A proven server typically already returns structured errors; your custom one must too.

Emit a structured shape: an isError flag plus an errorCategory (transient / validation / business / permission), isRetryable, a message, the attempted query, and any partial results. This is what enables intelligent routing and retry decisions.

return {
    "isError": True,
    "errorCategory": "transient",
    "isRetryable": True,
    "message": "Upstream warehouse API timed out after 5s",
    "attempted_query": {"order_id": order_id},
    "partial_results": []
}

Don't Over-Pack a Custom Server

A tempting anti-pattern: cram every internal endpoint into one giant custom server. Resist it.

Selection reliability degrades as tools accumulate — 4–5 tools per agent is optimal; 18+ noticeably degrades selection. Scope each server to a coherent role, and let the model see only the tools that fit the task.

This is another reason adoption is attractive: a focused community server is already scoped, where a sprawling custom one tempts you to over-pack.

A Hybrid Is Normal

Most real architectures mix both. You adopt proven servers for the commodity surface and build a thin custom server only for the proprietary slice.

Community GitHub server for repo actions.
Community Postgres server for the read-only catalog (exposed as Resources).
Custom billing server for your in-house pricing logic and structured errors.

The skill isn't picking a side — it's drawing the line at "standard vs proprietary" for each integration.

Quick Check: Choosing a Server

You're architecting an agent that needs to read issues and open pull requests on GitHub — a completely standard integration. A mature, widely-used community GitHub MCP server exists. What's the best move?

Recap: Adopt by Default, Build with Intent

Key takeaways:

Prefer proven community MCP servers for standard integrations — you inherit hardening, maintenance, and refined tool descriptions.
Build custom only for proprietary or non-standard surfaces (internal APIs, domain logic).
When you build, you own the hard parts: rich tool descriptions (the selection mechanism) and structured errors (isError + errorCategory + isRetryable).
Keep servers scoped — 4–5 tools is optimal; avoid sprawling 18+ tool servers.
Share via .mcp.json at project scope; inject secrets with env vars like ${TOKEN} — never commit them.

Adopt by default, build with intent.

자주 묻는 질문

“커뮤니티 서버와 사용자 지정 서버” 강의는 무료인가요?

네 — “커뮤니티 서버와 사용자 지정 서버” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Claude Architect 강의 전체를 잠금 해제할 수 있습니다. Claude Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

“커뮤니티 서버와 사용자 지정 서버”에서 뭘 배우나요?

표준 통합에는 검증된 서버를 우선 사용합니다 브라우저에서 직접 실행하는 실습 코드로 Claude Architect을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Claude Architect을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Claude Architect은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“커뮤니티 서버와 사용자 지정 서버” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Claude Architect 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Claude Architect 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Claude Architect(으)로 돌아가기