Claude Architect · Ders

Topluluk ve Özel Sunucular

Standart entegrasyonlar için kanıtlanmış sunucuları tercih edin.

Topluluk ve Özel Sunucular, CoddyKit'te ücretsiz bir Claude Architect dersidir. Bu, 4 dersinin 4. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, Claude Architect öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Claude Architect kursu toplamda 4 dersten oluşur.

Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.

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.

Sıkça Sorulan Sorular

“Topluluk ve Özel Sunucular” dersi ücretsiz mi?

Evet — “Topluluk ve Özel Sunucular” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve Claude Architect kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Claude Architect kursu toplamda 4 dersten oluşur.

“Topluluk ve Özel Sunucular” dersinde ne öğreneceğim?

Standart entegrasyonlar için kanıtlanmış sunucuları tercih edin. Claude Architect ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

Claude Architect öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te Claude Architect, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 4. dersidir.

“Topluluk ve Özel Sunucular” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu Claude Architect dersinde kod yazıp çalıştırabilir miyim?

Evet. Her Claude Architect dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

← Claude Architect Sayfasına Dön