Overlap

Share what the user is going through as a match request

create_match_request

Destructive

Use this tool to save a private match request draft when the user wants to find a peer living through a similar personal situation. Write the match request from the current conversation. Write 2–5 sentences in the third person, and 200–1500 characters. Use the words of the user, not formal or clinical words. Cover three things: the situation, where the user is in it, and what help they want. Write it so that a stranger in the same place recognizes themselves. Any situation belongs here: an illness, a company, a move, a course, a hard year. Example of a good match request: "She was diagnosed with early-stage breast cancer four months ago and is halfway through chemotherapy. The medical side goes to plan. She finds the isolation harder than the treatment. The people around her keep telling her to stay positive. She hopes to hear from someone at a similar stage who understands the day-to-day of it." Never invent a detail. Never include a name, an email address, an employer or another personal identifier. With no replaces_draft_id, this tool saves a new independent private draft. With replaces_draft_id, it saves the complete revised text as a new draft and supersedes only the identified earlier draft. Existing open requests remain unchanged. The draft is not submitted to the matching pool and contacts nobody. Returns request_id, status and the exact stored request_text. Publishing uses the separate confirm_match_request tool and requires the user’s explicit approval of that exact stored text. Discarding uses withdraw_match_request with the draft’s request_id.

Input Schema

Name	Required	Description	Default
`request_text`	Yes	The complete text of the request. Write 2–5 sentences in the third person, and at most 1500 characters. Say what the user hopes to get from a meeting.
`replaces_draft_id`	No	The request_id of a draft the user has already seen. Pass it only for a revision. Leave it out for a new independent request.

Output Schema

Name	Required	Description
`status`	Yes
`request_id`	Yes
`instruction`	Yes
`request_text`	Yes	The stored text, to show the user word for word.

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": {
+    "instruction": {
+      "type": "string"
+    },
+    "request_id": {
+      "type": "string"
+    },
+    "request_text": {
+      "description": "The stored text, to show the user word for word.",
+      "type": "string"
+    },
+    "status": {
+      "const": "draft",
+      "type": "string"
+    }
+  },
+  "required": [
+    "request_id",
+    "status",
+    "request_text",
+    "instruction"
+  ],
+  "type": "object"
+}

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

Changed2 schema fields changedSep 14, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

First observedSep 13, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations: it states that the draft is not submitted to the matching pool and contacts nobody, that existing open requests are unchanged, that only the identified earlier draft is superseded, what is returned (request_id, status, exact stored request_text), and that the stored text is what downstream approval must match. The destructiveHint=true annotation is contextualized by the explicit supersede-only-that-draft statement rather than left unexplained.

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 purpose and routing, then writing rules, then lifecycle behavior. The embedded example is long but directly instructive for a free-text generation task. Slightly dense, but every sentence carries operational guidance rather than filler.

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?

For a 2-parameter text-creation tool the definition covers input constraints, anonymization rules, revision semantics, side effects, return values (even though an output schema exists), and the handoff to confirm_match_request/withdraw_match_request. Nothing needed to call it correctly is missing.

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?

Although schema coverage is 100%, the description meaningfully expands it: third-person voice, 2–5 sentences, a 200–1500 character floor/ceiling (the schema only says 'at most 1500'), the three required content elements (situation, current position, help wanted), a prohibition on inventing details or including identifiers, and a worked example. The replaces_draft_id semantics are also given a behavioral framing ('only for a revision').

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 and resource ('save a private match request draft') with the condition that selects it ('when the user wants to find a peer living through a similar personal situation'). It also distinguishes itself from the siblings that handle the later lifecycle stages (confirm_match_request for publishing, withdraw_match_request for discarding).

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?

Explicit routing: publishing goes through confirm_match_request and requires explicit user approval of the stored text; discarding goes through withdraw_match_request. The replaces_draft_id branch is also spelled out as 'new independent draft' vs. 'supersedes only the identified earlier draft', leaving nothing to inference.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?