Abstraxn

Social / person profile lookup (pay-per-call)

social.profile_lookup

Read-onlyIdempotent

Resolve person / social-profile identity for a batch of records, paid per call directly from the caller's own wallet via the x402 protocol — no Abstraxn account needed. Supports two modes per record:

Fuzzy match: supply first_name and/or last_name plus emails and/or phones.
Reverse lookup: supply only emails and/or phones, no name required.

Every record needs a caller-chosen record_id (any string) to correlate it with its match in the response, plus at least one non-empty first_name/last_name, or at least one non-empty entry in emails, or at least one non-empty entry in phones — an empty array counts as not provided. Optional top-level match_condition_fields (e.g. ["linkedin_url"]) restricts results to matches that include ALL of the named fields.

The exact response shape (field names/nesting per match) is passed through unchanged from the upstream provider — read whatever comes back rather than assuming a fixed shape.

Charges ~$0.02 per call — the exact charge for a given call is always whatever the live payment challenge specifies for that request. The first call (no paymentPayload) returns paymentRequired; retry with the same arguments plus paymentPayload to complete payment and get the real result.

Input Schema

TableJSON Schema

Name	Required	Description
`records`	Yes	Records to resolve. Each needs record_id plus at least one non-empty first_name/last_name, emails entry, or phones entry.
`paymentPayload`	No	x402 payment payload from a previous `paymentRequired` challenge. Omit on the first call.
`match_condition_fields`	No	Optional filter — only return matches whose result includes ALL of these fields, e.g. ["linkedin_url"].

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`paymentRequired`	No

TDQS

A4.5/5.0

Behavior4/5

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

The description thoroughly explains the payment flow (first call returns paymentRequired, retry with paymentPayload), the batch processing nature, and the fact that response shape is passed through from upstream provider unchanged. Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as true/false, and the description adds significant behavioral context beyond these (payment requirements, two modes, response shape variability).

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?

The description is well-structured, front-loading the core purpose and payment model, then breaking down modes and requirements. It is slightly verbose in the parameter details section (could be more terse), but every sentence serves a purpose and the structure aids readability.

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?

Given the complexity (3 parameters, nested objects, payment protocol, output schema exists), the description is largely complete. It covers input requirements, payment flow, mode selection, result shape variability, and optional filtering. It does not explicitly state what happens on error or how to interpret the response beyond 'pass through', which is a minor gap, but the output schema helps mitigate this.

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 description coverage is 100%, so the schema already documents all parameters. The description adds significant value by explaining the two modes of operation (fuzzy match vs reverse lookup), the requirement for at least one non-empty field per record (with specific clarification about empty arrays), and the purpose of match_condition_fields. It also clarifies that record_id is caller-chosen for correlation.

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 clearly states the tool resolves person/social-profile identity for a batch of records, explicitly distinguishing between fuzzy match and reverse lookup modes. It provides specific verb+resource (resolve person/social-profile identity) and explains the two operational modes, making it easy to understand what the tool does and how it differs from siblings.

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?

The description provides explicit guidance on when to use each mode (fuzzy match vs reverse lookup), details the required inputs per record, explains the payment protocol (x402, pay-per-call, first call returns paymentRequired), and describes the optional match_condition_fields filter. This is comprehensive and leaves no ambiguity about invocation.

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

All Abstraxn tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation4/5

Tools are grouped by domain (market, network, places, social, travel, web3) and each has a distinct purpose. However, within the 'network' group, tools like token_price, token_info, and market.crypto/price_feed could be confused for similar price lookups, but descriptions clarify their differences (free vs paid, DEX vs CoinGecko).

Naming Consistency3/5

The naming uses a dot-separated domain prefix (e.g., market.crypto, network.blocknumber, places.lookup) which is consistent in structure, but the action selection within each tool (e.g., search vs price_feed) is not reflected in the tool name itself. This hybrid approach is clear but not strictly uniform.

Tool Count4/5

With 11 tools covering a wide range of domains (crypto, network, places, social, travel, web3), the count is appropriate for a multi-purpose server. Each domain has a focused set of actions, so the tool count feels well-scoped without being excessive.

Completeness3/5

The server covers a broad but shallow surface across multiple domains. For example, crypto market data is well-covered, but places lacks a reverse geocode or photo tool. Travel has only flight and hotel search, missing car rentals or activities. The network domain is relatively complete for read operations, but lacks write support beyond prepare_transfer.

Resources

Need Help?