User Intuition

Upload Research Source

upload_research_source

Attach external evidence to a research session: TXT, Markdown, CSV, JSON, text PDF or DOCX, up to 10 MB. Send user-provided file bytes as base64. Uploading again creates another source; list sources after an uncertain response before retrying.

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": {
      "session_id": "<session_id>",
      "file_name": "<file_name>",
      "data_base64": "<data_base64>"
    },
    "name": "upload_research_source"
  }
}

Input Schema

Name	Required	Description
`file_name`	Yes	Base filename of the uploaded file, including its extension.
`session_id`	Yes	UUID of the research session, as returned by inspect_research_session.
`data_base64`	Yes	Raw file bytes encoded as standard base64; never a server path or URL.
`organization_id`	No	Organization for this operation and billing. Use list_organizations to choose an active membership.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026

addedInput schema / properties / file_name / description

Added value: +"Base filename of the uploaded file, including its extension."

addedInput schema / properties / session_id / description

Added value: +"UUID of the research session, as returned by inspect_research_session."

Changed1 schema field changedOct 22, 2026

changedInput schema / properties / organization_id / description

Previous value: -"Platform admins only: select an organization for this operation. Required when changing another organization’s study or using its wallet."New value: +"Organization for this operation and billing. Use list_organizations to choose an active membership."

AddedOct 17, 2026

TDQS

A3.8/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, and the description adds real value on top of that by explaining the duplicate-creation consequence ('Uploading again creates another source') and a retry-safety pattern. Beyond that it does not discuss failure modes (e.g. rejected formats or oversize payloads) or any storage/retention behavior.

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?

Three tight sentences: what it accepts first, then the input encoding, then the duplicate/retry caveat. There is no filler, and the most decision-relevant information (formats and size) is front-loaded.

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?

With annotations covering the safety profile and an output schema covering returns, the description only needs to carry format limits, encoding, and duplicate semantics, all of which it does. It stops short of covering rejection behavior or size-overflow handling, which would make it fully self-sufficient.

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 100%, so every parameter is already documented, which sets a baseline of 3. The description contributes mainly by restating the base64 requirement and translating the opaque maxLength of 13333336 into the human-meaningful 'up to 10 MB' limit, but it says nothing extra about session_id or organization_id beyond what the schema provides.

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 gives a specific verb and resource ('Attach external evidence to a research session') and enriches it with the supported formats (TXT, Markdown, CSV, JSON, text PDF, DOCX) and a 10 MB ceiling, so an agent knows exactly what this tool accepts. It does not explicitly differentiate itself from the similarly named upload_research_template sibling, which keeps it below a 5.

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?

It states the expected input shape ('Send user-provided file bytes as base64') and gives a concrete recovery rule: listing sources after an uncertain response before retrying. What is missing is any explicit when-not-to-use guidance, e.g. why one would choose this over uploading a template.

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

All User Intuition 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.