Skip to main content
Glama
spranab

Saga MCP

by spranab
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

task_list

Read-onlyIdempotent

List tasks across all epics with subtask and dependency counts. Filter by project, status, priority, assignee, branch, or tag to quickly locate relevant work.

Instructions

List tasks; without epic_id, across all epics. Includes subtask and dependency counts. Rows are compact: nulls and metadata dropped, descriptions cut to 120 chars (task_get for full). branch="current" restricts to the active git branch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNoFilter by tag
limitNoMax results
branchNoGit branch filter: "current" = active branch, "" = branch-agnostic only, omit = all.
statusNo
epic_idNoFilter by epic (omit for all tasks)
sort_byNoSort order: priority (critical first), created (newest first), due_date (earliest first), status (actionable first)priority
priorityNo
project_idNoScope to one project. Needed when a single database holds several projects; defaults to the SAGA_PROJECT env var if set, otherwise the whole database.
assigned_toNoFilter by assignee
include_deletedNoInclude removed tasks.
include_archivedNoInclude archived epics and their tasks.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed4 schema fields changedv1.10.0
    • changedInput schema / properties / branch / description
      Previous value: -"Filter by the git branch of the task's epic. Pass \"current\" to auto-detect; pass empty string to restrict to branch-agnostic epics. Omit to list all."New value: +"Git branch filter: \"current\" = active branch, \"\" = branch-agnostic only, omit = all."
    • addedInput schema / properties / include_archived
      Added value: +{
+  "default": false,
+  "description": "Include archived epics and their tasks.",
+  "type": "boolean"
+}
    • addedInput schema / properties / include_deleted
      Added value: +{
+  "default": false,
+  "description": "Include removed tasks.",
+  "type": "boolean"
+}
    • addedInput schema / properties / project_id
      Added value: +{
+  "description": "Scope to one project. Needed when a single database holds several projects; defaults to the SAGA_PROJECT env var if set, otherwise the whole database.",
+  "type": "integer"
+}
  2. Changed1 schema field changedv1.5.5
    • addedInput schema / properties / branch
      Added value: +{
+  "description": "Filter by the git branch of the task's epic. Pass \"current\" to auto-detect; pass empty string to restrict to branch-agnostic epics. Omit to list all.",
+  "type": "string"
+}
  3. First observedv1.5.3

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description adds useful output-shape details: subtask/dependency counts, compact rows, dropped nulls/metadata, 120-char description truncation, and branch scoping. No contradiction with annotations.

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 dense sentences, each carrying new information: default scope, row compactness/truncation, and branch special value. The key scoping statement is front-loaded and there is no filler.

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 read-only list tool with 11 well-described optional parameters and safety annotations, this is nearly complete. There is no output schema, so a bit more explicit return-shape detail would be ideal, but the compact-row and count information gives enough context for correct 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 82%, and the schema already explains branch semantics, sorting, project scoping, and defaults. The description adds little beyond restating the epic-scope behavior, so the baseline of 3 is appropriate.

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?

States a specific verb and resource ('List tasks') and immediately clarifies scope: all epics when epic_id is omitted. It distinguishes itself from the sibling task_get by noting that rows are compact/truncated and pointing to task_get for full descriptions.

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?

Provides a clear pointer to task_get when full descriptions are needed, and explains the special branch='current' behavior. It does not enumerate exclusions, but for a read-only list with no required parameters the main alternatives are implicit and mostly covered.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/spranab/saga-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server