Sync by CHNLSYNC

Request a human broker callback

request_broker_callback

Ask a CHNLSYNC human broker to contact the user about their case.

Only call this with the user's explicit consent to share their name and email with CHNLSYNC. Requires the session credentials returned by ask_sync_advisor. The result's book_url is an optional scheduling link you may offer the user as a next step ("pick a time now"); the callback is already queued and a broker will reach out either way, so never present booking as required or as a confirmed appointment. Do not automatically retry after a timeout: the request may already be recorded.

Input Schema

TableJSON Schema

Name	Required	Description
`session_id`	Yes	Workspace ID returned by the advisor.
`contact_name`	Yes	Name the user consented to share.
`contact_email`	Yes	Email the user explicitly consented to share.
`session_token`	Yes	Private workspace credential.

Output Schema

TableJSON Schema

Name	Required	Description
`status`	Yes	Callback request recorded, not yet completed.
`book_url`	Yes	Optional scheduling link; booking is not required.
`disclosure`	Yes	Human-review disclosure supplied by the backend.

Schema Changelog

Changes observed during successful MCP inspections.

Changed19 schema fields changedSep 9, 2026

addedInput schema / properties / contact_email / description

Added value: +"Email the user explicitly consented to share."

addedInput schema / properties / contact_email / maxLength
```
Added value: +255
```
addedInput schema / properties / contact_email / minLength
```
Added value: +3
```
addedInput schema / properties / contact_email / pattern
```
Added value: +"^[^@\\s]+@[^@\\s]+\\.[^@\\s]+$"
```
addedInput schema / properties / contact_name / description
```
Added value: +"Name the user consented to share."
```
addedInput schema / properties / contact_name / maxLength
```
Added value: +255
```
addedInput schema / properties / contact_name / minLength
```
Added value: +1
```
addedInput schema / properties / contact_name / pattern
```
Added value: +"\\S"
```
addedInput schema / properties / session_id / description
```
Added value: +"Workspace ID returned by the advisor."
```

addedInput schema / properties / session_id / pattern

Added value: +"^[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}$"

addedInput schema / properties / session_token / description
```
Added value: +"Private workspace credential."
```
addedInput schema / properties / session_token / maxLength
```
Added value: +512
```
addedInput schema / properties / session_token / minLength
```
Added value: +1
```
addedInput schema / properties / session_token / pattern
```
Added value: +"^\\S+$"
```
removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / description

Added value: +"Recorded callback acknowledgement; this is not a confirmed appointment."

addedOutput schema / properties

Added value: +{
+  "book_url": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "description": "Optional scheduling link; booking is not required.",
+    "title": "Book Url"
+  },
+  "disclosure": {
+    "description": "Human-review disclosure supplied by the backend.",
+    "title": "Disclosure",
+    "type": "string"
+  },
+  "status": {
+    "const": "received",
+    "description": "Callback request recorded, not yet completed.",
+    "title": "Status",
+    "type": "string"
+  }
+}

addedOutput schema / required

Added value: +[
+  "status",
+  "book_url",
+  "disclosure"
+]

addedOutput schema / title
```
Added value: +"CallbackResponse"
```

First observedSep 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare non-read-only, non-idempotent, open-world behavior, and the description adds the reasons: the callback can be queued server-side so a retry may duplicate a recorded request, and the returned book_url is optional rather than a confirmation. This is exactly the kind of context annotations cannot convey.

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?

Front-loaded with the core action, then layered constraints in descending priority. Every sentence carries a distinct obligation (consent, credentials, book_url framing, no-retry) with no 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 mutation tool with an output schema, the description covers what an agent still needs: consent prerequisite, credential source, non-idempotency handling, and how to interpret the returned book_url. Nothing material 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?

Schema description coverage is 100%, so all four parameters are documented structurally (session_id as workspace ID, contact_name/contact_email as consented values, session_token as private credential). The description reinforces the consent framing but adds no syntax or format detail beyond the schema, which is the baseline 3 case.

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: asking a CHNLSYNC human broker to contact the user about their case. It also positions itself relative to the sibling ask_sync_advisor by naming it as the source of the required session credentials, so the agent can tell the two apart.

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 (user's explicit consent to share name and email; credentials from ask_sync_advisor), an explicit no-retry rule on timeout, and explicit presentation guidance for book_url ('never present booking as required or as a confirmed appointment'). When-to-use and when-not-to-act are both covered.

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

All Sync by CHNLSYNC 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?