ESQ Matching Engine

Help me request an introduction (needs my yes)

request_attorney_introduction

DestructiveIdempotent

Use only when the user asks to be introduced to ONE specific lawyer AND has seen that lawyer's name, the exact details to be shared and the consent text from get_attorney_profile, then said yes. Never call it on your own initiative or for several lawyers at once. Stores only the authorized fields; retries with the same idempotency_key do not duplicate. IMPORTANT: sending to lawyers is currently switched off, so the introduction is RECORDED, NOT SENT; tell the user and give them the lawyer's phone or profile link. Returns a referral id, its lifecycle_state and a private status token.

Input Schema

Name	Required	Description
`state`	Yes	US state, two-letter code or name, e.g. CA or California
`consent`	Yes
`contact`	Yes
`match_id`	No
`attorney_id`	Yes
`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 introduction
`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`	Yes
`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.

Changed2 schema fields changedNov 1, 2026

addedInput schema / properties / intake_notice_acknowledged

Added value: +{
+  "description": "True only after the user read: no attorney-client relationship exists yet and the lawyer may decline",
+  "type": "boolean"
+}

addedInput schema / properties / opposing_party_name

Added value: +{
+  "description": "Name of the other side, if any, so the firm can check conflicts. Not shared beyond the firm.",
+  "maxLength": 160,
+  "type": "string"
+}

First observedOct 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the most consequential fact an agent could miss: that sending is currently disabled, so the introduction is RECORDED, NOT SENT, with instructions to tell the user and offer a phone number or profile link. It also covers idempotency behavior and field-minimization ('stores only the authorized fields'), which annotations alone (destructiveHint/openWorldHint) could not convey.

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 trigger condition and the disabled-sending caveat, and no sentence is filler. It is dense single-paragraph prose with heavy capitalization, which slightly hurts scanability for such a long block.

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 13-parameter, consent-gated mutation with nested objects, the description covers the critical decision points (preconditions, single-recipient rule, disabled delivery, idempotency) and even summarizes the return. Remaining gap is the unexplained optional parameters, though the output schema and nested consent schema already document return shape and consent contents.

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?

Schema coverage is only 46%, but the description compensates for the highest-risk parameters: consent, authorized fields, attorney_id and idempotency_key are all explained in prose. Several parameters (match_id, practice_area, attribution_token, opposing_party_name, state, preferred_timeframe) remain undocumented in either place, so compensation is partial rather than complete.

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 (request an introduction to ONE specific lawyer) and immediately bounds the scope to a single, named recipient. It is clearly distinguishable from siblings like find_attorneys or get_attorney_profile, which it names as the prerequisite source.

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 has seen the name, exact details and consent text from get_attorney_profile, then said yes) and explicit exclusions (never on own initiative, never for several lawyers at once). An agent has no ambiguity about when to call it.

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?