Google Contacts, Gmail and Google Calendar are not currently available as standard Hands connectors. This article explains a possible workflow; it is not a guide to connecting those services in Hands today.
Why keep this reference at all?
The underlying workflow is useful beyond one provider: durable identity facts should live in an identity source, while a request should focus on the outcome. When a compatible data source is available, a Hand can use stable contact context instead of asking you to repeat an email address in every instruction.
Names need an identity source
“Email Sophie” is not precise if there are three Sophies in your working life. A useful identity source connects the human name to stable attributes such as the right email address, company and role. The action layer — mail, calendar, CRM or another tool — can then operate on the resolved person.
Resolve the person first. Act second. If more than one record is plausible, ask which person the user means rather than guess.
What good source data looks like
- Use recognizable names. Avoid records that only say “Accountant” or contain nothing but an email address.
- Keep the primary email current. A perfect name match is not useful if the underlying address is obsolete.
- Add company or role when it disambiguates. “Sophie Jansen · Northstar” is more useful than two records simply called “Sophie”.
- Clean duplicates in the source system. Identity cleanup belongs where the contact data is owned.
Good automation should expose ambiguity, not hide it
If a lookup returns one clearly relevant person, the identity source has done its job. If two records remain plausible, the safer behavior is to ask which one you mean. Better source data shortens prompts; it should not make uncertain guesses look confident.
How this pattern can become actionable again
Hands lets users add their own public HTTPS remote MCP server. If you independently operate or trust a compatible MCP server that exposes contact, mail or calendar tools, you can connect it yourself. Which tools are available and what they may do then depends on that MCP server and the provider credentials you supply.
Using your own MCP server is different from choosing a standard Hands connector. Check which contact tools that server offers and which accounts it can access before using it for this workflow.
Use the identity pattern now; only automate it through connections you actually have.
For currently available integrations, use the MCP catalog. If you bring a compatible public remote MCP server yourself, verify its tools and provider permissions before relying on it for contact or communication work.




