Overlap

Answer a match

respond_to_match

Destructive

Record the one answer the user gave about a match: accept, decline or block. Call it only after the user has said which of the three they want. When both people accept, overlap opens a private conversation in the app. It also sends each person a link by email. Never promise an address. A decline covers this one request, and a later request from that person can still match. A block is permanent and covers the person, so send block only when the user asks for exactly that.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`match_id`	Yes	The match_id from check_matches.
`response`	Yes	The one answer the user gave. Use accept when the user wants this match. Use decline to pass on it: that covers this request only, and the next request from the same person can still match. Use block to never match the user with this person again — it is permanent, so use it only when the user asks for exactly that. A plain 'no thanks' is a decline, not a block.

Output Schema

TableJSON Schema

Name	Required	Description
`state`	Yes
`match_id`	Yes
`icebreaker`	Yes	Something to open with.
`their_name`	No
`you_accepted`	Yes
`introduced_at`	No
`they_accepted`	Yes
`why_you_matched`	Yes
`their_request_text`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "icebreaker": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Something to open with."
+    },
+    "introduced_at": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "match_id": {
+      "type": "string"
+    },
+    "state": {
+      "type": "string"
+    },
+    "their_name": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "their_request_text": {
+      "type": "string"
+    },
+    "they_accepted": {
+      "type": "boolean"
+    },
+    "why_you_matched": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "you_accepted": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "match_id",
+    "state",
+    "their_request_text",
+    "why_you_matched",
+    "icebreaker",
+    "you_accepted",
+    "they_accepted"
+  ],
+  "type": "object"
+}

Changed1 schema field changedSep 28, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
AddedSep 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, so the bar is lower, yet the description still adds substantial context: the mutual-accept conversation opening, the outbound email links, the caution never to promise an address, and the permanence of block versus the reversibility of decline. No behavior contradicts the annotations.

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 action and its precondition, and each subsequent sentence carries a distinct rule (email behavior, decline scope, block scope). Slightly long, but nothing is filler and the ordering matches how an agent would need the information.

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?

With an output schema present, return values need not be explained, and the description instead covers exactly what is missing from structured fields: prerequisites, side effects, and the semantic distinction between the destructive and non-destructive responses. Nothing material is absent for a two-parameter tool.

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 100% and both parameters are fully documented there, including the enum meanings and the match_id provenance. The description's remarks on accept/decline/block largely restate what the schema's enum description already says, so it adds little beyond the structured baseline.

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?

States a specific verb+resource ('record the one answer the user gave about a match') and enumerates the three possible responses, which cleanly separates it from siblings like withdraw_match_request and confirm_match_request. An agent can select it without opening the schema.

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

Usage Guidelines5/5

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

Gives explicit preconditions ('call it only after the user has said which of the three they want') and an explicit when-not ('send block only when the user asks for exactly that'). It also disambiguates sibling-adjacent choices by contrasting decline (one request, revisitable) with block (permanent, person-level).

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

All Overlap tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?