Dweep Scouting MCP
Scouting partners has never been easier.
Connecting your organisation to the Dweep MCP
Three things have to be true before partner scouting works: the server knows your organisation, it knows which person is asking, and that person has a live LinkedIn session. This guide covers all three, what you supply for each, and what breaks when one is missing.
Dweep finds B2B partner companies and the people to contact at them. It searches through a real LinkedIn account that someone at your organisation signs into once. Everything below exists to establish and maintain that chain.
Budget about ten minutes. Only step 3 needs a browser, and only step 1 needs someone with access to your organisation's key.
The identity chain
Three tiers resolve in order on every call. Each one has a distinct failure message, so the error you see tells you exactly which tier is missing — worth learning, because it turns most support questions into a five-second diagnosis.
TIER 1 — WHO IS THE COMPANYOrganisation keyAuthorization: Bearerdwk_live_…
TIER 2 WHO IS THE PERSONUser handleidentify_user(user_id="ayush-b")
TIER 3, WHOSE LINKEDINLinkedIn bindingbrowser sign-in,once per person
IF MISSING, THE SERVER REPLIESidentity_requiredconnector has no keyuser_not_identifiedorg known, person notno_linkedin_bindingnobody signed in yetAll three present → ready: true → scouting worksCompany research (financials, ratings, unit economics) works from tier 1 alone.
What you actually supply
Almost everything is configured on our side already. There are exactly two values that come from you, and one of them is per-person rather than per-organisation.
Step by step
1. Put the organisation key on the connector
Add a custom header to the Dweep MCP connector. Use the key issued to your organisation at onboarding:
It must be the Authorization header specifically. The server also accepts x-dweep-service-key, but MCP clients restrict which header names they will send, and Authorization is the one every client permits. A key beginning dwk_live_ is recognised as an organisation key rather than a user token, so there is no ambiguity.
2. Claim a handle
The organisation key says which company is calling. It cannot say which of your colleagues is calling, and that matters: LinkedIn accounts are bound per person, not per company.
Pick something short and stable, your name with a dash works. It does not have to exist beforehand; the call creates it.
Not an email address, and not a handle you know belongs to someone else — you would be claiming their binding.
3. Connect a LinkedIn account
Ask for a link, open it, and complete the sign-in fully — including any verification step LinkedIn asks for.
One LinkedIn account binds to exactly one person. If a colleague has already connected that account, your attempt is refused use a different LinkedIn account, or have them release theirs first.
4. Verify before you rely on it
Anything other than ready: true names the tier that is missing and the next action. The page you land on after signing in is not the confirmation, check_setup is.
What happens when you connect
Worth understanding once, because two of the failure modes in the troubleshooting table only make sense against this sequence.
The single-use token is what ties your return to the request that started it. It is created at the beginning of the sequence, not when you click which is why a slow sign-in fails even though LinkedIn itself succeeded.
When something is wrong
Every refusal names its reason. Match it here.
Last updated