relay/client/output

Extract the typed answer from a completed MCP tool call. A non-interactive caller can use require instead of handling all three result variants. Tool refusals and input requests retain their evidence; a transport error keeps the original client.Error. No retry decision is implied: combine evidence with the tool’s read-only hint and the application’s policy.

Types

One error boundary for callers requiring a tool’s output.

pub type Error {
  CallFailed(client.Error)
  ToolFailed(
    content: List(content.ContentBlock),
    structured: option.Option(value.Value),
  )
  InputRequired
}

Constructors

Stable classification; match a detailed variant only when needed.

pub type Kind {
  TransportFailure
  ToolRefusal
  NeedsInput
}

Constructors

  • TransportFailure
  • ToolRefusal
  • NeedsInput

Values

pub fn describe_error(error: Error) -> String
pub fn error_kind(error: Error) -> Kind
pub fn evidence(error: Error) -> client.Evidence

A server refusal or input request is a completed exchange. Only a transport failure can leave submission unknown.

pub fn meta(
  result: client.ToolResult(a),
  key: String,
) -> option.Option(value.Value)

Read one application metadata member from the first text block that contains it. Input-required results have no output metadata yet.

pub fn require(
  result: Result(client.ToolResult(a), client.Error),
) -> Result(a, Error)
pub fn require_discovered(
  result: Result(
    client.ToolResult(option.Option(value.Value)),
    client.Error,
  ),
) -> Result(value.Value, Error)

Extract a discovered tool’s structured value, or project a content-only answer to a JSON string of its text blocks. Only use this projection when text is sufficient; call_discovered retains all media blocks. An explicit structured null remains null, regardless of output schema.

✨ Search Document