Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Social Media Scraper - Custom MCP Server Scrape this LinkedIn profile: https://linkedin.com/in/johndoe"
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.
Model Context Protocol (MCP) is an open standard that enables AI assistants to securely connect with external data sources and tools. MCP servers act as bridges between AI models and various services, allowing for enhanced capabilities like real-time data access, API integrations, and custom tool execution.
Related MCP server: LinkedIn MCP Server
This server exposes the following tools for an AI assistant to use:
LinkedIn Profile Scraping: Extract personal and company profile data
Facebook Profile Scraping: Fetch public profile information
Instagram Profile Scraping: Get profile data and basic information
Google Search: Perform web searches using Google Serper API
We recommend using uv to manage your Python projects.
If you haven't created a uv-managed project yet, create one:
uv init custom-mcp-server
cd custom-mcp-serverThen add MCP to your project dependencies:
uv add "mcp[cli]"This will auto-generate files and folders similar to the project structure mentioned below, also create a .env file to securely store the API keys.
In the files generated look for main.py and copy paste the code given in main.py (repo).
uv add httpx python-dotenv fastmcpRapidAPI Key:
Sign up at RapidAPI
Subscribe to the following APIs (Most Important):
Fresh LinkedIn Profile Data
Facebook Scraper3
Instagram Scraper Stable API
Google Serper API Key:
Sign up at Serper.dev
Get your API key from the dashboard
Create .env file in your project root with the following variables:
RAPIDAPI_KEY=your_rapidapi_key_here
SERPER_API_KEY=your_serper_api_key_hereYou can install this server in Claude Desktop and interact with it right away by running:
uv run mcp install main.pyLater, go to Claude AI (desktop version) and you will see changes in the platform similar to the screenshot shown.
Paste the URLs of required platform and ask the AI to provide information of the mentioned URLs.
Please scrape this LinkedIn profile: https://linkedin.com/in/example-profileGet company information for: https://linkedin.com/company/example-companyIf the MCP tools don't appear in Claude Desktop:
Windows: Open Task Manager (Ctrl+Shift+Esc)
Mac: Open Activity Monitor
End all Claude-related processes
uv run mcp install main.pyPaste the URLs of required platform and ask the AI to provide information of the mentioned URLs.
Alternatively, you can test it with the MCP Inspector:
uv run mcp dev main.pycustom-mcp-server/
├── __pycache__/ # Python bytecode cache (auto-generated)
├── .venv/ # Virtual environment directory
├── .env # Environment variables (API keys)
├── .python-version # Python version specification
├── main.py # Main MCP server implementation
├── pyproject.toml # Project configuration and dependencies
├── README.md # Project documentation
└── uv.lock # UV lock file for reproducible buildsAll tools return JSON-formatted strings containing the scraped data. Example response structure:
{
"success": true,
"data": {
"profile": {
"name": "John Doe",
"title": "Software Engineer",
"location": "San Francisco, CA",
"bio": "Passionate about technology..."
}
},
"timestamp": "2024-01-15T10:30:00Z"
}But using these tools via Claudes makes it readable.
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
In case of any queries, please leave a message or contact me via the email provided in my profile.
Fetch full LinkedIn company page data for a given URL.
| Name | Required | Description | Default |
|---|---|---|---|
| linkedin_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply says 'Fetch full LinkedIn company page data' but does not explain any behavioral traits such as authentication requirements, rate limits, error handling, or the structure of the returned data. The adjective 'full' hints at completeness but adds little actionable detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no extraneous words. It is front-loaded with the action and resource, making it easy to parse quickly. This is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description is insufficient for an agent to fully understand the tool's behavior. It does not mention what 'full company page data' includes, the format of the response, potential errors, or any preconditions (e.g., URL format validation). The tool is simple, but the lack of contextual detail reduces its completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It mentions 'for a given URL,' which clarifies that the linkedin_url parameter should be a LinkedIn company page URL. However, it does not provide format expectations or examples, and the parameter name itself already conveys most of the meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fetch full LinkedIn company page data for a given URL.' It uses a specific verb ('fetch') and resource ('LinkedIn company page data'), and it distinguishes itself from siblings like get_personal_profile and get_facebook_profile by focusing on company pages and LinkedIn specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for LinkedIn company URLs but does not explicitly state when to use it over alternatives like get_personal_profile or scrape_website. There is no mention of exclusions or alternative tools, leaving the agent to infer the appropriate context from the resource type mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch Facebook profile data for a given public URL.
| Name | Required | Description | Default |
|---|---|---|---|
| profile_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'public URL' hinting at accessibility, but does not disclose return format, authentication needs, error behavior, or rate limits. This is a significant gap for a fetch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the core purpose, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should explain what data is returned and any limitations. It doesn't. The sibling tools suggest different profile types, but this description doesn't clarify how this tool fits in, leaving the context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for 'profile_url', and the description only adds that it is a public URL. It does not clarify the expected format (e.g., full URL vs username) or any constraints, providing minimal compensation for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches Facebook profile data for a public URL, using a specific verb and resource. It distinguishes itself from siblings by platform (Facebook vs Instagram, personal, company), though it doesn't specify what 'profile data' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the sibling tools. The description only states what it does, not when to choose it over alternatives or any exclusions (e.g., not for private profiles).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch Instagram profile data for a given public username or URL.
| Name | Required | Description | Default |
|---|---|---|---|
| instagram_url_or_username | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only notes the profile must be 'public', which hints at a limitation, but does not mention return format, rate limits, error behavior, or what data is included. This is sparse for a tool with no structured behavioral annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It front-loads the verb and resource, then specifies the input format. It is concise without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what 'profile data' includes, but it remains vague. It also lacks details on limitations for private profiles, expected errors, or result structure. While the tool is simple, the description is under-specified for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, but the description compensates by adding meaning to 'instagram_url_or_username': it clarifies the string can be either a username or a URL, and must be public. This goes beyond the bare type string, giving the agent essential usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and clearly identifies the resource as 'Instagram profile data', with a parameter accepting a username or URL. This distinctly separates it from sibling tools like get_facebook_profile and scrape_website, making the tool's purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need Instagram profile data, but provides no explicit guidance on when to use it versus alternatives like get_personal_profile or scrape_website. There are no stated exclusions or comparison to sibling tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full LinkedIn personal profile data for a given URL.
| Name | Required | Description | Default |
|---|---|---|---|
| linkedin_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. 'Fetch' clearly implies a read-only operation with no side effects. However, it does not mention potential limitations (e.g., private profiles, authentication needs, or failure modes) or describe the output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and resource without unnecessary words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description defines the input and purpose, but it does not hint at the shape of the returned profile data or any error conditions. It is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage of 0% and only one parameter, the description adds meaning by stating 'for a given URL', indicating that the linkedin_url parameter expects a LinkedIn profile URL. This is helpful guidance for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and clearly identifies the resource ('full LinkedIn personal profile data'). It distinguishes from sibling tools by specifying 'LinkedIn personal' versus company, Facebook, or Instagram profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when a LinkedIn personal profile is needed, given the sibling tools cover other platforms. It does not explicitly name alternatives or exclusions, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch search results for a given query using Google Serper API.
| Name | Required | Description | Default |
|---|---|---|---|
| gl | No | in | |
| num | No | ||
| page | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only names the API. It does not disclose behavior like rate limits, authentication needs, whether results are scraped from a website, or output structure. Lacks essential transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it errs on the side of under-specification, but conciseness itself is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description is far too minimal. It does not cover parameter semantics, usage context, or return values, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only mentions 'query' generically and ignores 'gl', 'num', and 'page' entirely. Fails to add meaning beyond the schema's simple parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a verb ('Fetch'), resource ('search results'), and method ('using Google Serper API'). However, the tool name 'scrape_website' suggests scraping websites, which conflicts with the description's focus on search results, slightly undermining clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives (e.g., the sibling profile getters). The description implies use for fetching search results but gives no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_company_profileget_facebook_profileget_instagram_profileget_personal_profilescrape_websiteEach tool targets a distinct entity type or platform: LinkedIn personal, LinkedIn company, Facebook profile, Instagram profile, and general web search. There is no overlap in purpose, and the descriptions make the boundaries clear.
Most tools follow a get_[qualifier]_profile pattern, but scrape_website breaks the convention with a different verb and noun. Also, get_personal_profile and get_company_profile use entity type qualifiers rather than platform names, while the other two profile tools use platform names, creating minor inconsistency.
Five tools is well within the ideal range and each tool serves a distinct function. The scope is narrow but well-defined for a social media scraper focused on profile retrieval.
The tool surface is incomplete for a general social media scraper. It covers only LinkedIn, Facebook, and Instagram, missing major platforms like Twitter, YouTube, or TikTok. Additionally, it only supports profile fetching, not posts, comments, or other content, and the inclusion of scrape_website for Google search results is tangential to the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Scrape, crawl and search the web for AI agents via MCP.
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
Social media MCP server: your Instagram, TikTok, YouTube, LinkedIn and Threads history for your AI.
Live LinkedIn data for AI agents: profiles, companies, jobs, posts, email finding. No account risk.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sharan-Kumar-R/Custom-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
