Skip to main content
Glama
Sign In
Zearch MCP

Zearch MCP

Official
by zearchcomputer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List research runs

list_runs
Read-onlyIdempotent

Retrieve recent Zearch research runs, newest first, with optional limit and starting_after pagination to browse shared app/API history.

Instructions

List your recent Zearch runs, newest first. The app and the API share one history. Free. Page with starting_after.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_runs"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
starting_afterNoRun id from the previous page.

Output Schema

NameRequiredDescriptionDefault
dataYes
objectNo
has_moreNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare a safe, idempotent, closed-world read, so the description needn't restate safety. It adds genuinely new context beyond them: results are newest-first, the app and API share a single history, calls are free, and paging uses the cursor parameter.

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?

Four short, front-loaded sentences with no filler; identity and ordering come first, then the shared-history and cost facts, then the paging hint. Nothing is wasted.

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 no explanation, and this is a simple two-parameter read tool. The remaining gap is the unexplained limit parameter and the absence of any routing advice to siblings, which is minor at this complexity.

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 50%: starting_after is documented in the schema, while limit is only constrained (1-100, default 20) without explanation. The description clarifies that starting_after drives pagination but says nothing about limit or page-size behavior, so it adds only partial value over 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?

The description states a specific verb and resource ("List your recent Zearch runs") plus ordering ("newest first"), which clearly separates it from the singular get_run sibling. It stops short of explicitly naming any alternative, so it is clear but not maximally differentiating.

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: use this to see recent runs, newest first. The only concrete operational guidance is "Page with starting_after," which covers multi-page retrieval but not when to prefer this over research or get_run, nor any exclusions.

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