Generect

Resolve an anonymous LinkedIn link

resolve_profile

Reveal who is behind an anonymous LinkedIn profile link. Billable: about $0.0005 per resolved profile (an unresolvable reference is free; duplicates in one batch are billed per row) at the Tier 0 list price. Accounts can pay a different rate: get_balance returns this account's prices, and every response reports what was actually spent in cost.amount_charged_usd. Takes the obfuscated links that Sales Navigator leaves in exports, CRMs and ad platforms (linkedin.com/in/ACwAA…), plus Sales Navigator lead URLs, bare profile ids and urns, and returns the real profile URL and identity. profiles (up to 50) resolves a batch in one call. The id it returns is the identifier enrich_lead, generate_email and find_phone accept, so this is the cheap first step before a full record. Returns identity only (no location, company or work history; enrich_lead has those). The numeric member id is not accepted as input (LinkedIn answers 403 to it); it comes back as linkedin_id.

Input Schema

Name	Required	Description
`id`	No	Alias for `url` — same accepted values. Use whichever reads better.
`url`	No	A single LinkedIn person reference: profile URL of any flavour (including /in/ACwAA… and /sales/lead/…), a public identifier, an obfuscated id (ACwAA… or ACoAA…) or an urn. Matched case-insensitively.
`compact`	No	Default true: return a small per-profile summary (including the Generect `id`, which every later step accepts). Set false for the full raw record (~80 fields) — only worth it when you specifically need skills, education or other deep fields.
`profiles`	No	Batch mode: 1–50 references, mixed freely. One row per input, in input order, each either a resolved profile or {input, error}. Duplicates are billed per row — deduplicate first.
`timeout_ms`	No	Request timeout in milliseconds.

Output Schema

Name	Required	Description	Default
`cost`	No
`found`	No
`profile`	No
`profiles`	No
`resolved`	No
`test_mode`	No
`test_mode_notice`	No
`vocabulary_warnings`	No
`deprecated_params_ignored`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 19, 2026
- addedOutput schema / properties / found
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / profile
```
Added value: +{}
```

Changed6 schema fields changedOct 7, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / properties / deprecated_params_ignored / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / profiles / items
```
Added value: +{}
```
addedOutput schema / properties / vocabulary_warnings / items
```
Added value: +{}
```

AddedSep 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only give the generic readOnly/openWorld/destructive triad, while the description discloses the traits that actually matter here: billability at ~$0.0005/resolved profile, free unresolvable references, per-row billing for duplicates, per-account pricing via get_balance, and where the actual charge appears (cost.amount_charged_usd). That is exactly the context annotations cannot carry.

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

Conciseness4/5

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

Front-loaded with purpose, then cost, then inputs, then downstream use — a sensible order with no filler. It is dense and slightly long, with parenthetical billing caveats that take a second read, but every sentence carries information an agent needs.

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?

For a billable resolution tool with an output schema and full param documentation, the description covers inputs, cost model, batch semantics, output identity scope, and the handoff to sibling tools. An agent can decide whether to call it and how to chain it without further discovery.

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 baseline is 3, but the description adds real meaning beyond the schema: it enumerates the accepted input flavours (obfuscated ACwAA links, Sales Nav lead URLs, bare ids, urns), notes the 50-item batch cap, and — crucially — states that the numeric member id is rejected with a 403, a constraint absent from the schema.

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 first sentence names a specific verb and resource ('reveal who is behind an anonymous LinkedIn profile link') and the rest scopes it precisely: identity only, no location/company/history. It is clearly distinguishable from enrich_lead, which the description explicitly names as the tool for the deeper fields.

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 states when to use it ('the cheap first step before a full record'), names the alternatives and their differing scope (enrich_lead has location/company/work history), and describes the downstream chain (the returned `id` is accepted by enrich_lead, generate_email, find_phone). It also states a when-not: the numeric member id is not accepted as input.

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

All Generect 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.