Skip to main content
Glama

Find Phone Number

find_phone_number
Read-only

Pass a list of LinkedIn profile URLs — one entry for a single person, all of them at once for a batch (they are looked up in parallel, costing one tool call against the loop guard, not N). Returns one result per URL in the same order. Airscale brokers providers like RocketReach. Persists nothing — use the returned numbers however the agent needs them (e.g. tell the user, or stash them on prospects via update_prospect).

A LinkedIn profile URL is the only accepted input — this tool cannot look a person up by email or name. When a record (a HubSpot/CRM contact, a prospect row, a spreadsheet line) has no LinkedIn URL but does have the person's email, first call find_linkedin_url(email=...) to resolve one, then pass that URL here. Apply this resolve-then-lookup step to every record, not just the first; skip the phone lookup for any person you cannot get a URL for.

Costs 8 Sliq credits per number found, when run on Sliq's shared Airscale account. Misses (no number on file) and upstream failures are free. A worst-case check runs up front on the Sliq path: the whole batch is refused unless the balance covers 8 credits per URL (any URL could be a hit). So no API call is ever spent on a lookup that can't be billed, and a user low on credits is told to top up or connect their own key. If the user has connected their own Airscale key (BYO, via the integrations page), lookups run against that account instead — no Sliq credit gate and no Sliq credit charge. A list of result dicts in input order. Per hit: {status: 'success', found: True, phone_number, phone_numbers, provider, linkedin_url, credits_charged: 8} (0 on the BYO path) — phone_number is the first number, phone_numbers the full list. Per miss: {..., found: False, phone_number: None, phone_numbers: [], credits_charged: 0}. A malformed (non-LinkedIn) URL or an upstream failure on one URL becomes a per-item {found: False, error, credits_charged: 0} in that slot — it never aborts the rest of the batch. If the up-front worst-case credit check fails, it raises InsufficientCreditsError (no lookups are attempted).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
linkedin_urlsYesLinkedIn profile URLs, e.g. ["https://www.linkedin.com/in/janedoe"].

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses parallel batch behavior, one-tool-call loop-guard behavior, order preservation, persistence behavior ('persists nothing'), credit costs, the up-front worst-case balance check, InsufficientCreditsError, and per-item error isolation. This far exceeds what annotations alone provide.

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?

The description is long but densely informative; the core summary is front-loaded and the cost/credit details are structured into clear sections. Every sentence carries operational meaning an agent would need before calling or deciding not to call.

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?

With only one parameter and no formal output schema, the description fully compensates by specifying return shape per hit/miss/error, failure handling, cost implications, BYO-key behavior, and the prerequisite LinkedIn-URL constraint. Nothing an agent needs for correct invocation is 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?

The schema already documents linkedin_urls with an example (100% coverage), and the description adds important semantics: one URL per person, single or batch, parallel execution, one tool call vs N, and same-order results. It doesn't go much beyond that, but the added batch and ordering semantics are valuable.

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?

The description opens with a specific action (find phone numbers) and the exact input (LinkedIn URLs), and explicitly contrasts with what it cannot do (look up by email or name). This clearly distinguishes it from siblings like find_linkedin_url and find_email.

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

Usage Guidelines5/5

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

It gives explicit when-to-use context (when you have LinkedIn URLs), explicit exclusions (no email/name lookup), and an explicit alternative workflow: call find_linkedin_url(email=...) first when only an email is available. It also instructs to repeat resolve-then-lookup per record and skip if no URL can be obtained.

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.

Resources