Skip to main content
Glama
Sign In

Revternal

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Revternal Enrich Person

revternal_enrich_person
Read-onlyIdempotent

Enrich one person from their LinkedIn profile URL via Revternal — full normalized profile: name, headline, current company and title, past work experience, education, skills, certifications, and profile picture. Default (fetch_live: false) reads Revternal's existing record for that URL and returns found:false if there is none; set fetch_live: true to have Revternal fetch a fresh profile (slower, higher vendor cost). Use to enrich a lead, candidate, or contact you already have a LinkedIn URL for. Requires your own Revternal API key (BYOK) — pass it as _apiKey. Example: revternal_enrich_person({ linkedin_url: "https://www.linkedin.com/in/vishalv06" }).

Input Schema

NameRequiredDescriptionDefault
_apiKeyYesYour Revternal API key (sent as x-api-key), from https://revternal.com/signup. Required — Pipeworx has no platform key for this pack.
fetch_liveNofalse (default): return Revternal's existing profile record, found:false if none (1 credit if found). true: Revternal fetches fresh profile data (5 credits, slower, higher vendor cost).
linkedin_urlYesPersonal LinkedIn profile URL containing /in/, e.g. "https://www.linkedin.com/in/vishalv06". A bare username is also accepted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / _apiKey / description
      Previous value: -"Revternal API key (x-api-key). Injected from the platform key when omitted."New value: +"Your Revternal API key (sent as x-api-key), from https://revternal.com/signup. Required — Pipeworx has no platform key for this pack."
    • changedInput schema / properties / fetch_live / description
      Previous value: -"false (default): return Revternal's existing profile record, found:false if none. true: Revternal fetches fresh profile data (slower, higher vendor cost)."New value: +"false (default): return Revternal's existing profile record, found:false if none (1 credit if found). true: Revternal fetches fresh profile data (5 credits, slower, higher vendor cost)."
    • changedInput schema / required
      Previous value: -[
-  "linkedin_url"
-]New value: +[
+  "linkedin_url",
+  "_apiKey"
+]
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations cover read-only/idempotent/no-destructive behavior. The description adds meaningful extra context: default reads the existing record and returns found:false if absent, fetch_live triggers a fresh fetch that is slower and higher vendor cost, and BYOK auth is required. It does not cover rate limits or return format, but this goes well beyond annotations.

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 the core action and return shape, then branches into fetch_live behavior and usage context. Slightly dense but each sentence carries information; the trailing example is mildly redundant given the schema example.

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 3-param read tool with no output schema, the description is complete enough: it explains the return fields, the fetch_live branch, the auth requirement, and the usage context. Only the response envelope (found, credits) could be richer.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are already documented in the schema. The description restates linkedin_url and fetch_live behavior but adds little beyond the schema's own descriptions; the example is redundant with the schema example. Baseline 3 applies.

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 (enrich) and resource (one person) from a LinkedIn URL via Revternal, and enumerates the returned fields. It is clearly distinguishable from siblings like revternal_enrich_developer or revternal_people_search.

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?

Explicitly gives when-to-use ('enrich a lead, candidate, or contact you already have a LinkedIn URL for') and explains the fetch_live true/false choice with its cost/perf tradeoff. It doesn't explicitly name the sibling alternatives, but the use context is unambiguous.

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

All Revternal toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources