ESQ Matching Engine

Send my message to the lawyer I picked (needs my yes)

send_client_message

DestructiveIdempotent

Use only when the person asked to contact ONE specific lawyer they picked, has seen the lawyer's name, the exact message and details to be shared and the consent text, and said yes. Never call it on your own initiative or for several lawyers at once. Call preview_client_message first and pass its approval_code: if the recipient or the text changed since the person's yes, it is refused. Stores only the approved fields; retries with the same idempotency_key do not duplicate, and reusing a key for different details is refused. The same rule applies to every listed lawyer. Returns a contact_request_id, its lifecycle_state and a private status token. This is a listing service, not a lawyer referral service. No lawyer pays for placement or ranking of any kind.

Input Schema

Name	Required	Description
`state`	Yes	US state, two-letter code or name, e.g. CA or California
`consent`	Yes
`contact`	Yes
`entry_id`	No	The entry_id from start_from_directory_profile, if the user started from a directory listing. Counts the listing visit; carries no personal data.
`match_id`	No
`pending_ok`	No	Deprecated since 2026-11-04 and ignored. Messages no longer wait for anything a lawyer buys.
`attorney_id`	Yes
`approval_code`	No	The approval_code from preview_client_message for the exact version the user said yes to. If anything changed since, the request is refused and nothing is stored.
`practice_area`	No
`matter_summary`	Yes	Summary the USER read and approved for sharing with this lawyer
`idempotency_key`	No	Same key on retries prevents a duplicate message
`attribution_token`	No	Signed campaign/partner token issued by ESQ Matching Engine, if the user arrived through a partner link
`opposing_party_name`	No	Name of the other side, if any, so the firm can check conflicts. Not shared beyond the firm.
`preferred_timeframe`	No
`preferred_contact_method`	Yes
`intake_notice_acknowledged`	No	True only after the user read: no attorney-client relationship exists yet and the lawyer may decline

Output Schema

Name	Required	Description	Default
`notice`	Yes
`status`	Yes
`consent`	Yes
`attorney`	Yes
`match_id`	Yes
`duplicate`	Yes
`next_step`	Yes
`created_at`	Yes
`submission`	Yes
`api_version`	Yes
`destination`	Yes
`referral_id`	Yes
`consultation`	Yes
`last_updated`	Yes
`status_check`	No
`status_token`	Yes
`qualification`	Yes
`delivery_notice`	No
`lifecycle_state`	Yes
`attorney_response`	Yes
`consent_text_shown`	Yes
`delivered_to_lawyer`	Yes
`personal_details_deleted`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / approval_code / pattern

Previous value: -"^apr_[a-f0-9]{32}$"New value: +"^(apr_[a-f0-9]{32}|apr2_[0-9a-z]{6,12}_[a-f0-9]{32})$"

Changed1 schema field changedNov 5, 2026

changedOutput schema / required

Previous value: -[
-  "api_version",
-  "referral_id",
-  "status",
-  "lifecycle_state",
-  "delivered_to_lawyer",
-  "delivery_notice",
-  "match_id",
-  "created_at",
-  "last_updated",
-  "attorney",
-  "destination",
-  "submission",
-  "attorney_response",
-  "consultation",
-  "qualification",
-  "consent",
-  "personal_details_deleted",
-  "next_step",
-  "notice",
-  "duplicate",
-  "status_token",
-  "consent_text_shown"
-]New value: +[
+  "api_version",
+  "referral_id",
+  "status",
+  "lifecycle_state",
+  "delivered_to_lawyer",
+  "match_id",
+  "created_at",
+  "last_updated",
+  "attorney",
+  "destination",
+  "submission",
+  "attorney_response",
+  "consultation",
+  "qualification",
+  "consent",
+  "personal_details_deleted",
+  "next_step",
+  "notice",
+  "duplicate",
+  "status_token",
+  "consent_text_shown"
+]

AddedNov 5, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the approval_code precondition, refusal behavior if details changed, idempotency_key semantics, storage limits, and return fields. This adds substantial behavioral context for a destructive, open-world, idempotent action.

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?

The description is dense but appropriately front-loaded with the critical consent condition and the preview requirement. The listing-service disclaimer is useful context but slightly outside immediate invocation needs, keeping it from a perfect score.

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 high-stakes 16-parameter mutation with nested consent and an output schema, the description covers the essential consent, approval, idempotency, and refusal behaviors well. It is not fully complete on parameter-level semantics, but the output schema reduces the need to explain return values.

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 only 56% across 16 parameters, so the description must compensate. It adds valuable meaning for approval_code, idempotency_key, consent, and approved fields, but leaves many parameters such as attorney_id, state, contact, preferred_contact_method, and intake_notice_acknowledged without added description-level guidance.

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 states a specific action: sending a user-approved message to one specific lawyer, with explicit constraints. It clearly distinguishes this tool from preview_client_message and from any multi-lawyer or proactive sending.

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?

It gives explicit when-to-use conditions: only after the user picked one lawyer, saw the exact message and consent text, and said yes. It also gives when-not-to-use conditions and routes the agent to preview_client_message first.

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

All ESQ Matching Engine 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?