Skip to main content
Glama
4tal

MCP Google Contacts Server

by 4tal

get_contact

Retrieve Google Contacts information by resource name or email address, including comprehensive contact details and fields.

Instructions

Get a contact by resource name or email with comprehensive information.

    Args:
        identifier: Resource name (people/*) or email address of the contact
        include_all_fields: Whether to include all contact fields (default: True)
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
identifierYes
include_all_fieldsNo

Implementation Reference

  • MCP tool handler implementation for 'get_contact'. Uses @mcp.tool() decorator for automatic registration. Fetches contact details via GoogleContactsService and formats the output.
    @mcp.tool()
    async def get_contact(identifier: str, include_all_fields: bool = True) -> str:
        """Get a contact by resource name or email with comprehensive information.
    
        Args:
            identifier: Resource name (people/*) or email address of the contact
            include_all_fields: Whether to include all contact fields (default: True)
        """
        service = init_service()
        if not service:
            return "Error: Google Contacts service is not available. Please check your credentials."
    
        try:
            contact = service.get_contact(identifier, include_all_fields)
            return format_contact(contact)
        except Exception as e:
            return f"Error: Failed to get contact - {str(e)}"
  • Core helper method in GoogleContactsService that implements the Google People API call to retrieve a contact by resource name or email address, with support for full or limited fields, and enhanced formatting.
    def get_contact(self, identifier: str, include_all_fields: bool = True) -> Dict[str, Any]:
        """Get a contact by resource name or email with comprehensive field support.
    
        Args:
            identifier: Resource name (people/*) or email address
            include_all_fields: Whether to include all available fields
    
        Returns:
            Contact dictionary with comprehensive information
        """
        try:
            person_fields = (
                ",".join(self.PERSON_FIELDS)
                if include_all_fields
                else "names,emailAddresses,phoneNumbers,addresses,organizations"
            )
    
            if identifier.startswith("people/"):
                # Get by resource name
                person = (
                    self.service.people()
                    .get(resourceName=identifier, personFields=person_fields)
                    .execute()
                )
    
                return self._format_contact_enhanced(person)
            else:
                # Search by email
                contacts = self.search_contacts(identifier, max_results=1)
                if contacts:
                    return contacts[0]
    
                raise GoogleContactsError(f"Contact with identifier {identifier} not found")
    
        except HttpError as error:
            raise GoogleContactsError(f"Error getting contact: {error}")
  • src/tools.py:64-73 (registration)
    Top-level registration function that calls register_contact_tools(mcp), where the get_contact handler is defined and registered via @mcp.tool() decorator.
    def register_tools(mcp: FastMCP) -> None:
        """Register all Google Contacts tools with the MCP server.
    
        Args:
            mcp: FastMCP server instance
        """
        register_contact_tools(mcp)
        register_directory_tools(mcp)
        register_contact_group_tools(mcp)
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions retrieving 'comprehensive information' but doesn't specify what that includes, whether there are rate limits, authentication requirements, error conditions, or response format. For a read operation with zero annotation coverage, this leaves significant behavioral gaps.

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 appropriately concise with two sentences: one stating the purpose and one detailing parameters. The parameter documentation is structured but could be more front-loaded; the purpose statement earns its place by specifying scope and alternatives.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and 2 parameters with 0% schema coverage, the description is incomplete. It doesn't explain what 'comprehensive information' returns, error handling, or behavioral constraints. For a tool that likely interacts with contact data, more context about response structure and limitations is needed.

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 0%, so the description must compensate. It explains both parameters: identifier accepts resource name or email, and include_all_fields controls field inclusion with a default. This adds meaningful semantics beyond the bare schema, but doesn't detail format requirements (e.g., email validation) or what 'all fields' entails.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'contact', specifying it retrieves comprehensive information by resource name or email. It distinguishes from siblings like list_contacts (which lists multiple) or search_contacts (which searches broadly), but doesn't explicitly name these alternatives.

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 usage for retrieving a single contact by specific identifier, suggesting it's for targeted lookups rather than browsing or searching. However, it doesn't provide explicit guidance on when to use this versus alternatives like get_other_contacts or search_contacts, nor does it mention prerequisites or exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/4tal/mcp-google-contacts'

If you have feedback or need assistance with the MCP directory API, please join our Discord server