Onplana

list_overdue

Read-onlyIdempotent

Answers "what is overdue across my projects" and "which tasks are late" from the user's Onplana workspace. List tasks due before today (in the time zone of the user; a task due today is not overdue) and NOT yet DONE, across every project visible to the caller. Optional projectId filter to narrow to one project. Returns up to 25 tasks ordered by most-overdue first, with a daysOverdue field so the model can prioritise response. Use list_my_tasks({overdueOnly:true}) for "MY overdue tasks only" - this tool returns overdue tasks across all assignees. Each row carries collaborators, the people working on the task besides its assignee. Optional underTaskId narrows to the tasks under one task at any depth, such as a phase and its work packages. workItemsOnly true leaves out summary tasks (a task with subtasks, such as a phase), false includes them; the response's workItemsOnly field, when present, says which it read. When the response carries hasMore true, more tasks are overdue than were returned and total counts them all: raise limit, narrow by projectId or underTaskId, or read summarize_project for project-wide counts.

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_overdue"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Default 25, max 50.
`projectId`	No	Optional - narrow to one project.
`underTaskId`	No	Optional - only tasks under this task (a phase or other summary task), at any depth.
`workItemsOnly`	No	True: leave out summary tasks (tasks with subtasks). False: include them.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 14, 2026

addedInput schema / properties / underTaskId

Added value: +{
+  "description": "Optional - only tasks under this task (a phase or other summary task), at any depth.",
+  "type": "string"
+}

addedInput schema / properties / workItemsOnly

Added value: +{
+  "description": "True: leave out summary tasks (tasks with subtasks). False: include them.",
+  "type": "boolean"
+}

Changed1 schema field changedOct 19, 2026

changedInput schema / properties / projectId / description

Previous value: -"Optional — narrow to one project."New value: +"Optional - narrow to one project."

AddedJun 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description still adds real behavior: due-today is not overdue, time-zone basis, DONE exclusion, 25-row cap, most-overdue-first ordering, daysOverdue and collaborators fields, and what hasMore/total mean. The only gap is that it never states the recovery ceiling implied by limit's max of 50.

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?

Front-loaded with the answering scope, then parameters, then the hasMore recovery guidance — a sensible order. It is dense but nearly every sentence carries distinct information; minor redundancy exists between the workItemsOnly sentence and the schema text.

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?

There is no output schema, and the description compensates by naming the returned fields, ordering, cap, and pagination semantics. For a zero-required-parameter list tool, an agent has everything needed to call and interpret 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 the baseline is 3, but the description goes beyond the schema: underTaskId is clarified as any depth such as a phase and its work packages, workItemsOnly is tied to the definition of a summary task, and the response's workItemsOnly echo is disclosed. It does not restate limit's default or max, leaving that to the schema.

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 due before today... and NOT yet DONE") plus scope ("across every project visible to the caller"). It explicitly distinguishes itself from the sibling list_my_tasks by noting this tool returns overdue tasks across all assignees.

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?

Gives explicit usage conditions with example user phrasings, names the alternative (list_my_tasks({overdueOnly:true})) and the condition selecting it ("MY overdue tasks only"), and routes to summarize_project for project-wide counts when hasMore is true. Exclusions are stated rather than inferred.

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

All Onplana 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.