Extract LinkedIn Profile Data with MCP for Contact Research

BrowserAct published a LinkedIn Profile Scraper Bot that lets an MCP-connected AI agent pull visible profile fields — name, headline, current position, company, about, experience, education and contact info — from a user-supplied list of personal profile URLs. The template preserves input order and repeated URLs, returns one record per nonempty input including error-status records, and keeps collected facts separate from the agent's own notes so users can verify role changes before meetings. The company recommends running a small batch of verifiable profiles first to confirm coverage before processing a full list.

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. 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. 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. The LinkedIn Profile Scraper https://www.browseract.com/template/linkedin-profile-scraper-bot?co-from=blog-LinkedIn-Profile-Data-Research-DEV 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. profile urls , using commas or semicolons between multiple URLs. Click When the task finishes, review each row's status and download the CSV or JSON. The LinkedIn URL-to-CSV guide https://www.browseract.com/blog/linkedin-profile-scraper?co-from=blog-LinkedIn-Profile-Data-Research-DEV covers result handling in more detail. If you need a personal Bot, follow the template's How to Build a New Scraper Bot section: 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. 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. 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. 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. 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. 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. 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 https://docs.browseract.com/integrations/mcp?co-from=blog-LinkedIn-Profile-Data-Research-DEV 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.