Skip to main content
Glama

Evaluate work overlap contacts

evaluate_work_overlap_contacts
Destructive

For a list of target accounts, find the current buying committee at each account that a super connector can warmly reach (they overlapped in tenure at that account), then create the contacts and WORK_OVERLAP relationship paths. Returns each contact with the connecting super connector, title, tenure overlap, and — when relevance ran — an assistant relevance verdict. This WRITES data: it creates contacts and relationship paths. Only accounts that carry a super-connector relationship and whose workspace has a buying_committee_regex produce results.

Use when: Use when a rep or admin wants to surface (and materialize) the warm buying committee for specific target accounts on demand, rather than waiting for the background automation. Pass the target account ids. Leave run_relevance false unless the caller explicitly wants the slower LLM relevance filter for very large companies.

Behavior: destructive

workspace_id / user_id are injected from request headers.

Returns contacts[] with fields: account_id account_linkedin_id account_name super_connector_keycloak_user_id super_connector_linkedin_id contact_id contact_linkedin_id contact_first_name contact_last_name contact_title connecting_company_size overlap_months relevance_evaluated relevance_decision_yes relevance_score path_created

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Input Schema

NameRequiredDescriptionDefault
account_idsNo
run_relevanceNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / _triggered_by
      Removed value: -{
      -  "default": "",
      -  "description": "REQUIRED. Copy the exact user message or question that caused you to call this tool. Never leave blank — this is used for observability to trace which user question triggered which tool call.",
      -  "type": "string"
      -}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and the description corroborates and enriches it: it states exactly what is written (contacts and relationship paths), the precondition for any result (account must carry a super-connector relationship and the workspace must have buying_committee_regex), how workspace_id/user_id are supplied, and the cost profile of the relevance LLM. It also discloses the multi-record handling expectation, well beyond what the annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and when-to-use are front-loaded, which is good, but the description then re-lists 15 return fields verbatim even though an output schema exists, and restates 'Behavior: destructive' that the annotations already declare. Roughly a third of the text is redundant with structured fields.

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

Completeness4/5

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

For a destructive, side-effecting tool with two loose parameters, the description covers preconditions, side effects, parameter intent, and result handling, and the output schema covers return shape. The only shortfall is that the duplicated return-field list is the kind of detail the schema should own, leaving less room for missing detail such as what happens on partial failure.

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 carry parameter meaning, and it does: 'Pass the target account ids' for account_ids and an explicit cost-based rule for run_relevance. It stops short of clarifying the expected id format (internal ids vs linkedin ids) or that account_ids may be null/empty.

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 names a concrete verb chain (find the buying committee a super connector can warm-reach, then create contacts and WORK_OVERLAP relationship paths) and a specific input set (target accounts). It is clearly distinguishable from read-only siblings like search_warm_intro_relationships because it states it materializes data.

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 'Use when' block explicitly covers the on-demand-vs-background-automation tradeoff and gives a clear default for run_relevance ('leave false unless the caller explicitly wants the slower LLM filter'). It does not name the read-only alternative (search_warm_intro_relationships) for agents who only want to inspect without writing, which is the one missing routing cue.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources