Skip to main content
Glama
Sign In
Uoink

Uoink

by ryanbiddy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Start a research run

research_start

Start a local research run for a question with source and ASR budgets, returning a run ID, normalized scope, and any network sources that require user consent. Makes no network requests.

Instructions

Start a local research run for a question, with source and ASR budgets. Returns the run_id, normalized scope and network sources needing consent. Makes no network requests. Only the user's research_network_sources setting grants network consent; research tools cannot change it.

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": {
      "question": "<question>"
    },
    "name": "research_start"
  }
}

Input Schema

NameRequiredDescriptionDefault
sinceNoEarliest known publication date, YYYY-MM-DD; unknown dates remain eligible.
questionYesResearch question, 1-500 characters; surrounding whitespace is stripped.
max_sourcesNoSource budget, 1-30; discovery returns a pool of up to twice this number.
source_kindsNoDistinct sources to search; network sources require consent in settings. Reddit search is deferred.
max_asr_minutesNoASR budget in minutes, 0-1440; reserved for the later capture step.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.14.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations say readOnlyHint=false and openWorldHint=false; the description supports the openWorld claim by stating "Makes no network requests" and clarifies that creation of a run is local state. It also adds value the annotations cannot convey: which values are returned, that some sources need consent, and that consent is governed solely by the user's setting and cannot be changed by research tools. It stops short of saying whether the created run persists or how long it lives.

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 sentences, front-loaded with the action and return contract, then the no-network guarantee, then the consent rule. Nothing is redundant and no sentence could be dropped without losing information.

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

Completeness5/5

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

There is no output schema, so the description correctly names what comes back (run_id, normalized scope, consent-requiring sources), and it flags the network/consent constraint that would otherwise surprise an agent. For a five-parameter tool with fully described schema, this is complete enough to call correctly.

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 description coverage is 100%, so all five parameters are already documented with ranges, defaults and patterns. The description restates the existence of source and ASR budgets and the consent constraint on network sources, both of which are also in the schema, so it adds little meaning beyond it. Baseline 3 applies when the schema carries the detail.

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 ("Start a local research run for a question") and states the output contract ("Returns the run_id, normalized scope and network sources needing consent"). The word "local" plus "Makes no network requests" implicitly separates it from network-reaching research siblings, but no sibling is named outright, so differentiation still requires some inference.

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?

Usage is implied by the name and by the sequencing language around budgets and consent, but the description never says when to choose this over research_discover or research_capture, nor does it state prerequisites such as ordering within the research pipeline. An agent can infer this is the entry point, but that inference is left to it.

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

Deploy Server

Other Tools