goldseam

Read My Document for Selfie

read_my_document_for_selfie

Read-only

Optional evidence: read a document the person chooses to share and return its text and origin, so you can propose statements from its passages for the person to affirm. Reads PDF, Word (.docx) and plain text; text your host has already read can be sent as pasted. Reading a document affirms nothing and verifies nothing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "package": "<package>"
    },
    "name": "read_my_document_for_selfie"
  }
}

Input Schema

Name	Required	Description
`files`	No
`pasted`	No
`package`	Yes	The package the last GoldSeam Selfie answer returned (goldribbon_package_v1 with its selfie_interview part). Keep it for the person and send it back whole; GoldSeam keeps no copy.

Output Schema

Name	Required	Description
`limits`	No	What this answer could not do, each { code, statement }
`status`	No	What happened, or needs_attention with a problem
`package`	No	The person's package with the interview; absent when the call could not use it
`problem`	No	When status is needs_attention: code, statement, what_to_do
`contract`	Yes
`documents`	No	Each document's evidence_id, filename, slot, extraction_status and text
`statement`	Yes
`how_to_use`	No
`next_actions`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations only supply readOnlyHint, so the description's closing line 'Reading a document affirms nothing and verifies nothing' is genuinely additive: it prevents an agent from treating ingestion as validation or as an affirmation event. It also discloses supported formats (PDF, .docx, plain text). It does not mention error or rejection behavior for oversized files beyond what the schema states.

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?

Three sentences, front-loaded with the action and the person-consent framing, ending with the most important caveat. The 'Optional evidence:' prefix is slightly label-like but does real work. No filler sentences.

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?

An output schema exists, so return values need not be described, and the description correctly focuses on inputs and behavioral caveats. For a nested three-parameter ingestion tool, the remaining gap is guidance on combining files with pasted and on slot semantics.

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 33%, so the description must carry weight. It clarifies the file-format support behind 'files' and the rationale for the 'pasted' array (text already read by the host), which helps. It says nothing about the slot enum values or how the three inputs relate when both files and pasted are supplied, and the package parameter's meaning lives entirely in the schema.

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?

States a specific verb and resource: 'read a document the person chooses to share and return its text and origin', plus the downstream purpose (proposing statements to affirm). This is concrete and distinct from sibling retrieval tools like get_persona_transcript, but it never names an alternative sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Frames the tool as 'Optional evidence' and gives the condition that motivates a call: so passages can be turned into statements the person affirms. It also explains the alternate input route ('text your host has already read can be sent as pasted'). No explicit when-not guidance is given, e.g. when to skip reading a document.

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

All goldseam 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.