Skip to main content
Glama

LinkMCP: hosted LinkedIn MCP server

Find Mobile Number

find_mobile
Read-onlyIdempotent

Find the mobile phone number of one person. Identify the person with their LinkedIn profile URL or slug, or with their email address. One identifier is enough.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNoThe person's email address. Used only to identify the person, for example when you have no LinkedIn profile URL.
linkedin_profileNoThe person's LinkedIn profile URL (e.g. "https://linkedin.com/in/johndoe") or slug (e.g. "johndoe").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / email / description
      Previous value: -"Email address (alternative or additional identifier for the person)."New value: +"The person's email address. Used only to identify the person, for example when you have no LinkedIn profile URL."
    • changedInput schema / properties / linkedin_profile / description
      Previous value: -"LinkedIn profile URL (e.g. \"https://linkedin.com/in/johndoe\"), slug (e.g. \"johndoe\"), or URN."New value: +"The person's LinkedIn profile URL (e.g. \"https://linkedin.com/in/johndoe\") or slug (e.g. \"johndoe\")."
  2. First observed

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds the constraint that it resolves exactly one person and accepts a single identifier, but says nothing about what happens when no mobile number is found, hit rates, or any rate limits.

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 short sentences, front-loaded with the operation and its scope, then the identifier options. Every sentence carries information and there is no filler.

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

Completeness4/5

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

For a two-parameter lookup with full schema coverage and rich annotations, the description is nearly complete. The one gap is the absence of an output schema combined with no mention of return semantics, such as what the agent gets when the person is identified but no mobile number exists.

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% and both parameters carry examples, so the baseline is 3. The description adds meaning the schema does not: with 0 required parameters, it clarifies that exactly one identifier is needed and that either the LinkedIn profile or the email alone suffices.

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

Purpose4/5

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

States a specific verb and resource ('Find the mobile phone number') plus scope ('of one person'), which cleanly separates it from lookup siblings like find_email and validate_email. It never names an alternative tool explicitly, so the differentiation is implicit in the resource rather than spelled out.

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

Usage Guidelines3/5

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

The description tells the agent which identifiers are accepted and that 'one identifier is enough', which is real usage guidance, but it gives no when-to-use/when-not-to-use framing relative to find_email or the other person-lookup siblings. Usage is implied by the resource name rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.