Agent skills vs MCP servers vs rules files में अंतर

Agent skills, MCP servers और rules files के बीच अंतर: संक्षिप्त उत्तर

Agent skills, MCP servers और rules files, ये तीनों ही एक coding agent के सामने जानकारी प्रस्तुत करते हैं। जानकारी के कार्य के आधार पर सही विकल्प चुनें। MCP (Model Context Protocol) उन डेटा के लिए है जो अगली बार देखने पर बदल सकता है। Skill उस प्रक्रिया के लिए है जिसे आप आज लिख सकते हैं और छह सप्ताह बाद भी वह सही रहेगी। Rules file उन कुछ तथ्यों के लिए है जो हर session में लागू होने चाहिए।

इस चयन की एक कीमत है, और वह कीमत context है। जिस instruction की agent को आवश्यकता नहीं थी, उस पर खर्च किया गया प्रत्येक token उस code के लिए अनुपलब्ध हो जाता है जिसे वह पढ़ रहा है। यह एक ऐसा token भी है जिसे आप हर turn पर दोबारा चुकाते हैं, क्योंकि हर request के साथ पूरा context window फिर से भेजा जाता है। इसलिए उपयोगी प्रश्न यह नहीं है कि कौन सा mechanism काम कर सकता है। अधिकांश दिनों में तीनों ही काम कर सकते हैं। प्रश्न यह है कि जब वे idle होते हैं, तो उनमें से किसकी लागत सबसे कम होती है।

उपयोग से पहले प्रत्येक की लागत

ये तीनों अलग-अलग समय पर लोड होते हैं, और यही समय का अंतर ही मुख्य अंतर है।

एक rules file हर सत्र (session) की शुरुआत में पूरी तरह लोड हो जाती है, चाहे वह प्रासंगिक हो या न हो। Claude Code हर बातचीत की शुरुआत में CLAUDE.md को पढ़ता है और लंबाई की परवाह किए बिना इसे पूरा लोड करता है। दस्तावेजी लक्ष्य प्रति फाइल 200 पंक्तियों से कम का है, क्योंकि लंबी फाइल अधिक context का उपयोग करती है और उसका पालन कम विश्वसनीयता से होता है। ये दोनों प्रभाव एक ही दिशा में काम करते हैं, यही कारण है कि 900 पंक्तियों वाली rules file बेकार होने से भी बदतर है।

एक skill दो चरणों में लोड होती है। स्टार्टअप पर केवल प्रत्येक SKILL.md के frontmatter से description पंक्ति ही context में आती है, ताकि मॉडल को पता रहे कि skill मौजूद है और यह मोटे तौर पर कब लागू होती है। जब skill को invoke किया जाता है, तब उसका मुख्य भाग (body) लोड होता है। इसलिए, 400 पंक्तियों के संदर्भ दस्तावेज़ की लागत तब तक लगभग शून्य होती है जब तक कि उसकी आवश्यकता न हो।

MCP server पहले महंगा हुआ करता था, और यहीं पर अधिकांश तुलनाएं जो आप पढ़ेंगे, अब पुरानी हो चुकी हैं। वर्तमान Claude Code में tool search डिफ़ॉल्ट रूप से चालू रहता है। सत्र की शुरुआत में केवल tool के नाम और server का instructions field लोड होते हैं, और पूर्ण JSON (JavaScript object notation) schemas को तब तक के लिए टाल दिया जाता है जब तक कि Claude उन्हें खोज न ले। अब एक server जोड़ने पर शुरुआत में हजारों tokens खर्च नहीं होते। इसकी अभी भी कुछ लागत है, और उन configurations में जहाँ tool search बंद है, यह अभी भी शुरुआत में पूरी लागत लेता है।

[
  {
    "label": "Rules file, 200 lines",
    "at_startup": "2,500",
    "after_use": "2,500"
  },
  {
    "label": "Skill, 12 KB body",
    "at_startup": 40,
    "after_use": "3,000"
  },
  {
    "label": "MCP server, tool search on",
    "at_startup": 500,
    "after_use": "3,200"
  },
  {
    "label": "MCP server, tool search off",
    "at_startup": "4,500",
    "after_use": "4,500"
  }
]

ये अनुमान हैं, आपकी मशीन से लिए गए माप नहीं। ये प्रत्येक तंत्र द्वारा लोड किए गए टेक्स्ट के आकार से आते हैं, जो लगभग चार वर्ण प्रति token है: 200 पंक्तियों वाली rules file लगभग 10 KB की markdown होती है, एक skill description लगभग 160 वर्णों की होती है, और बारह tools को expose करने वाला एक server लगभग 18 KB का schema और 2 KB का instructions block लेता है। Claude Code प्रत्येक tool description और प्रत्येक server instructions field को 2 KB पर truncate कर देता है, इसलिए उस हिस्से की एक ऊपरी सीमा है। अगला भाग आपको अपने वास्तविक आंकड़े पढ़ना सिखाएगा।

पहली दो पंक्तियों को एक साथ पढ़ें। एक ऐसे सत्र में जहाँ किसी को इसकी आवश्यकता नहीं थी, rules file की लागत 2,500 tokens है। उसी सत्र में skill की लागत 40 tokens है, और दस में से एक सत्र में जहाँ यह सक्रिय होती है, वहां इसकी लागत 3,000 है। अंतिम दो पंक्तियाँ एक ही server को दो बार दर्शाती हैं, tool search के चालू और बंद होने के साथ: 500 tokens बनाम 4,500। यह अंतर ही वह कारण है कि MCP context bloat के बारे में पुरानी सलाह अभी भी प्रचलित है।

Tool search के लिए ऐसे मॉडल की आवश्यकता होती है जो tool_reference blocks का समर्थन करता हो, जिसका अर्थ अगस्त 2026 तक Claude Sonnet 4.5, Haiku 4.5, Opus 4.5 और बाद के संस्करण हैं। Claude Code इसे तब बंद कर देता है जब ANTHROPIC_BASE_URL किसी ऐसे host की ओर इशारा करता है जो first party नहीं है, क्योंकि अधिकांश proxies उन blocks को forward नहीं करते हैं। इसे नियंत्रित करने के लिए ENABLE_TOOL_SEARCH सेट करें: false हर schema को शुरुआत में लोड करता है, true उन सभी को टाल देता है, और auto उन्हें शुरुआत में केवल तभी लोड करता है जब वे context window के 10% के भीतर फिट हो जाएं।

# Load schemas up front only if they fit in 5% of the window
ENABLE_TOOL_SEARCH=auto:5 claude

निर्णायक प्रश्न: क्या invocations के बीच डेटा बदलता है?

सबसे पहले यह पूछें, क्योंकि यह एक विकल्प को पूरी तरह समाप्त कर देता है। यदि agent को कुछ ऐसा पढ़ना या लिखना है जो अगली बार देखने पर अलग हो सकता है, तो आपको एक server की आवश्यकता है। एक issue tracker, एक database, एक monitoring dashboard, या आपका अपना internal API (application programming interface)। इसे लिख देना मदद नहीं करता, क्योंकि जिस क्षण कोई और record को edit करता है, वह जानकारी पुरानी हो जाती है। आपका अपना codebase भी इसी सूची में आता है, क्योंकि इसकी संरचना हर commit के साथ बदलती है। यही कारण है कि repository का parsed map MCP के माध्यम से agent को देना बेहतर है, बजाय इसके कि layout को ऐसी file में वर्णित किया जाए जो पुरानी हो जाती है।

यदि उत्तर छह सप्ताह बाद भी सही रहेगा, बिना किसी के उसे maintain किए, तो आपको एक skill की आवश्यकता है। एक release checklist। एक migration procedure। आपके error responses का स्वरूप। इस repository में tests कैसे लिखे जाने चाहिए। एक skill, git में मौजूद एक file है। इसका कोई port नहीं होता, कोई process नहीं होती, और गलत होने के अलावा इसका कोई failure mode नहीं होता, जिसे code review के जरिए पकड़ा जा सकता है।

यदि यह एक ऐसा तथ्य है जो उन कार्यों पर लागू होना चाहिए जिनके बारे में आपने अभी तक सोचा भी नहीं है, तो इसे rules file में रखें। Run make lint before committing. Never push to main. Handlers live in src/api/handlers/. प्रत्येक के लिए एक पंक्ति। जिस क्षण कोई entry चरणों (steps) में बदल जाती है, वह तथ्य नहीं रहती बल्कि एक procedure बन जाती है, और उसे एक skill में स्थानांतरित हो जाना चाहिए।

जब एक rules file पर्याप्त हो

Rules files कई स्थानों से लोड होती हैं, सबसे व्यापक से लेकर सबसे विशिष्ट तक: एक managed policy file, आपकी व्यक्तिगत ~/.claude/CLAUDE.md, प्रोजेक्ट की ./CLAUDE.md या ./.claude/CLAUDE.md, और एक gitignored ./CLAUDE.local.md। सभी खोजी गई फाइलें एक-दूसरे को ओवरराइड करने के बजाय आपस में जुड़ (concatenate) जाती हैं, और आपकी working directory के करीब वाली फाइलें अंत में पढ़ी जाती हैं।

Claude Code CLAUDE.md को पढ़ता है, AGENTS.md को नहीं। यदि आपकी repository में अन्य टूल्स के लिए पहले से ही AGENTS.md मौजूद है, तो दो ऐसी प्रतियां न रखें जो समय के साथ अलग-अलग हो जाएं।

ln -s AGENTS.md CLAUDE.md

Symlink सफल होने पर कुछ भी प्रिंट नहीं करता है। एक session शुरू करें, /context चलाएं, और पुष्टि करें कि Memory files के अंतर्गत CLAUDE.md दिखाई देता है। यदि यह वहां सूचीबद्ध नहीं है, तो agent ने इसे कभी नहीं देखा है और कोई भी rewording मदद नहीं करेगी। जब आप Claude-विशिष्ट पंक्तियाँ भी चाहते हैं, तो import फॉर्म का उपयोग करें और उन्हें import के नीचे रखें।

@AGENTS.md

## Claude Code

Use plan mode for changes under `src/billing/`.

यहाँ एक समस्या हो सकती है। @path imports context को सेव नहीं करते हैं। आयातित फाइल को launch के समय उस फाइल के साथ expand और load किया जाता है जिसने इसे reference किया है, चार hops की गहराई तक। 600-line की rules file को छह imports में विभाजित करना इसे मनुष्यों के लिए व्यवस्थित करता है और token cost को बिल्कुल भी नहीं बदलता है। AGENTS.md और इसके human-facing twin के पीछे के conventions को पढ़ने लायक है, इससे पहले कि आप किसी layout को अंतिम रूप दें।

जो चीज cost को कम करती है, वह है paths field के साथ .claude/rules/। paths frontmatter वाली एक rule file केवल तभी लोड होती है जब agent किसी ऐसे file को touch करता है जो patterns में से किसी एक से मेल खाता हो।

---
paths:
  - "src/api/**/*.ts"
---

# API rules

- Every endpoint validates its input.
- Use the standard error response shape.

बिना paths field वाली rule, launch के समय .claude/CLAUDE.md के समान प्राथमिकता के साथ लोड होती है। इसलिए working pattern यह है कि छोटी unconditional rules रखें, और किसी भी ऐसी चीज़ पर paths सूची का उपयोग करें जो केवल एक directory के भीतर मायने रखती है।

जब आपको किसी skill की आवश्यकता हो

एक skill एक ऐसी directory है जिसके अंदर SKILL.md होता है। व्यक्तिगत skills ~/.claude/skills/<name>/SKILL.md पर रहती हैं और आपकी मशीन पर मौजूद हर project पर लागू होती हैं। Project skills .claude/skills/<name>/SKILL.md में रहती हैं, repository के साथ चलती हैं, और किसी भी अन्य file की तरह pull request में review की जा सकती हैं।

mkdir -p ~/.claude/skills/summarize-changes

---
name: summarize-changes
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff.
---

Run `git status` and `git diff` against the merge base.
Group the changes by intent, not by file.
Call out anything touching auth, migrations or deletions.

description उस file का एकमात्र हिस्सा है जो skill के चलने से पहले context में रहता है, इसलिए यह दो काम करता है। यह बताता है कि skill क्या करती है, और यह बताता है कि इसका उपयोग कब करना है। "Helps with deploys" जैसा विवरण model को मिलान करने के लिए कुछ नहीं देता है, इसलिए skill कभी सक्रिय नहीं होती और आप यह निष्कर्ष निकालते हैं कि skills काम नहीं करती हैं।

Directory का नाम ही command बन जाता है, इसलिए ऊपर दिया गया उदाहरण आपको /summarize-changes देता है। व्यक्तिगत या project skill में, frontmatter name केवल listings में display label को set करता है।

एक बार कोई skill invoke होने पर उसका rendered content conversation में एक single message के रूप में शामिल हो जाता है और session के बाकी हिस्से में बना रहता है। Claude Code बाद के turns में file को दोबारा read नहीं करता। One-time steps के बजाय standing instructions लिखें और body को संक्षिप्त रखें, क्योंकि इसके बाद हर line प्रत्येक request पर recurring cost बन जाती है। Auto-compaction के बाद Claude Code प्रत्येक skill का सबसे recent invocation फिर से attach करता है और combined budget 25,000 tokens के भीतर प्रत्येक का पहला 5,000 tokens रखता है। एक ही session में कई बड़ी skills invoke करने पर सबसे पुरानी skills पूरी तरह drop हो जाती हैं। इसी कारण लंबी conversation के बाद कोई skill महत्वहीन लग सकती है। उसे फिर से invoke करें और वह वापस आ जाएगी। Procedure-heavy skill इस trade-off को स्पष्ट करती है: unlazy skill और उसकी Depth Tree method gates और plan file के लिए वास्तविक context खर्च करती है, बदले में ऐसा agent मिलता है जो काम पूरा होने की घोषणा समय से पहले नहीं करता। जब यही procedure एक से अधिक codebase पर लागू हो, तो file को copy करने के बजाय कई repositories में एक skill share करें।

आपको MCP server की आवश्यकता कब होती है

इसे जोड़ना केवल एक command का काम है, और transport यह तय करता है कि इसका स्वरूप क्या होगा।

# Remote HTTP server
claude mcp add --transport http notion https://mcp.notion.com/mcp

# Remote HTTP server behind a bearer token
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

# Local stdio server: everything after -- is passed through untouched
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
  -- npx -y airtable-mcp-server

-- महत्वपूर्ण है। stdio server के लिए, यह Claude Code के अपने विकल्पों को उस command line से अलग करता है जो आपके server को start करती है। यदि आप इसे छोड़ देते हैं, तो server के लिए बना --port 8080, claude mcp add के एक विकल्प के रूप में parse हो जाता है, जिसे वह फिर अस्वीकार कर देता है।

claude mcp list
claude mcp get notion

claude mcp add एक Added ... line के साथ पुष्टि करता है, जो केवल यह बताता है कि configuration को disk पर लिख दिया गया है। claude mcp list वह command है जो आपको सही स्थिति बताती है, क्योंकि यह प्रत्येक server के बगल में health status print करती है: ✔ Connected, ! Needs authentication, या ✘ Failed to connect। failure status का अर्थ है कि Claude Code उस server तक नहीं पहुँच सका, न कि यह कि list command खराब हो गई है। एक session के भीतर, /mcp प्रत्येक server के लिए वही view और tool count प्रदान करता है।

MCP server को की गई प्रत्येक call स्वतंत्र होती है और अपनी आवश्यकता की हर चीज साथ रखती है, जो यही कारण है कि एक MCP server आपके पिछले अनुरोध को याद नहीं रखता है। यह एक design choice है जिसका परिणाम आपको भुगतना पड़ता है: किसी भी ऐसी स्थिति (state) को जिसे सुरक्षित रखना आवश्यक है, server के पीछे, database या file में होना चाहिए, और यह वह चीज है जिसे अब आप operate करते हैं।

MCP server एक ऐसी process है जिसे आपको run करना होता है

यहाँ वह लागत है जिसे vendor तुलनाओं में छोड़ देते हैं। एक skill एक file होती है। एक MCP server वह software है जो कहीं न कहीं run होता है, और जब वह 'कहीं' आपका VPS (virtual private server) होता है, तो उसके uptime की जिम्मेदारी आपकी होती है।

एक stdio server सबसे सस्ता विकल्प है। Claude Code session शुरू होने पर इसे child process के रूप में spawn करता है, और session समाप्त होने पर यह बंद हो जाता है। इसमें न तो कुछ monitor करना होता है और न ही किसी अलग schedule पर patch करना होता है। एक remote HTTP server एक long-lived service है, और इसे उन सभी चीजों की आवश्यकता होती है जो किसी भी long-lived service को चाहिए होती हैं।

[Unit]
Description=Notes MCP server
After=network-online.target
Wants=network-online.target

[Service]
User=mcp
WorkingDirectory=/srv/notes-mcp
ExecStart=/usr/bin/node /srv/notes-mcp/dist/server.js
Environment=PORT=8931
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now notes-mcp
systemctl is-active notes-mcp
journalctl -u notes-mcp -n 50 --no-pager

systemctl is-active को active print करना चाहिए। यदि यह failed print करता है, तो journal में इसका कारण मौजूद होता है, और पहली बार run करने पर यह लगभग हमेशा एक missing environment variable या किसी अन्य चीज़ द्वारा पहले से bound port के कारण होता है। Restart=on-failure यहाँ वैकल्पिक नहीं है, क्योंकि एक crashed MCP server खुद को सूचित नहीं करता है। आपको तब पता चलता है जब agent आपको बताता है कि वह आपके issue tracker को पढ़ नहीं पा रहा है।

Process को 127.0.0.1 पर bind करें और इसके सामने TLS (transport layer security) वाला एक reverse proxy लगाएँ। एक MCP server जो आपके database तक पहुँचता है और बिना authentication के public port पर जवाब देता है, वह एक ऐसा database है जिसे आपने सार्वजनिक कर दिया है। VPS पर MCP server चलाना proxy, certificate और firewall पक्ष को सही ढंग से कवर करता है।

फिर बार-बार होने वाले काम का ईमानदारी से आकलन करें। service को अपने स्वयं के schedule पर security updates की आवश्यकता होती है, जिसका उस agent से कोई लेना-देना नहीं है जो इससे बात करता है। इसका OAuth token expire हो जाता है, और claude mcp list किसी असुविधाजनक क्षण में ! Needs authentication print करना शुरू कर देता है। इसके credentials एक config file या Authorization header में होते हैं, इसलिए उन्हें किसी भी अन्य secret की तरह ही देखभाल की आवश्यकता होती है, जो अपने आप में एक पूरा विषय है: AI agent की पहुँच से secrets को दूर रखना। skill के लिए ऐसा कोई काम नहीं होता।

बनाने से पहले विकल्प के साथ इसकी तुलना करें। यदि प्रस्तावित server के पीछे का data लगभग हर तिमाही में बदलता है, तो एक ऐसी skill जो agent को बताती है कि कहाँ देखना है और fields का क्या मतलब है, उस service की तुलना में सस्ती है जिसे आपको जीवित रखना पड़ता है।

अपनी context cost को कैसे मापें

अनुमान लगाना बंद करें और एक session के भीतर /context चलाएं। यह startup का विवरण प्रिंट करता है: system prompt, memory files, tools, और MCP servers, साथ ही प्रत्येक का token weight।

दो चीजों की जाँच करें। Memory files के अंतर्गत, पुष्टि करें कि आपके द्वारा अपेक्षित प्रत्येक rules file सूचीबद्ध है। एक missing file एजेंट को दिखाई नहीं देती है, इसलिए जब निर्देशों की अनदेखी की जा रही हो, तो यह सबसे पहली चीज है जिसे बाहर करना चाहिए। यदि file सूचीबद्ध है और नियम अभी भी अनदेखा किया जा रहा है, तो कारण पूरी तरह से कहीं और है, और वे कारण जिनकी वजह से एजेंट उसे दिखाई देने वाले निर्देश को अनदेखा कर देता है को फिर से लिखने से पहले उन पर काम करना उचित है। फिर देखें कि आपके servers की लागत क्या है। यदि आप जिस server का उपयोग महीने में दो बार करते हैं, वह उस सूची की सबसे बड़ी पंक्तियों में से एक है, तो उसे /mcp में toggle off करें और जिन sessions में इसकी आवश्यकता हो, उनके लिए इसे वापस चालू करें। configuration दोनों ही स्थितियों में सुरक्षित रहती है।

एक remote server cached 2h ago · connects on first use · 5 tools जैसी स्थिति की रिपोर्ट भी दे सकता है। इसका मतलब है कि Claude Code ने startup पर connect करने के बजाय पिछले session से tool list को पढ़ा है, और यह पहली बार tool call होने पर connect होगा। tools आपके पहले message से ही उपलब्ध होते हैं, इसलिए ठीक करने के लिए कुछ भी नहीं है। यदि आप चाहते हैं कि हर server startup पर ही connect हो, तो MCP_DISCOVERY_CACHE=0 सेट करें। व्यापक दृष्टिकोण के लिए, Claude Code context window को प्रबंधित करना यह बताता है कि compaction के बाद क्या बचता है, और वे tokens वास्तव में आपको क्या लागत देते हैं उन संख्याओं को पैसे में बदल देता है।

मेरा skill कभी trigger क्यों नहीं होता है?

इसका सामान्य कारण description है। skill चलने से पहले संदर्भ में यही एकमात्र टेक्स्ट होता है, इसलिए यदि यह स्थिति का नाम नहीं बताता है, तो कुछ भी match नहीं होता है। trigger को वाक्य में लिखें: "Use when the user asks what changed, wants a commit message, or asks to review their diff." अस्पष्ट विवरण चुपचाप विफल हो जाते हैं, जिससे इसे नोटिस करना कठिन हो जाता है।

दूसरा कारण frontmatter में typo है, और यह स्पष्ट रूप से दिखाई देता है। एक अज्ञात key को पूरी तरह से अस्वीकार कर दिया जाता है:

Unexpected key(s) in SKILL.md frontmatter: argument-hint. Allowed properties are: allowed-tools, compatibility, description, license, metadata, name

तीसरा कारण स्थान है। Project skills आपके working directory में और repository root तक के प्रत्येक parent में .claude/skills/ से load होते हैं। जहाँ से आपने शुरू किया था, उसके नीचे nested directories में मौजूद skills launch के समय load नहीं होते हैं। वे पहली बार तब दिखाई देते हैं जब agent उस subdirectory के अंदर किसी file को read या edit करता है, इसलिए तब तक वे autocomplete नहीं होते और नाम से invoke नहीं किए जा सकते।

इस silent failure का MCP समकक्ष url के साथ एक .mcp.json entry है जिसमें कोई type नहीं है। Claude Code बिना type वाली किसी भी entry को stdio server के रूप में read करता है, इसलिए यह entry को छोड़ देता है और रिपोर्ट करता है:

MCP server "notes" has a "url" but no "type"; add "type": "http" (or "sse" / "ws") to this entry

तीनों का एक साथ उपयोग

ये तंत्र एक ही स्लॉट के लिए प्रतिस्पर्धा नहीं करते हैं। एक प्रभावी सेटअप वह है जहाँ प्रत्येक का उपयोग वहां किया जाता है जहाँ वह किफायती हो। rules फाइल में कुछ ऐसी पंक्तियाँ होती हैं जो हर जगह सत्य होती हैं। Skills में प्रक्रियाएं होती हैं और वे केवल तभी लोड होती हैं जब उनकी आवश्यकता होती है। एक MCP server, या कभी-कभी दो, उन सिस्टम को जोड़ते हैं जिनकी सामग्री का आप पहले से अनुमान नहीं लगा सकते। यदि आप अभी भी इनमें से पहले वाले के लिए अपना मानसिक मॉडल बना रहे हैं, तो agent skill वास्तव में क्या है इसके प्रारूप को विस्तार से कवर करता है।

एक परीक्षण इस बहस को सुलझा देता है कि कोई चीज़ कहाँ होनी चाहिए। इसे हटा दें, एक नया session शुरू करें, और agent को कार्य दें। यदि agent केवल धीमा है, तो वह एक skill में होना चाहिए था। यदि agent आत्मविश्वास के साथ गलत है, तो वह rules फाइल में होना चाहिए था। यदि agent जानकारी प्राप्त ही नहीं कर पा रहा है, तो आपको server की आवश्यकता थी, और अब आपको उस server को चालू रखने के लिए एक योजना की भी आवश्यकता है।

FAQ

क्या मुझे skill लिखनी चाहिए या MCP server खड़ा करना चाहिए?

यह इस बात पर निर्भर करता है कि जानकारी हर बार इस्तेमाल करने पर बदलती है या नहीं। यदि agent को live state पढ़ना है जिसे कोई और बदल सकता है, जैसे कि issue tracker, database या dashboard, तो आपको MCP server की आवश्यकता है। ऐसा इसलिए है क्योंकि आपके द्वारा लिखी गई कोई भी जानकारी रिकॉर्ड बदलते ही पुरानी (stale) हो जाती है। यदि आप उत्तर को एक बार लिख दें और वह छह सप्ताह बाद भी सही रहे, तो skill लिखें। Skill git में मौजूद एक file है जिसे चलाने के लिए किसी process, open port या patch schedule की आवश्यकता नहीं होती, इसलिए जब भी संभव हो, यह सस्ता विकल्प है।

क्या MCP servers अभी भी मेरी context window भर देते हैं?

पहले की तुलना में बहुत कम। वर्तमान Claude Code में tool search डिफ़ॉल्ट रूप से सक्षम है, इसलिए session शुरू होने पर केवल tool के नाम और server के instructions load होते हैं। जब Claude उन्हें खोजता है, तभी पूर्ण schemas fetch किए जाते हैं। यदि tool search बंद हो, तो upfront loading अभी भी होती है: ENABLE_TOOL_SEARCH=false के साथ, जब ANTHROPIC_BASE_URL किसी ऐसे proxy की ओर इशारा करता हो जो first party नहीं है, या Claude 4.5 generation से पुराने model पर। यह जानने के लिए कि आप किस स्थिति में हैं, /context चलाएं, क्योंकि पुराने तुलनात्मक लेखों में दिए गए आंकड़े upfront loading को आधार मानकर लिखे गए हैं।

क्या Claude Code AGENTS.md पढ़ता है?

नहीं। Claude Code CLAUDE.md पढ़ता है। यदि आपके repository में अन्य agents के लिए पहले से ही AGENTS.md मौजूद है, तो दो प्रतियां रखने के बजाय एक को दूसरे की ओर point करें। साधारण symlink के लिए ln -s AGENTS.md CLAUDE.md चलाएं, या CLAUDE.md की पहली पंक्ति में @AGENTS.md लिखें और उसके नीचे Claude-विशिष्ट निर्देश जोड़ें। फिर एक session शुरू करें और यह पुष्टि करने के लिए /context चलाएं कि Memory files के अंतर्गत CLAUDE.md दिखाई दे रहा है।

session के बीच में मेरी skill का असर क्यों बंद हो गया?

इसका सामान्य कारण auto-compaction है। जब बातचीत का सारांश (summarize) तैयार किया जाता है, तो Claude Code प्रत्येक skill के सबसे हालिया invocation को फिर से जोड़ता है। यह प्रत्येक के पहले 5,000 tokens को सुरक्षित रखता है, जो कुल मिलाकर 25,000 tokens की सीमा के भीतर होते हैं। यह बजट सबसे हाल ही में invoke की गई skill से भरना शुरू होता है, इसलिए यदि आपने कई बड़ी skills invoke की हैं, तो पुरानी skills पूरी तरह से हटा दी जाती हैं। अपनी पूर्ण सामग्री को पुनर्स्थापित करने के लिए skill को फिर से invoke करें।

मैं एक लंबी rules file को हर session में load होने से कैसे रोकूँ?

उन हिस्सों को .claude/rules/ files में ले जाएं जिनमें उनके frontmatter में paths field हो, ताकि प्रत्येक file केवल तब load हो जब agent किसी matching file को छुए। file को @path imports में विभाजित करने से कोई मदद नहीं मिलती, क्योंकि imported files को launch के समय ही उस file के साथ expand और load कर दिया जाता है जिसने उन्हें reference किया था। जो कुछ भी एक स्थायी तथ्य (standing fact) के बजाय बहु-चरणीय प्रक्रिया (multi-step procedure) है, उसे skill बन जाना चाहिए, क्योंकि skill body को invoke किए जाने तक उसकी कोई लागत नहीं होती।