SwiftProbate

get_tasks

Read-onlyIdempotent

List tasks with optional filters. Use this to find tasks by status, category, asset, or search term. By default returns titles only; pass include_description: true to also get each task's full description (use this when reviewing tasks for jurisdiction or other content-level changes). Tasks come back in the dashboard's order; each has its position in the full task list and waiting_on (the unfinished task it can't start before, or null). Each task includes assigned_to (user ID) and assigned_to_name (who it is assigned to; null when unassigned). For "what's next", pass up_next: true to get exactly the dashboard's Up Next list.

Input Schema

Name	Required	Description
`limit`	No	Max number of tasks to return (default 20)
`search`	No	Search term to match against task title or description
`status`	No	Filter by task status
`up_next`	No	When true, ignore the other filters and return the dashboard's Up Next list: the next open tasks in the same order the user sees on their Overview page. Use this whenever the user asks what to do next.
`asset_id`	No	Filter by asset ID
`estate_id`	Yes	The estate to act on. Call list_my_estates first to get this id.
`task_category`	No	Filter by task category
`include_description`	No	When true, include each task's full description in the response. Use when reviewing tasks for content changes (e.g., jurisdiction review). Default false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

addedInput schema / properties / up_next

Added value: +{
+  "description": "When true, ignore the other filters and return the dashboard's Up Next list: the next open tasks in the same order the user sees on their Overview page. Use this whenever the user asks what to do next.",
+  "type": "boolean"
+}

First observedOct 11, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive safety, so the bar is lower. The description adds valuable behavior: default titles-only output, dashboard ordering, position and waiting_on semantics, up_next overriding other filters. Minor gap: doesn't mention pagination behavior for the limit parameter explicitly.

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?

Information is front-loaded with the core purpose first, then progressive detail. It's dense but each sentence conveys distinct behavior (default output, ordering, up_next, assignment fields). Slightly long, but nothing is truly wasted.

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?

No output schema exists, so the description carries the return-shape burden and does so well: titles by default, position, waiting_on, assigned_to/assigned_to_name. Combined with filters and up_next guidance, an agent has enough to call it correctly.

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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: include_description's purpose (jurisdiction/content review) and up_next's semantics (ignore other filters, match Overview page). These clarify intent beyond the schema text, justifying a 4.

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+resource ('List tasks') and immediately scopes it with default return behavior (titles only) and ordering. The description clearly differentiates this list/overview tool from the sibling get_task_detail by emphasizing summary fields and filters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says what to filter by (status, category, asset, search term), when to add include_description (content-level review), and directly addresses the 'what's next' case via up_next: true. Multiple concrete use conditions are provided with no ambiguity.

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

All SwiftProbate tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?