MyHumanRep: Contact a Human

Request an independent witness

request_independent_witness

Idempotent

Ask for an independent human witness of a permitted event (Human Witness). Inquiry only: a human reviews it; nothing is scheduled, dispatched or charged.

Input Schema

Name	Required	Description
`budget`	No
`context`	No
`objective`	No
`why_human`	No
`persona_id`	No
`deliverables`	No
`service_tags`	No
`budget_amount`	No
`location_text`	No
`budget_currency`	No
`conversation_id`	Yes	conversation_id returned by start_conversation.
`desired_outcome`	No
`preferred_rep_id`	No
`client_request_id`	Yes	Required idempotency key, unique per conversation. Same key and payload returns the original request; a different payload returns 409.
`problem_statement`	No
`timing_preference`	No
`conversation_token`	No	conversation_token returned once by start_conversation. Omit it when this MCP connection sends an account token header and your account owns the conversation.
`deadline_preference`	No
`evidence_requirements`	No
`human_capability_needed`	No
`authorization_description`	No
`confidentiality_preference`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 31, 2026

changedInput schema / properties / conversation_token / description

Previous value: -"conversation_token returned once by start_conversation."New value: +"conversation_token returned once by start_conversation. Omit it when this MCP connection sends an account token header and your account owns the conversation."

changedInput schema / required

Previous value: -[
-  "conversation_id",
-  "conversation_token",
-  "client_request_id"
-]New value: +[
+  "conversation_id",
+  "client_request_id"
+]

First observedOct 31, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Beyond the annotations, the description adds important behavioral boundaries: a human reviews the request, and nothing is scheduled, dispatched, or charged. This meaningfully clarifies the nature of the inquiry, though it does not explain the request lifecycle or return behavior in detail.

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?

The description is two tightly written sentences with no wasted wording. The core purpose and the inquiry-only constraint are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 22-parameter tool with no output schema, the description gives a useful high-level behavioral picture but omits parameter expectations and outcome details beyond human review. Given the annotations and the schema's field descriptions, it is minimally adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are 22 parameters and schema description coverage is only 14%, so the description should compensate by explaining key fields. It provides no parameter-level guidance at all, leaving the agent to rely entirely on the schema for required IDs, objective/problem_statement, budget, location, and other semantics.

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 uses a specific verb and resource: asking for an independent human witness of a permitted event, labeled Human Witness. It clearly marks the operation as inquiry-only, but it does not explicitly distinguish it from other request_human_* siblings such as request_human_observation or request_human_representative.

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 implies when to use the tool by saying it is for a permitted event and is inquiry-only. However, it does not explicitly state when to choose it over sibling tools or when not to use it, so the agent must infer the routing.

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

All MyHumanRep: Contact a Human 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?