Extract LinkedIn Profile Data with MCP for Contact Research

You are preparing for meetings with people whose LinkedIn profile URLs are already in your notes. Your AI agent needs their visible professional details to organize the research, connect each person to a source and identify questions that still need an answer.

You can extract LinkedIn profile data through an MCP-connected AI agent using a published BrowserAct Bot. Prepare a personal LinkedIn Profile Scraper Bot with your own login, give the agent your URLs, and have it retrieve the actual results before building the research table. MCP (Model Context Protocol) lets the agent use BrowserAct's tools in the conversation.

The useful result includes the table, a coverage summary and a follow-up list. Collected facts stay separate from the agent's notes, so you can check a role change or missing detail before using it in a meeting.

Key Takeaways

• Use URL-based extraction when you already know whose profiles you need to research.
• Your LinkedIn access determines which profile details can be collected; configure your own login before running.
• Count successful records and distinct profiles separately, especially when your input contains duplicates.
• Review empty optional fields separately from profiles that could not be read.
• Preserve the original export and keep your research notes separate from collected facts.

Define the Research Table You Need

Choose the information needed for your next decision before collecting the list. Start with name, current role, company and profile URL. Include an email column when contact research needs it, filling it only from an address actually returned. Visible About text and career history can add context.

The template returns these groups of fields:

Information	Returned fields	What it helps you check
Identity and source	full_name, profile_url	Whether the record belongs to the intended person
Professional context	headline, location, current_position, current_company	How the person describes their work and which current role is explicitly shown
Background	about, experience, education	Relevant professional background available on the profile
Additional details	contact_info	Visible Contact info; extract an email only if one is actually returned
Collection outcome	status, status_detail	Whether the profile was read or needs further attention

Keep the headline and current position separate. A headline can mention several interests or services; it is not necessarily a job title. Similarly, an empty education field can simply mean no education was visible.

This Bot starts with personal-profile URLs you provide. Finding new people, collecting company pages and converting Sales Navigator links require different workflows. It also does not infer hidden contact details from a person's name or employer.

Prepare Your LinkedIn Profile List

Put the source URLs in one column and keep that list unchanged. If you already have notes about each person, retain them in separate columns so you can compare those notes with the collected information later.

Use standard personal-profile links containing /in/. Check that a copied link belongs to the intended person rather than a company or search-results page. For a list of distinct people, remove duplicate profiles in a working copy before collection. If repeated inputs matter to your project, retain them and account for them explicitly.

The template's result format preserves input order and repeated URLs, with one record per nonempty input, including error-status records. Check a completed batch against that expectation. Missing records are a coverage problem to investigate, not profiles to count as successfully collected.

Start with a few profiles from your actual list. Choose people whose identity you can check, then decide which fields you need for the research. The first batch should help you establish whether the output meets those needs before you process the rest.

Prepare a Bot to Extract LinkedIn Profile Data

The LinkedIn Profile Scraper explains both how to run the ready-made template and how to build a personal scraper. Use the template to check a small batch first. A personal Bot for the MCP route is a separate preparation step.

Run the Template with Your Own LinkedIn Account

1. Open Run. Open the template Run page and click Run.
2. Enter Profile URLs. Paste your personal-profile URLs into profile_urls, using commas or semicolons between multiple URLs. Click Continue.
3. Choose a Proxy. Under Account login, select a Proxy. The template recommends a Static Proxy to keep a consistent IP address across runs.
4. Set Up LinkedIn Login and Run. Choose Account credentials through Settings, or Import cookies through Import. Complete setup with your own LinkedIn account, then click Save & Run.

When the task finishes, review each row's status and download the CSV or JSON. The LinkedIn URL-to-CSV guide covers result handling in more detail.

Prepare a Personal Bot for the MCP Route

If you need a personal Bot, follow the template's How to Build a New Scraper Bot section:

1. Describe the Data You Need. Open BrowserAct and describe the website, records and fields you need. Select This website needs login for LinkedIn.
2. Let BrowserAct Build and Test. Start the build. BrowserAct explores the site and tests extraction. Complete your own login when requested.
3. Run the Bot and Review the Results. Enter a few profile URLs, run the completed Bot and check the structured output.

For the MCP route below, publish that personal Bot and keep its name or ID ready. The agent must read its current required inputs before submitting your list. Configure the Bot's own LinkedIn access; a session in another browser does not provide it.

Keep account credentials out of profile_urls. If LinkedIn requests verification, complete the required account step before expecting usable profile data. For a task that ends in failure, resolve the reported problem before choosing to run again. A timeout alone does not prove execution stopped; check the existing task before starting another.

When the agent retrieves the Bot's result, preserve the returned records or result file with their status fields. Keep that original output unchanged and put research notes in a working table.

Read a Real Batch Before Processing the Rest

A BrowserAct run recorded on October 21, 2026 illustrates what to look for. It used an already authenticated Bot and six nonempty inputs. The examples below are historical snapshots, not current claims about the people or a forecast of what another account will see.

What a Successful Record Contains

One successful record included the following values, selected from the full output:

Field	Recorded value
profile_url	https://www.linkedin.com/in/williamhgates
full_name	Bill Gates
current_position	Co-chair
current_company	Gates Foundation
contact_info	Website: gatesnot.es (Blog)
status	ok

The website stayed within that person's Contact info field. Work and education histories likewise remain within the person's own record, rather than becoming extra people in the CSV. This sample contained listed websites; it does not establish email or phone availability.

Why Six Rows Did Not Mean Six People

The complete batch contained both valid and invalid inputs:

Input order	Input or returned identity	Returned status
1	Bill Gates	ok
2	Satya Nadella	ok
3	LinkedIn company-page URL	invalid_url
4	Malformed URL	invalid_url
5	Nonexistent profile in that run	not_found
6	Bill Gates, repeated input	ok

The result was six returned rows, three successful rows and two distinct successful profiles. Counting every row as a researched contact would overstate the usable list. Removing the error rows before reconciliation would hide what still needed attention.

For your batch, first check that each nonempty input has a corresponding record. Then review successful records against the intended identities and the fields your research needs. Check important details on the source pages using the account that collected them. The sample above demonstrates output handling; it does not establish a general success rate or large-batch capacity.

Handle Missing Details and Access Problems Differently

For invalid_url, correct the input. For not_found, check the intended profile link. A missing optional field in an ok record should remain empty unless you obtain information from a source you can verify.

A partial record needs review before use. For login_required, repair login and start a new run; for access_restricted, resolve access before continuing. Investigate failed using its explanation. These statuses describe different follow-up tasks, so keep the status and reason beside the record.

An empty Contact info field does not mean the person has no website, email or phone. It means the result contains no such detail. Avoid filling that gap with a guessed address.

Use BrowserAct MCP in Your AI Agent

Connect your AI agent to BrowserAct through MCP and give it a small list for your prepared Bot. The agent can submit the URLs, retrieve the completed results and organize the records into a research table in the same conversation. Check that first result before processing the rest.

Connect Your Agent

In an MCP-compatible client's settings, add the official BrowserAct server at https://mcp.browseract.com/mcp/ and configure your general BrowserAct API Key in the client's local configuration or supported secure credential field. Follow the BrowserAct MCP setup guide and confirm that BrowserAct's search and run tools are available in your agent before continuing. Keep the key outside the conversation.

Use the personal Bot you built, checked and published above. The official MCP connection lets your agent find published Bots accessible to your API Key; connecting MCP does not sign a Bot into LinkedIn. Check that the Bot's required inputs and returned fields match the research task before using it.

Read actual output before preparing the research table.

Give the Agent a Research Task

Provide the personal-profile URLs you want to research and identify your published Bot. You can use the following request once the connection and Bot are ready:

Use BrowserAct MCP and my published LinkedIn Profile Scraper Bot to research
the personal-profile URLs I provide. Identify the Bot by the name or ID
I specify; ask me to choose if several match. Read its current required
inputs and ask me for missing values. If it is unavailable, explain and stop.

Run it once for the supplied URLs. Keep the task reference and retrieve
the final task details and actual output before analyzing it. If submission
times out or creation is uncertain, check for the original task before
submitting again. Never create a duplicate while its state is unknown.
Report failures and missing output. If login or access is missing, ask me
to resolve it in BrowserAct. Do not treat a task reference as collected data.

Using only the returned records or result files you can read, prepare a
table of name, source URL, headline, current position, company and relevant
background. Preserve collected values, contact_info, status and status_detail.
Extract only email addresses explicitly present in contact_info into working
columns email, email_source_url and email_status. Preserve their spelling
and source profile URL; leave email empty when absent. Do not guess addresses
or label them deliverable. Use observed, not_observed or review_required;
flag unreadable records for review. Keep notes and follow-up questions separate.

Report returned rows, successful rows and distinct successful profiles
separately. Flag duplicates, missing required details and collection
problems. Also count distinct profiles with observed emails separately.
Do not infer hidden contact details. Keep unanswered questions
visible, and do not send messages or modify LinkedIn profiles.

Review the Research Table

The agent's output should include the research table, a short coverage summary and a follow-up list. Names, roles and profile links come from the Bot's actual results; research notes and questions are added by the agent. Preserve that distinction so you can trace a note back to the collected source. If only a result file is available, the agent needs to read it before summarizing its contents.

For meeting preparation, suppose an employer in your earlier notes differs from current_company. Ask the agent to flag the difference and retain both values with the source URL. Check the profile's current roles and dates before updating your notes. Once confirmed, the change can inform a question about the person's new responsibilities. The same conversation can carry the collection result and this follow-up research.

Extract Email Addresses from Returned Contact Info

If contact_info contains an explicit email address, ask the agent to copy it into the working table. Keep the original field and spelling. These are agent-created working columns, rather than extra fields promised by the Bot:

Working column	What to record
email	The returned address; empty when absent
email_source_url	The corresponding LinkedIn profile URL
email_status	observed, not_observed, or review_required for ambiguous text or an uncertain record

An ok profile record does not prove an email was found. Check the record before assigning email_status; collection errors stay visible. Report profiles with observed emails separately from successful profiles, and keep duplicates out of that count. Observation does not establish ownership or deliverability. Website-only Contact info, as in the historical example above, leaves email empty; the Bot does not visit that website to find an address.

Reuse the Process for Your Next List

Expand to the remaining profiles after the sample meets your requirements. Keep a record of each submitted batch and compare it with the corresponding export. Process unresolved rows separately so a second attempt does not silently create duplicate contacts in your working table.

Treat every export as a snapshot. Saving a CSV does not make it update when someone changes roles. Record the collection date in your research workspace and collect again when fresh information is needed.

For later research, give your connected agent the next profile list and use the same confirmed Bot. Recheck login when access changes, and keep the new results associated with their source batch and collection date.

Start with the Contacts You Already Have

To extract LinkedIn profile data for contact research in your AI agent, prepare your personal Bot and connect BrowserAct MCP. Begin with a small list, retrieve the actual output and check every input. Use the research table and follow-up questions for your meeting preparation, then reuse the same Bot for the next list.

Frequently Asked Questions

Do I need code to extract LinkedIn profile data?

No. You can use the template's Run form, or have an MCP-connected agent call your published Bot. Configure your own LinkedIn login in BrowserAct. The agent can then retrieve and organize the actual collection results.

Do I need to log in to LinkedIn?

Yes, this template requires your own LinkedIn login. For a template run, configure it in the Run flow; for the MCP route described here, configure your personal Bot's Website login settings. The information visible to that account determines what can be collected, and LinkedIn may require additional verification.

Can the Bot find new people for my list?

This Bot reads the personal-profile URLs you submit. It does not discover new profiles from a company, search query or job title. Prepare the source list before using this collection workflow.

How do I extract an email address into the research table?

Have the agent copy an email only when it appears explicitly in returned contact_info, preserving the source profile URL. Email is not guaranteed: leave the working column empty when absent and flag uncertain records for review. The Bot does not infer hidden addresses, and an observed address has not been tested for deliverability.

Does connecting MCP also log the Bot into LinkedIn?

No. Your BrowserAct API Key gives the agent access to BrowserAct tools and resources allowed for that key. The Bot needs its own LinkedIn login configured in BrowserAct. Resolve missing login or access there before asking the agent to run again.