Skip to main content
Glama

research_start

Start a web research session (required before searching) by defining topic, objective, and sub-questions. Returns session ID, date, budget, and rules for safe, audited searching.

Instructions

Start a web research session (required before searching). Returns session_id, today's date, budget and rules.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNoquick|standard|deep sets the budgetstandard
topicYesWhat you are researching (short)
freshnessNodefault recency windowany
objectiveYesThe answer the user needs
sub_questionsYes1-5 specific things to find out

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the call returns a session_id, today's date, budget and rules, but says nothing about whether repeated calls create duplicate sessions, whether sessions expire, or any side effects -- gaps that matter for a session-creating tool with zero annotation coverage.

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?

Two short sentences with the prerequisite front-loaded and zero filler. The trailing enumeration of return values is mildly redundant given an output schema exists, but it is brief enough not to waste space.

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?

For a 5-parameter tool with full schema coverage and an output schema, the description supplies the critical missing piece: the mandatory ordering before searching. It leaves minor gaps around session lifecycle and reuse, but nothing that would cause an obviously wrong invocation.

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 the schema already documents all five parameters (including the depth-to-budget link). The description adds no syntax or format detail beyond what the schema provides, making the baseline 3 appropriate.

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 ('Start a web research session') plus the ordering constraint '(required before searching)', which lets an agent distinguish this prerequisite call from the search tools. It does not explicitly differentiate itself from the sibling research_approve, so it stops short of 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?

Gives a clear condition for use -- it must be called before any searching -- which is the key routing signal an agent needs. It stops short of naming alternatives or stating exclusions (e.g. when research_approve is appropriate, or whether a session is reusable).

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