Gravatar MCP Server

Official

by Automattic

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Get Gravatar Profile by Email

get_profile_by_email

Read-onlyIdempotent

Retrieve a Gravatar profile by email address to get personal details, social accounts, and avatar information.

Instructions

Retrieve comprehensive Gravatar profile information using an email address. Returns detailed profile data including personal information, social accounts, and avatar details. 'Show me the Gravatar profile for john.doe@example.com' or 'Get profile info for user@company.com.'

Input Schema

TableJSON Schema

Name	Required	Description	Default
`email`	Yes	The email address associated with the Gravatar profile. Can be any valid email format - the system will automatically normalize and hash the email for lookup. The email is processed securely and not stored.

Output Schema

TableJSON Schema

Name	Required	Description
`hash`	Yes	The SHA256 hash of the user's primary email address.
`links`	No	A list of links the user has added to their profile. This is only provided in authenticated API requests.
`company`	Yes	The user's current company's name.
`gallery`	No	Additional images a user has uploaded. This is only provided in authenticated API requests.
`location`	Yes	The user's location.
`payments`	No	The user's public payment information. This is only provided in authenticated API requests.
`pronouns`	Yes	The pronouns the user uses.
`timezone`	No	The timezone the user has. This is only provided in authenticated API requests.
`interests`	No	A list of interests the user has added to their profile. This is only provided in authenticated API requests.
`job_title`	Yes	The user's job title.
`languages`	No	The languages the user knows. This is only provided in authenticated API requests.
`last_name`	No	User's last name. This is only provided in authenticated API requests.
`avatar_url`	Yes	The URL for the user's avatar image if it has been set.
`first_name`	No	User's first name. This is only provided in authenticated API requests.
`description`	Yes	The about section on a user's profile.
`profile_url`	Yes	The full URL for the user's profile.
`contact_info`	No	The user's contact information. This is only available if the user has chosen to make it public. This is only provided in authenticated API requests.
`display_name`	Yes	The user's display name. This is the name that is displayed on their profile.
`header_image`	No	The header image used in the main profile card.
`pronunciation`	Yes	The phonetic pronunciation of the user's name.
`avatar_alt_text`	Yes	The alt text for the user's avatar image if it has been set.
`is_organization`	No	Whether user is an organization. This is only provided in authenticated API requests.
`background_color`	No	The profile background color.
`last_profile_edit`	No	The date and time (UTC) the user last edited their profile. This is only provided in authenticated API requests.
`registration_date`	No	The date the user registered their account. This is only provided in authenticated API requests.
`verified_accounts`	Yes	A list of verified accounts the user has added to their profile. This is limited to a max of 4 in unauthenticated requests.
`number_verified_accounts`	No	The number of verified accounts the user has added to their profile. This count includes verified accounts the user is hiding from their profile. This is only provided in authenticated API requests.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0-beta.4Sep 25, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the read-only, idempotent, and open-world aspects. The description adds value by specifying the response contents: personal information, social accounts, and avatar details. This gives the agent a clearer picture of what to expect beyond the schema. It does not mention any additional constraints, but given the annotations, this is sufficient.

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 two sentences with a clear, front-loaded action statement and an illustrative example block. Every sentence earns its place; the examples are concrete and helpful without being verbose. There is no fluff or repetition.

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?

Given the simplicity of the tool (one parameter, no nested objects) and the presence of an output schema, the description covers the essential context: what the tool does, what it returns, and typical usage examples. Nothing critical is missing for an agent to invoke it correctly.

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?

The schema already provides a detailed description of the 'email' parameter, including normalization, hashing, and security processing. The description does not add new information about parameters beyond what the schema states. With 100% schema coverage, the baseline score of 3 is appropriate.

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 a specific action ('Retrieve comprehensive Gravatar profile information') and the resource ('using an email address'). It distinguishes from sibling tools by emphasizing email-based lookup, and the examples reinforce the intended use. This is as clear as it gets for a lookup tool.

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

Usage Guidelines3/5

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

The description implies this tool is for email-based profile retrieval, but it does not explicitly state when to use it over alternatives like get_profile_by_id or get_avatar_by_email. The examples show usage but no exclusions or conditions. A short mention of 'use this when you have an email, otherwise use the ID-based variant' would have strengthened it.

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

Deploy Server