बोला गया सारांश — साथ पढ़ने के लिए प्ले दबाएँ: बोली जा रही पंक्ति ऊपर रहती है।
हमारे पास tools, skills, और connectors हैं। तो फिर MCP क्यों मौजूद है? पहली नज़र में यह API के ऊपर एक दूसरा API स्टैक किया हुआ लगता है। यह एक उचित सवाल है — और जवाब इस बात पर निर्भर करता है कि integration code को कौन maintain करता है।
रखरखाव की समस्या
मान लीजिए आपके agent को Asana से tasks pull करने हैं, Google Calendar check करना है, और Slack search करना है — सब एक साथ। custom tools के साथ, आपको तीन integrations लिखने होंगे। यह हिस्सा करने योग्य है। दर्दनाक हिस्सा इसके बाद आता है: आपको उन integrations को maintain भी करना होगा हर बार जब उन सेवाओं का API बदले, जो अक्सर होता है। बधाई हो, अब आप third-party API wrappers का एक ढेर maintain कर रहे हैं।
MCP उस रखरखाव को service provider को स्थानांतरित करता है। Asana एक MCP server publish करता है। Slack एक publish करता है। Google एक publish करता है। प्रत्येक server अपने tools को expose करता है — descriptions, schemas, और authentication के साथ — एक standard protocol के माध्यम से। जब उनका API बदलता है, वे अपने server को update करते हैं। आप कुछ नहीं बदलते।
Tools vs. skills vs. MCP
ये तीन features अलग-अलग काम करते हैं:
- Tools Claude को आपकी internal systems से जोड़ते हैं — आपका database, आपका project tracker, आपके proprietary APIs। आप code के मालिक हैं, इसलिए आप रखरखाव के भी मालिक हैं।
- Skills Claude को एक procedure सिखाते हैं — आपका report template, आपकी review checklist। Skills निर्देश हैं, जरूरी नहीं कि integrations हों।
- MCP Claude को third-party services से जोड़ता है, जहां service provider integration को maintain करता है। आप Asana wrapper नहीं लिखते — Asana ने लिखा।
संक्षिप्त संस्करण: tools आपके सामान के लिए हैं, skills आपकी प्रक्रियाओं के लिए हैं, और MCP सभी के सामान के लिए है।
Tools, Skills, और MCP के लिए तुलना कार्ड, MCP कार्ड हाइलाइट किया गया: Claude को third-party services से जोड़ता है, service provider द्वारा maintain किया जाता है
एक MCP server से जुड़ना
MCP का अनुभव प्राप्त करने का सबसे स्वच्छ तरीका Claude को किसी भी MCP server की ओर इशारा करना और यह देखना है कि वहां क्या है। इस उदाहरण के लिए, हम Linear MCP server का उपयोग करेंगे, connection details और auth token के साथ एक . env file में stored।
Request में दो pieces एक साथ काम करते हैं। mcp_servers key connection को declare करता है — एक type, एक URL, इसे refer करने के लिए एक नाम, और optionally एक auth token। फिर mcp_toolset type वाला एक tool configure करता है कि Claude उस server से कौन से tools use कर सकता है। default सभी हैं, लेकिन अगर आप इसे scope down करना चाहते हैं, तो यह वह जगह है जहां आप ऐसा करते हैं।
import os import anthropic
client = anthropic. Anthropic()
response = client. beta. messages. create( model="claude-opus-4-8", max_tokens=1000, messages=[ {"role": "user", "content": "What tools do you have available? "} ], mcp_servers=[ { "type": "url", "url": "https://mcp. linear. app/mcp", "name": "linear", "authorization_token": os. environ["LINEAR_MCP_TOKEN"], } ], tools=[ { "type": "mcp_toolset", "mcp_server_name": "linear", } ], betas=["mcp-client-2025-11-20"], )
print(response)
ध्यान दें कि हमने एक भी tool schema नहीं लिखा। Claude introspects server को, tools और उनके schemas की list वापस पाता है, और prompt के लिए सही चुनता है। इस पाठ के अनुसार, MCP connector beta में है — request में beta header पर ध्यान दें।
इसे चलाएं, और अगर आपका MCP URL Linear के MCP endpoint की ओर इशारा करता है, तो Claude Linear के tools को list करता है और फिर एक को call करता है। यही basically किसी भी compliant server के लिए काम करता है। हमने एक भी tool define नहीं किया। हमने एक Linear client नहीं लिखा। Linear इसे maintain कर रहा है।
Terminal output जो Linear MCP server के discovered tools को list करता है, इसके बाद Claude यह नोट करता है कि वे Linear project management tools हैं और कौन से को call करना है
कौन से tools Claude use कर सकता है इसे filter करना
MCP servers अक्सर बहुत सारे tools expose करते हैं — और आप हमेशा Claude को सभी का उपयोग करना नहीं चाहते। शायद आप इसे write permissions नहीं देना चाहते, या आप बस नहीं चाहते कि सभी tool definitions context ले लें।
समाधान: सब कुछ default से disable करें, फिर केवल specific tools को enable करें जो आप चाहते हैं। यहां एक Slack MCP server के साथ वह pattern है:
tools=[ { "type": "mcp_toolset", "mcp_server_name": "slack", "default_config": { "enabled": False, }, "configs": { "search_messages": {"enabled": True}, "list_channels": {"enabled": True}, }, } ]
अब Claude Slack को search कर सकता है और channels list कर सकता है, लेकिन यह post या delete नहीं कर सकता। यह तब उपयोगी है जब आप एक service पर reads के लिए विश्वास करते हैं लेकिन Claude को accidentally आपकी ओर से लिखने नहीं देना चाहते।
सारांश
- MCP इसलिए मौजूद है ताकि आपको integrations maintain न करने पड़ें जो किसी और ने पहले ही बना दिए हैं। service provider एक MCP server publish करता है और इसे up to date रखता है — जब उनका API बदलता है तो आप कुछ नहीं बदलते।
- काम के लिए सही feature चुनें: tools आपके data के लिए, skills आपकी process के लिए, MCP third-party services के लिए।
- mcp_servers में connection declare करें (type, URL, name, optional auth token) और tools में एक mcp_toolset entry के साथ access grant करें। Claude server को introspect करता है और tools को अपने आप discover करता है — कोई schemas लिखने के लिए नहीं।
- default_config: {"enabled": False} set करके और configs में specific tools को enable करके access को scope down करें — एक server को read-only रखने के लिए काम आता है।
- MCP connector वर्तमान में beta में है, इसलिए अपने requests पर beta header include करें।
- उपलब्ध servers की list के लिए और protocol के बारे में अधिक जानने के लिए **modelcontextprotocol. io** पर जाएं।