Skip to main content
Glama
Sign In
Vibecoders MCP

Vibecoders MCP

by RaedBerjaoui
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

tasks_list

List background delegations newest first, and retrieve full output for a specific task by ID.

Instructions

List background delegations (those started with delegate background:true), newest first. Pass an id to get that task’s full output.

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": "tasks_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoa task id from a prior tasks_list — returns its full output

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the transparency burden. It discloses behavior beyond the bare listing: results are newest first, and passing an id returns full output. It could mention return format or error handling, but for a simple list tool, these are sufficient.

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?

The description is only two sentences, with the main purpose front-loaded in the first sentence and parameter guidance in the second. Every word earns its place; there is no fluff or repetition of schema details.

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?

Given the tool's simplicity (one optional parameter, no output schema), the description fully covers purpose, ordering, and optional parameter behavior. It is complete enough for an agent to select and invoke the tool correctly. No additional context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage for the 'id' parameter. The description adds valuable context by specifying 'a prior tasks_list' as the source of the id and that it returns 'full output,' which builds on the schema's description rather than repeating it. This justifies a score above the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and identifies the exact resource ('background delegations') with a clarifying filter ('started with delegate background:true'). It also specifies ordering ('newest first'), which distinguishes it from sibling tools like tasks_steer or tasks_interrupt.

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?

The description clearly states what the tool does and when to use it: to list background delegations. It also provides guidance for the optional id parameter ('Pass an id to get that task’s full output'), though it doesn't explicitly contrast it with alternatives like tasks_steer or tasks_interrupt.

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