MCP Google Contacts Server

by 4tal

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is notable overlap between create_contact and create_contact_advanced, and between update_contact and update_contact_advanced, which could confuse agents about which to use. Additionally, search_contacts and search_contacts_by_group have overlapping search functionality, though their descriptions help differentiate them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as create_contact, delete_contact_group, and list_contacts. This predictability makes the tool set easy to navigate and understand at a glance.
Tool Count4/5
With 19 tools, the count is slightly high but reasonable for a Google Contacts server, covering contacts, groups, and directory operations. It includes essential CRUD and search functions, though some redundancy (like advanced vs. basic create/update) contributes to the higher number.
Completeness5/5
The tool set provides comprehensive coverage for managing Google Contacts, including full CRUD for contacts and groups, search across multiple dimensions, and integration with Google Workspace. There are no obvious gaps; agents can perform all typical contact management workflows without dead ends.
Average 3.3/5 across 19 of 19 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 the tool is 'more targeted' but doesn't explain what that means operationally—whether it searches specific fields, requires permissions, has rate limits, or what the output format looks like. The description lacks critical behavioral details for a search tool.
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 reasonably concise with three sentences, though the Args section formatting is slightly verbose. The core purpose is stated upfront, and each sentence adds value without redundancy. Minor room for improvement in structure.
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?
For a search tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what 'more targeted' means, how results are returned, error conditions, or differentiation from siblings. Critical context is missing for effective tool use.
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 documents both parameters with basic semantics ('Search term to find specific directory members' and 'Maximum number of results to return'), but doesn't explain query syntax, result ordering, or default behavior beyond the default value. This provides marginal value over the bare schema.
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 tool searches for people in the Google Workspace directory, providing a specific verb ('search') and resource ('people in the Google Workspace directory'). It distinguishes itself from generic search tools by specifying the directory scope, though it doesn't explicitly differentiate from sibling tools like 'search_contacts' or 'list_workspace_users'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance, stating it's a 'more targeted search' but without explaining when to use this versus alternatives like 'search_contacts', 'search_contacts_by_group', or 'list_workspace_users'. No explicit when/when-not criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's an update operation. It doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, error conditions, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is inadequate.
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 efficiently structured with a clear purpose statement followed by parameter documentation. However, the parameter section uses informal formatting ('Args:') and could be more integrated. Overall, it's appropriately sized with minimal waste.
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?
For a mutation tool with 2 parameters (including a complex nested object), 0% schema coverage, no annotations, and no output schema, the description is insufficient. It lacks critical information about behavior, parameter details, error handling, and comparison to siblings, leaving the agent poorly equipped to use 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?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds basic semantics for both parameters ('Contact resource name' and 'Dictionary containing updated contact information'), but doesn't explain format, constraints, or examples for 'contact_data' despite its complexity. It partially compensates but leaves significant gaps.
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 ('Update') and resource ('existing contact') with specific scope ('full field support including multiple emails, phones, addresses, etc.'). It distinguishes from the simpler 'update_contact' sibling by emphasizing advanced capabilities, though it doesn't explicitly name the sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the simpler 'update_contact' sibling or other contact-related tools. It mentions 'full field support' but doesn't clarify prerequisites, constraints, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool can 'search and list users' and describes the parameters, but doesn't address important behavioral aspects like authentication requirements, rate limits, pagination behavior, error conditions, or what specific user information is returned beyond 'email addresses and other information'. For a directory listing tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 sized and well-structured. It starts with a clear purpose statement, then provides parameter documentation in a formatted 'Args:' section. While slightly verbose with the introductory sentence repeating the purpose, each sentence adds value by clarifying scope and parameter usage. The formatting helps readability without excessive length.
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 the tool's complexity (directory listing with search capabilities), lack of annotations, and absence of an output schema, the description is incomplete. It doesn't explain what user information is returned beyond vague 'other information', doesn't address authentication or permission requirements, and provides no examples of query syntax or result formatting. For a tool that interacts with organizational directory data, this leaves too many practical questions unanswered.
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?
The description adds meaningful context for both parameters beyond what the schema provides. With 0% schema description coverage, the description compensates by explaining that 'query' is an 'optional search term to find specific users (name, email, etc.)' and 'max_results' is the 'maximum number of results to return (default: 50)'. This provides practical usage guidance that the bare schema titles ('Query', 'Max Results') lack.
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 tool's purpose as listing Google Workspace users in the organization's directory, including their email addresses and other information. It uses specific verbs ('list', 'search') and identifies the resource ('Google Workspace users'). However, it doesn't explicitly distinguish this tool from sibling tools like 'search_directory' or 'list_contacts', which appear to serve similar directory functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'search_directory', 'list_contacts', and 'search_contacts' available, there's no indication of how this tool differs in scope, functionality, or appropriate use cases. The description only states what the tool does, not when it should be selected over other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the update action but lacks critical behavioral details: permission requirements, whether changes are reversible, rate limits, error conditions, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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?
Front-loaded with the core purpose, followed by parameter details in a structured Args section. No wasted sentences, though the parameter explanations could be slightly more concise. Overall efficient and well-organized for its length.
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?
For a mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers parameters adequately but misses behavioral context (e.g., side effects, permissions, response format). Given the complexity and lack of structured data, it should provide more operational guidance.
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 0%, but the description compensates well by explaining all 3 parameters: 'resource_name' (with example), 'name' (new name), and 'client_data' (optional custom data as key-value pairs). It adds meaning beyond the bare schema, clarifying purpose and format, though it doesn't detail constraints like string length or key formats.
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 'update' and resource 'contact group' with specific fields 'name and custom data'. It distinguishes from siblings like 'create_contact_group' (creation) and 'delete_contact_group' (deletion), though not explicitly. However, it doesn't fully differentiate from 'update_contact' or 'update_contact_advanced' which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing contact group), exclusions, or comparisons to siblings like 'update_contact' (for individual contacts) or 'update_contact_advanced' (for more complex updates). The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states this is a creation operation but doesn't cover critical aspects like required permissions, whether it's idempotent, error conditions, or what happens on success/failure. The description adds minimal behavioral context beyond the basic action.
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 sized with two sentences and a structured Args section. The first sentence states the purpose clearly, and the Args section efficiently explains parameters with examples. No unnecessary information is included, though the formatting could be slightly cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is moderately complete. It covers the basic action and parameters well but lacks behavioral details like permissions, side effects, or return values. Given the complexity of a write operation, more context would be helpful for safe invocation.
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 0%, so the description must compensate. It provides clear semantics for both parameters: 'name' is explained with examples of group names, and 'client_data' is described as optional custom key-value pairs with an example. This adds meaningful context beyond the bare schema.
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 'Create' and resource 'new contact group (label)', specifying its purpose to organize contacts. It distinguishes from siblings like 'update_contact_group' or 'list_contact_groups' by focusing on creation, though it doesn't explicitly contrast with other creation tools like 'create_contact'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing appropriate permissions, or compare to other creation tools like 'create_contact' or 'create_contact_advanced', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It states the destructive action ('Delete') but doesn't cover critical aspects like whether deletion is permanent/reversible, required permissions, rate limits, error conditions, or what happens to associated data. The description is technically accurate but lacks essential context for safe use.
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 perfectly concise and well-structured. The first sentence clearly states the purpose, followed by a properly formatted Args section that adds parameter details without redundancy. Every element serves a clear purpose with zero wasted words.
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?
For a destructive operation with no annotations and no output schema, the description is insufficiently complete. It doesn't address critical contextual elements like confirmation requirements, success/error responses, side effects, or integration with sibling tools. The agent lacks enough information to use this tool safely and effectively in complex scenarios.
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?
The description adds meaningful context for the single parameter by specifying the expected format ('people/*') and clarifying it's a 'Contact resource name' rather than just a generic identifier. With 0% schema description coverage and only one parameter, this adequately compensates by providing the necessary semantic understanding beyond the bare schema.
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 action ('Delete') and resource ('contact by resource name'), making the purpose immediately understandable. It distinguishes from siblings like 'delete_contact_group' by specifying the contact resource type. However, it doesn't fully differentiate from other destructive operations like 'remove_contacts_from_group' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing the contact's resource name), when not to use it (e.g., for bulk deletions), or direct alternatives among the many sibling tools like 'remove_contacts_from_group' or 'update_contact' for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information' but doesn't specify what that includes (e.g., metadata, permissions), whether it's a read-only operation, error conditions, or rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 sized and front-loaded, starting with the core purpose followed by parameter explanations in a structured format. Every sentence adds value, with no redundant or vague language. However, the parameter section uses a code-like format that slightly disrupts flow, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and parameters but lacks behavioral details (e.g., what 'detailed information' includes, error handling) and usage guidelines. Without an output schema, it should ideally hint at return values, but the parameter explanations help offset this gap.
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?
The description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that resource_name is a 'Contact group resource name' with an example, clarifies include_members as 'Whether to include the list of member contact IDs', and notes max_members applies 'if include_members is True'. This compensates well for the schema's lack of descriptions, though it doesn't detail format constraints (e.g., resource_name pattern).
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 tool's purpose: 'Get detailed information about a specific contact group.' It specifies the verb ('Get') and resource ('contact group'), and distinguishes it from siblings like list_contact_groups (which lists multiple groups) and get_contact (which gets individual contacts). However, it doesn't explicitly differentiate from search_contacts_by_group, which might overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a resource_name), exclusions, or comparisons to siblings like list_contact_groups (for listing) or get_contact (for individual contacts). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose whether this is a read-only operation, if it requires specific permissions, what the return format looks like (e.g., list structure, pagination), or any rate limits. The explanation of contact groups is helpful context but insufficient for a mutation-free tool.
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?
Well-structured with a clear purpose statement, explanatory context about contact groups, and parameter documentation in a dedicated Args section. The sentences earn their place, though the contact group explanation could be slightly more concise for a purely functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description covers the basics but has gaps. It explains what contact groups are and documents the parameter, but lacks behavioral context (especially important with no annotations) and doesn't describe the return value format, which would be helpful since there's no output schema.
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?
The description explicitly documents the single parameter 'include_system_groups' with a clear explanation of what it does, compensating for the 0% schema description coverage. Since there's only one parameter and it's fully explained in the description, this meets the baseline expectation for minimal parameter documentation.
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 ('List') and resource ('all contact groups (labels) in your Google Contacts'), with a helpful explanation of what contact groups are. It distinguishes from siblings like 'get_contact_group' (singular) by emphasizing 'all', but doesn't explicitly differentiate from other list/search tools like 'list_contacts' or 'search_contacts_by_group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'list_contacts', 'search_contacts_by_group', or 'get_contact_group'. The description implies it's for retrieving groups rather than contacts, but doesn't specify use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'comprehensive field support' and parameters like max_results and include_all_fields, but doesn't cover critical aspects such as pagination behavior, rate limits, authentication requirements, or what happens when no contacts match. For a list operation with 3 parameters, this leaves significant 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 efficiently structured with a clear purpose statement followed by parameter explanations in a formatted Args section. Every sentence adds value, and there's no redundant information. It could be slightly more front-loaded by integrating parameter hints into the main description, but it's well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no annotations, and no output schema, the description provides adequate basics (purpose and param semantics) but lacks completeness. It doesn't explain return format, error conditions, or behavioral traits like pagination, which are important for a list tool. It's minimally viable but has clear gaps.
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?
The description adds meaningful context for all 3 parameters beyond the schema (which has 0% description coverage). It explains that 'name_filter' finds contacts by name, 'max_results' sets a limit with a default, and 'include_all_fields' controls inclusion of detailed data like addresses and birthdays. This compensates well for the lack of schema descriptions.
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 tool's purpose: 'List all contacts or filter by name with comprehensive field support.' It specifies the verb ('List') and resource ('contacts'), and mentions filtering capability. However, it doesn't explicitly differentiate from sibling tools like 'search_contacts' or 'get_contact', which is why it doesn't achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_contacts', 'get_contact', or 'list_workspace_users'. It mentions filtering by name and field inclusion, but doesn't specify scenarios, prerequisites, or exclusions for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While 'create' implies a write operation, it doesn't mention permission requirements, whether the operation is idempotent, what happens on duplicate contacts, or what the response format looks like. No rate limits, error conditions, or system constraints are described.
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 with a clear opening statement followed by detailed parameter documentation. While the parameter list is lengthy, each entry is concise and informative. The opening sentence could be more specific about what 'comprehensive field support' means.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 11 parameters and no annotations or output schema, the description does a good job with parameter documentation but lacks critical behavioral context. It doesn't explain what happens after creation, what the tool returns, or how to handle errors. The parameter coverage is excellent, but overall completeness is limited by missing operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics with clear explanations for all 11 parameters, including format specifications like 'YYYY-MM-DD' for birthday. With 0% schema description coverage, the description fully compensates by documenting each parameter's purpose and format beyond what the bare schema provides.
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 tool creates a new contact with comprehensive field support, which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'create_contact_advanced' or explain how it differs from 'update_contact' for new vs existing contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_contact_advanced' or 'update_contact'. It doesn't mention prerequisites, constraints, or typical use cases beyond the basic creation function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states this is a creation operation ('Create a new contact'), it doesn't mention whether this requires specific permissions, what happens on duplicate contacts, whether the operation is idempotent, or what the response looks like (e.g., returns a contact ID). For a mutation tool 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 sized and front-loaded with the core purpose in the first sentence. The parameter documentation is detailed but necessary given the complex nested structure. The formatting with bullet points improves readability, though the indentation in the provided text is slightly irregular.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation operation with nested objects, no annotations, no output schema), the description is partially complete. It excels at parameter semantics but lacks behavioral context (permissions, response format, error handling) and usage guidelines. For a creation tool with rich parameter requirements, more comprehensive coverage would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must fully compensate. It provides extensive semantic details about the 'contact_data' parameter, including specific examples of supported nested structures (emails, phones, addresses, relations, events, custom fields) with formatting examples. This adds substantial value beyond the minimal schema, making the parameter's expected structure and content clear.
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 tool's purpose: 'Create a new contact with full field support including multiple emails, phones, addresses, etc.' It specifies the verb ('create') and resource ('contact'), and distinguishes itself from the simpler 'create_contact' sibling by emphasizing 'full field support' and 'advanced' capabilities. However, it doesn't explicitly contrast with 'update_contact_advanced' for creation vs. update scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'create_contact_advanced' over the simpler 'create_contact', or when to use it versus 'update_contact_advanced' for modifying existing contacts. There's no context about prerequisites, permissions, or typical use cases beyond the basic functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a retrieval operation. It doesn't disclose behavioral traits like whether this requires authentication, rate limits, pagination behavior, error conditions, or what format the results return. The description is minimal beyond the basic purpose.
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 sized with three sentences plus a parameter section. The first sentence states the purpose, followed by explanatory context, and then parameter details. It's front-loaded and efficient, though the parameter section could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 low schema coverage, the description is incomplete. It covers the purpose and one parameter but lacks details on authentication, rate limits, result format, pagination, or error handling. For a retrieval tool with siblings, more context is needed to be fully helpful.
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?
The description adds the parameter 'max_results' with a default value and brief explanation, which is valuable since schema description coverage is 0% (the schema only provides title and type). However, it doesn't detail constraints like valid ranges or effects beyond 'maximum number of results to return'.
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 'Retrieve' and the resource 'contacts from the Other contacts section', with a helpful explanation of what 'Other contacts' means. It distinguishes this from main contacts but doesn't explicitly differentiate from sibling tools like 'list_contacts' or 'search_contacts'.
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 by explaining what 'Other contacts' are (people interacted with but not in contacts list), suggesting when this tool is appropriate. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'list_contacts' or 'search_contacts', nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behavioral traits: the server-side/client-side fallback mechanism and the default max_results value. However, it doesn't mention rate limits, authentication requirements, pagination behavior, or what happens when no results are found.
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 with a clear purpose statement followed by behavioral context and parameter explanations. It's appropriately sized at 4 sentences, though the Args section formatting could be cleaner. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description does reasonably well but has gaps. It covers parameters well and mentions search behavior, but doesn't describe the return format, error conditions, or how results are ordered/filtered.
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 0%, so the description must compensate. It provides meaningful context for all three parameters: explaining what 'query' searches for, clarifying 'max_results' default and purpose, and giving examples for 'search_fields'. This adds substantial value beyond the bare schema.
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 tool's purpose: 'Enhanced search contacts by name, email, phone, organization, or other fields.' It specifies the verb ('search') and resource ('contacts') with examples of searchable fields. However, it doesn't explicitly differentiate from siblings like 'search_contacts_by_group' or 'search_directory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_contacts_by_group', 'search_directory', or 'list_contacts'. It mentions server-side vs client-side search behavior but doesn't explain when one approach is preferred or what distinguishes this from other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states this is an update operation (implying mutation) but doesn't mention permission requirements, whether partial updates are allowed, what happens to unspecified fields, error conditions, or response format. For a mutation tool with 12 parameters and no annotations, this is insufficient behavioral context.
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 sized and well-structured with a clear opening statement followed by a comprehensive parameter list. Every sentence earns its place, though the formatting as a code block with Args: might not be optimal for readability. It's front-loaded with the core purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, mutation operation, no annotations, no output schema), the description is partially complete. It excels at parameter documentation but lacks crucial behavioral context for a mutation tool. The agent knows what parameters to provide but not how the tool behaves, what permissions are needed, or what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (titles only, no descriptions), so the description must compensate fully. The description provides detailed parameter documentation with clear explanations of each field's purpose (e.g., 'Updated first name', 'Updated birthday in YYYY-MM-DD format'), adding significant semantic value beyond the bare schema. This fully addresses the schema coverage gap.
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 'Update an existing contact with comprehensive field support' which specifies the verb (update) and resource (contact). It distinguishes from siblings like create_contact (create vs update) but doesn't explicitly differentiate from update_contact_advanced. The purpose is clear but sibling differentiation could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like update_contact_advanced or create_contact. There's no mention of prerequisites (e.g., needing an existing contact), constraints, or typical use cases. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the mutation action ('remove') but does not cover permissions required, whether the operation is reversible, error handling (e.g., if contacts aren't in the group), or response format. This leaves significant gaps for a mutation tool with zero annotation coverage.
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 front-loaded with the core purpose in the first sentence, followed by parameter details in a structured Args section. It avoids unnecessary words, though the parenthetical in the first sentence could be integrated more smoothly. Overall, it's efficient with minimal waste.
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?
For a mutation tool with no annotations, no output schema, and 2 parameters, the description is incomplete. It covers the basic operation and parameters but lacks behavioral details (e.g., side effects, error cases) and output information. Given the complexity and lack of structured data, it should provide more context to be fully helpful.
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 0%, so the description must compensate. It adds meaningful context by explaining both parameters: group_resource_name as 'Contact group resource name' with an example, and contact_resource_names as 'List of contact resource names to remove' with examples. This clarifies the purpose and format beyond the bare schema, though it doesn't detail constraints like list size limits.
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 specific action ('remove contacts from a contact group') and resource ('contact group'), with a parenthetical clarification ('remove a label from contacts') that distinguishes it from deletion tools like delete_contact or delete_contact_group. It precisely identifies the tool's function without redundancy.
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 by specifying the operation, but lacks explicit guidance on when to use this tool versus alternatives like delete_contact_group (for removing entire groups) or add_contacts_to_group (the inverse operation). No prerequisites or exclusions are mentioned, leaving usage context inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates this is a destructive operation ('Delete') and adds important context about the user-created vs system group limitation. However, it doesn't mention permissions needed, whether deletion is reversible, or what happens to contacts in the group, leaving gaps in behavioral understanding.
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 sized with two sentences that each earn their place - the first states the purpose, the second provides a critical constraint. The Args section is properly formatted but could be more integrated with the main description text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description provides the essential purpose and a key constraint. However, it lacks information about error conditions, confirmation requirements, or what happens to associated contacts, making it incomplete for safe operation despite the single parameter.
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 description provides the parameter name and an example value ('contactGroups/12345'), which adds meaning beyond the schema's 0% description coverage. However, it doesn't explain where to find resource names, format requirements beyond the example, or validation rules, so it only partially compensates for the schema's lack of documentation.
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 action ('Delete') and target ('a contact group'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'delete_contact' or 'remove_contacts_from_group', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when NOT to use this tool ('only works for user-created groups, not system groups'), which is valuable guidance. However, it doesn't mention alternatives for system groups or explicitly compare with other deletion-related siblings, keeping it from a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool adds contacts to a group (implying a mutation), but doesn't mention permissions required, whether the operation is idempotent, error handling for invalid resource names, or what happens if contacts are already in the group. This leaves significant gaps for a mutation tool.
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 front-loaded with the core purpose in the first sentence, followed by a concise parameter section with examples. Every sentence earns its place, with no redundant or verbose language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is moderately complete: it covers purpose and parameters well, but lacks behavioral details (e.g., side effects, error cases) and return values. Given the complexity, it should do more to compensate for missing structured data.
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 0%, so the description must compensate. It provides clear parameter names, types (string, array of strings), and example values (e.g., 'contactGroups/12345', ['people/12345']), adding essential meaning beyond the bare schema. However, it doesn't explain where to find these resource names or format constraints.
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 specific action ('add contacts to a contact group') and resource ('contact group'), distinguishing it from siblings like 'remove_contacts_from_group' (opposite action) and 'create_contact_group' (different resource). The parenthetical 'assign a label to contacts' further clarifies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to label contacts, but doesn't explicitly state when to use this tool versus alternatives like 'update_contact' (which might modify contact details) or 'search_contacts_by_group' (which retrieves contacts). It provides clear context but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the basic function but lacks critical details: it doesn't mention whether this is a read-only operation, what permissions are required, how results are returned (e.g., pagination), or potential rate limits. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded: the first sentence states the core purpose, the second adds useful context, and the Args section efficiently documents parameters. Every sentence earns its place without redundancy, and the structure (purpose, context, parameters) is logical and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and parameters well but lacks behavioral details (e.g., read/write nature, error handling) and output information. Without annotations or an output schema, the description should do more to explain what the tool returns and its operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains both parameters: 'group_resource_name' is clarified with an example ('e.g., "contactGroups/12345"'), and 'max_results' is described as limiting the return count. This fully compensates for the schema's lack of descriptions, making the parameters clear and actionable.
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 specific action ('Find all contacts') and resource ('that belong to a specific contact group'), distinguishing it from siblings like 'list_contacts' (general listing) and 'search_contacts' (general search). The second sentence reinforces this by explaining the purpose ('seeing which contacts have a particular label assigned'), making the tool's scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Find all contacts that belong to a specific contact group') and implies an alternative use case ('useful for seeing which contacts have a particular label assigned'). However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as 'list_contacts' for unfiltered listing or 'search_contacts' for broader searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-google-contacts MCP server](https://glama.ai/mcp/servers/4tal/mcp-google-contacts/badges/card.svg)](https://glama.ai/mcp/servers/4tal/mcp-google-contacts)

Score Badge

Copy to your README.md:

[![mcp-google-contacts MCP server](https://glama.ai/mcp/servers/4tal/mcp-google-contacts/badges/score.svg)](https://glama.ai/mcp/servers/4tal/mcp-google-contacts)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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