PeopleSearch.im

Find a LinkedIn profile

find_linkedin_profile

Find a named person's LinkedIn profile: its URL with their current title, company and location. Give their first and last name, plus their company (name or website) and/or job title when you know them. A name only one person has is found from the name alone; when several people share it, the answer says how many and nothing is charged, so call again with their company or job title. Spends 2 credits, refunded if no confident match is found.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "first_name": "<first_name>",
      "last_name": "<last_name>"
    },
    "name": "find_linkedin_profile"
  }
}

Input Schema

Name	Required	Description
`job_title`	No	Their job title ("Head of Sales"). Tells apart people who share a name, together with or instead of company_or_domain.
`last_name`	Yes	The person's last name.
`first_name`	Yes	The person's first name.
`company_or_domain`	No	The company they work at, as its name or website (acme.com). Needed for a name several people share, together with or instead of job_title.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 28, 2026

changedInput schema / properties / company_or_domain / description

Previous value: -"Optional but recommended: the company name or domain they work at, to disambiguate common names."New value: +"The company they work at, as its name or website (acme.com). Needed for a name several people share, together with or instead of job_title."

addedInput schema / properties / job_title

Added value: +{
+  "description": "Their job title (\"Head of Sales\"). Tells apart people who share a name, together with or instead of company_or_domain.",
+  "type": "string"
+}

First observedSep 6, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false and openWorldHint=true, but the description goes substantially further: it discloses the 2-credit cost, the refund policy when no confident match is found, and that ambiguous-name lookups charge nothing and return only a count. These are exactly the behavioral traits an agent needs before deciding to spend credits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose then input guidance then cost/fallback behavior — the order matches the agent's decision sequence. No sentence is redundant with the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must convey return shape, which it does (URL with title, company, location; a count-only response for ambiguous names). Cost, refund conditions, and the retry path are all covered, leaving nothing material an agent needs missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description nonetheless adds decision semantics — company_or_domain and job_title are framed as disambiguators 'together with or instead of' each other, which clarifies they are alternatives rather than both-required. The one gap is that it does not clarify expected formats (full company name vs. bare domain) beyond the schema's own example.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Find a named person's LinkedIn profile') and specifies the returned payload (URL, current title, company, location). This cleanly distinguishes it from lookup_linkedin_profile (URL-keyed) and people_search, which an agent can infer from the name-plus-attributes input contract.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational context: supply name plus company and/or job title when known, and retry with those attributes when the ambiguous-name response returns a count. It does not explicitly name sibling alternatives such as lookup_linkedin_profile, so routing to the right tool still requires inference from the tool names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All PeopleSearch.im tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?