A
licenseNot graded
qualityB
maintenanceEnables AI coding agents to record and resume engineering work as durable, byte-exact threads of focus, decisions, evidence, and next steps.
2
Functional Source , Version 1.1, ALv2 Future
Overlap
Server Details
Records what you're working on so Overlap can introduce you to someone two weeks ahead of you.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 61.6% over 57 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.2/5.0
Scored across 7 tools
Disambiguation3/5
Most tools have distinct purposes (create/confirm/withdraw requests, respond to matches, get match details), but check_matches and preview_pool both return pool counts, and check_matches and get_match_details both read match information. The descriptions clarify usage, but the boundaries between these read-oriented tools are genuinely blurry.
Naming Consistency5/5
All seven tools follow a strict snake_case verb_noun pattern (check_matches, confirm_match_request, create_match_request, get_match_details, preview_pool, respond_to_match, withdraw_match_request). The convention is predictable and readable throughout.
Tool Count5/5
Seven tools is well-scoped for a peer-matching lifecycle: draft, publish, withdraw, preview pool, check state, inspect a match, and respond. Each tool earns its place without redundancy at the set level.
Completeness4/5
The surface covers the full match-request lifecycle (create draft, confirm, withdraw, check, preview, get details, respond with accept/decline/block) plus draft revision via replaces_draft_id. Minor gaps exist (e.g. no explicit list-conversations or read-messages operation), but core workflows are covered.
Available Tools
7 toolscheck_matchesCheck for matchesARead-onlyIdempotentInspect
Where the user stands. It returns every current match request, the number of other people in the pool, and any match. Use it to answer what the user submitted, and who they matched with. A match can appear days later.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| matches | Yes | |
| requests | Yes | |
| others_in_pool | Yes | Other people in the pool, each counted once. |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety is covered. The description usefully adds a non-obvious temporal trait: 'A match can appear days later,' telling the agent results are asynchronous and re-polling may be needed. This is real value beyond the structured fields.
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?
Three short sentences, mostly front-loaded and free of filler. The opening fragment 'Where the user stands' is slightly impressionistic, but the rest is efficient and earns its place.
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?
With an output schema present, the description need not enumerate return fields, and it still summarizes what comes back. Annotations cover the safety profile and there are no parameters, so the definition is nearly complete; only the absence of sibling routing keeps it from a 5.
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 tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify, and it correctly does not fabricate parameter detail.
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 states a specific resource and scope: it returns every current match request, the pool size, and any resulting match. The opener 'Where the user stands' is vague, but the following clauses clarify the verb+resource well enough to distinguish it from siblings like get_match_details and preview_pool.
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?
It gives usage context ('Use it to answer what the user submitted, and who they matched with') which implies when to call it, but never names an alternative tool or states an exclusion. The guidance is implied rather than explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
confirm_match_requestConfirm the draft match requestAInspect
Confirm one draft match request and add it to the matching pool. The other requests of the user do not change. It stays active until the user withdraws it. Call this ONLY after the user approves the exact stored text. Always pass its request_id.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | The request_id from create_match_request or check_matches. Always name the exact request that the user approved, or asked you to withdraw. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| status | Yes | |
| request_id | Yes | |
| matches_found | Yes | |
| match_limit_note | No | |
| pipeline_completed | Yes | False when matching ran out of time. It finishes in the background. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, and the description adds real side-effect scope: 'The other requests of the user do not change' and the persistence lifecycle 'stays active until the user withdraws it.' Both are behavioral facts not present in 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?
Four short sentences, front-loaded with the action and scope, then the guardrail. Efficient, though 'Always pass its request_id' is slightly redundant with the schema and could be trimmed.
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?
An output schema exists, so return values need no explanation; annotations carry the safety profile; and the description supplies the missing pieces — scope of side effects, lifecycle, and the approval precondition — for a single-parameter mutation 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 the schema already explains request_id thoroughly (including its origin in create_match_request or check_matches). The description's 'Always pass its request_id' merely restates what the schema provides, so baseline 3 applies.
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?
Specific verb+resource: 'Confirm one draft match request and add it to the matching pool.' An agent can distinguish this from create_match_request and withdraw_match_request by the confirm-to-pool action. It does not explicitly name the sibling it is not, so it stops short of 5.
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?
'Call this ONLY after the user approves the exact stored text' gives a clear precondition for invocation, and 'It stays active until the user withdraws it' implicitly points to the withdraw path. No alternative is named explicitly, so 5 is not warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_match_requestShare what the user is going through as a match requestDestructiveInspect
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.
ParametersJSON 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| request_id | Yes | |
| instruction | Yes | |
| request_text | Yes | The stored text, to show the user word for word. |
get_match_detailsGet match detailsARead-onlyIdempotentInspect
Get the full details of one match: what the other person wrote, why the two of them matched, something to open with, and where the match stands. It only reads. To accept, decline or block the match, call respond_to_match. Never promise an address.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| match_id | Yes | The match_id from check_matches. |
Output Schema
ParametersJSON 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 |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so 'It only reads' is largely redundant. However, 'Never promise an address' is a genuinely non-obvious behavioral caution that structured fields do not convey, adding real value beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences carry the purpose, the sibling routing, and the usage caution with no filler. The only minor redundancy is 'It only reads' against the readOnly annotation.
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?
An output schema exists, so the return payload need not be explained, and the description covers scope, alternative tool, and a use constraint. It leaves minor gaps such as error or auth behavior for a single-id lookup, but nothing an agent needs in order 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter with 100% schema description coverage, and the schema already states the source ('The match_id from check_matches'). The description adds no further naming, format, or provenance detail, so baseline 3 is appropriate.
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 ('Get the full details of one match') and enumerates the returned content: what the other person wrote, why they matched, an opener, and match status. That scope is distinguishable from check_matches (list) and respond_to_match (action).
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?
Explicitly routes the agent: 'To accept, decline or block the match, call respond_to_match' names the alternative and the condition that selects it. It also adds a negative constraint ('Never promise an address') that bounds how the result may be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preview_poolSee how many people are going through something similarARead-onlyIdempotentInspect
Count people in overlap's peer-connection pool who are going through a similar personal situation. Use when the user asks whether another person shares their situation before deciding whether to join. Do not use for intersections of lists, sets or schedules, dating, or finding licensed professionals. Returns a number and nothing else, capped at 10 — never anyone's words, name or details. It saves nothing: no match request is created and nobody is contacted. This is the one tool that works without an account.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | What the person is going through, in their own words. Two to five sentences is enough. This is only embedded and counted against — it is never stored and never shown to anyone. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | People in the pool with a similar situation, at most 10. |
| capped | Yes | True when the count hit the cap of 10. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial unannotated behavior: output is only a number capped at 10, no names or details are ever returned, nothing is persisted, no contact occurs, and it is the one tool usable without an account.
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?
Five short sentences, each carrying distinct information (trigger, exclusions, return shape, side-effect profile, auth requirement), with the core purpose front-loaded. No filler or repetition.
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?
An output schema exists, yet the description still usefully summarizes the return as a capped number, and it fully covers privacy, persistence, contact, and auth behavior. An agent has everything needed to decide and invoke 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 coverage is 100% and the parameter's own description already explains the free-text format and that it is embedded and never stored. The tool description adds no parameter-level syntax or constraints beyond that, so the baseline 3 applies.
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 (count) and resource (people in overlap's peer-connection pool matching a described situation), and is clearly separable from the match-request lifecycle siblings (create_match_request, respond_to_match, etc.). The title and description together make the intent unmistakable.
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 an explicit trigger ('when the user asks whether another person shares their situation before deciding whether to join') plus concrete exclusions (list/set/schedule intersections, dating, licensed professionals). It also implicitly routes the follow-up action to the join/match-request flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
respond_to_matchAnswer a matchADestructiveInspect
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.
ParametersJSON 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
ParametersJSON 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 |
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.
withdraw_match_requestWithdraw the match requestADestructiveInspect
Withdraw one match request, either a draft or an open one. Always pass its request_id. If it is unclear which one the user means, call check_matches first. The other requests of the user stay active. This voids a pending match from this request. It keeps a match that both people accepted.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | The request_id from create_match_request or check_matches. Always name the exact request that the user approved, or asked you to withdraw. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| request_id | Yes |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description adds substantive state-effect detail: sibling requests stay active, a pending match tied to this request is voided, and a mutually accepted match is preserved. These effects go beyond the annotation and answer what actually changes.
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?
Four short sentences, front-loaded with the core action and the fallback to check_matches. Mild redundancy with the schema's own request_id guidance, but nothing wasted.
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?
With annotations covering the safety profile, an output schema handling returns, and full schema coverage, the description's job is mostly to convey effects and routing – which it does. Missing only explicit reversibility/undo information.
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 coverage is 100%, so the schema already fully documents request_id. The description reinforces passing the exact request_id but adds no format or sourcing detail beyond the schema, so the baseline 3 applies.
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 (withdraw) and resource (one match request), and scopes it to drafts or open requests. This clearly separates it from siblings like create_match_request and confirm_match_request.
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?
Gives an explicit alternative and condition: when the target request is unclear, call check_matches first. It also clarifies the boundary case that already-accepted matches are kept, so the agent knows not to use it for confirmed matches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
7 tool updates
- Changed
check_matches1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "matches": { + "items": { + "additionalProperties": false, + "properties": { + "created_at": { + "type": "string" + }, + "match_id": { + "type": "string" + }, + "state": { + "type": "string" + }, + "their_request_snippet": { + "description": "The first 200 characters of their request.", + "type": "string" + }, + "they_accepted": { + "type": "boolean" + }, + "you_accepted": { + "type": "boolean" + } + }, + "required": [ + "match_id", + "created_at", + "state", + "their_request_snippet", + "you_accepted", + "they_accepted" + ], + "type": "object" + }, + "type": "array" + }, + "others_in_pool": { + "description": "Other people in the pool, each counted once.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "requests": { + "items": { + "additionalProperties": false, + "properties": { + "request_id": { + "type": "string" + }, + "request_text": { + "type": "string" + }, + "status": { + "enum": [ + "draft", + "open" + ], + "type": "string" + } + }, + "required": [ + "request_id", + "status", + "request_text" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "requests", + "others_in_pool", + "matches" + ], + "type": "object" +}
- Changed
confirm_match_request1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "match_limit_note": { + "type": "string" + }, + "matches_found": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "note": { + "type": "string" + }, + "pipeline_completed": { + "description": "False when matching ran out of time. It finishes in the background.", + "type": "boolean" + }, + "request_id": { + "type": "string" + }, + "status": { + "const": "open", + "type": "string" + } + }, + "required": [ + "request_id", + "status", + "matches_found", + "pipeline_completed", + "note" + ], + "type": "object" +}
- Changed
create_match_request1 field changed- changed
Output 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" +}
- Changed
get_match_details1 field changed- changed
Output 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" +}
- Changed
preview_pool1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "capped": { + "description": "True when the count hit the cap of 10.", + "type": "boolean" + }, + "count": { + "description": "People in the pool with a similar situation, at most 10.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "count", + "capped" + ], + "type": "object" +}
- Changed
respond_to_match1 field changed- changed
Output 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" +}
- Changed
withdraw_match_request1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "request_id": { + "type": "string" + }, + "status": { + "const": "withdrawn", + "type": "string" + } + }, + "required": [ + "request_id", + "status" + ], + "type": "object" +}
7 tool updates
- Changed
check_matches1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
confirm_match_request1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
create_match_request1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
get_match_details1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
preview_pool1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
respond_to_match1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
withdraw_match_request1 field changed- added
Input schema / additionalPropertiesAdded value: +false
2 tool updates
- Changed
get_match_details3 fields changed- removed
Input schema / properties / acceptRemoved value: -{ - "description": "Record that the user accepts this match.", - "type": "boolean" -} - removed
Input schema / properties / blockRemoved value: -{ - "description": "Never match the user with this person again. This is permanent. Set it only when the user asks for exactly that. A plain 'no thanks' is a decline, not a block.", - "type": "boolean" -} - removed
Input schema / properties / declineRemoved value: -{ - "description": "Pass on this match. It covers this request only. The next request from the same person can still match.", - "type": "boolean" -}
- Added
respond_to_match
5 tool updates
- Changed
confirm_match_request2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - removed
Input schema / additionalPropertiesRemoved value: -false
- Changed
create_match_request2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - removed
Input schema / additionalPropertiesRemoved value: -false
- Changed
get_match_details3 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / match_id / patternAdded value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
- Changed
preview_pool2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - removed
Input schema / additionalPropertiesRemoved value: -false
- Changed
withdraw_match_request2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - removed
Input schema / additionalPropertiesRemoved value: -false
1 tool update
- Changed
check_matches1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
6 tool updates
- First observed
check_matches - First observed
confirm_match_request - First observed
create_match_request - First observed
get_match_details - First observed
preview_pool - First observed
withdraw_match_request
Related MCP Connectors
- RoleoraOAuthcom.roleora
Log, search and summarise your work history in Roleora, the career record for professionals.
- BalladicOAuthcom.balladic
Fluid cowork platform. Synthesizes work data across boundaries, with project tracking built in.
Shared memory for a team in Claude Code: what one person records, everyone has.
- DonelaneOAuthapp.donelane
An agent records what it finished into a team's standup feed, one line at a time.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceLets coding agents like Codex, Cursor, and Claude Code share and resume each other's chats, and attach to a common task with saved notes that can be searched later. This keeps task state and decisions in sync no matter which agent you switch to.70 npm2MIT
- AlicenseNot gradedqualityBmaintenanceSaves the current state of a project — decisions, rejected approaches, open questions and the actual files — and hands it to any new chat, so you never re-explain a project twice. Local-first: everything is written to your own disk as plain Markdown and JSON, with no account and no telemetry.84 npm2Elastic 2.0
- AlicenseNot gradedqualityDmaintenanceEnables teams to share context and messages between Claude Code sessions via a relay, allowing collaborative work on the same project.8 npmMIT
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.