Enrich social profiles from handle or URL -- Twitter/X, GitHub, LinkedIn, YouTube. Followers, bio, verification.
Single tool 'social_lookup_profile' has a well-structured schema with proper enum constraints (platform: github|twitter|linkedin|youtube) and clear parameter descriptions. The tool description is comprehensive (280+ chars) and includes explicit guidance on when NOT to use it (referencing alternative tools for email lookup, company data, person enrichment). Input schema is properly typed with object properties. However, the description embeds example output JSON rather than documenting the actual return schema structure in a machine-readable way. No output schema is formally declared. The tool follows verb_noun naming (social_lookup_profile) but could be more concise (e.g., lookup_social_profile). Parameter descriptions are adequate but lack format constraints (e.g., handle length, URL format validation rules). No error handling guidance is visible in the tool definition.
Use this when you need public profile data from a social media handle or URL. Returns structured profile data in JSON. Returns: 1. displayName and bio 2. avatarUrl 3. followerCount and followingCount 4. postCount 5. location and website 6. createdAt (account creation date) 7. isVerified (boolean) 8. platform. Example output: {"platform":"github","handle":"torvalds","displayName":"Linus Torvalds","bio":"Linux kernel developer","avatarUrl":"https://avatars.githubusercontent.com/u/1024025","followerCount":213000,"followingCount":0,"postCount":729,"location":"Portland, OR","isVerified":true} Use this FOR influencer research, lead enrichment, social listening, building contact profiles, and verifying social media presence. Do NOT use for email lookup -- use email_find_by_name instead. Do NOT use for company data -- use company_enrich_from_domain instead. Do NOT use for person enrichment by email -- use person_enrich_from_email instead.
Output schema not formally documented. Example JSON in description is helpful but does not replace a structured schema declaration. LLMs cannot reliably extract field types or plan downstream tool calls without explicit output schema.
No error handling guidance. Tool description does not explain what happens on invalid handle, unsupported platform, or network failure. LLMs cannot determine retry strategy or recovery path.
Parameter format constraints missing. 'handle' and 'url' parameters lack length limits, character restrictions, or validation rules. LLMs may pass invalid values without guidance on acceptable formats.
Mutually exclusive parameters (handle+platform vs url) not explicitly documented as such. LLMs may pass both or neither, causing ambiguous behavior.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2025-06-18+ | v2 |
Example output embedded in description rather than as formal schema. LLMs may treat example values (e.g., 'torvalds', 'Portland, OR') as the only valid options or reuse them literally in real calls.