Skip to main content
Glama
andreasd083

amazing-marvin-complete-mcp

by andreasd083
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_due_items

Read-only

Get open tasks and projects with a deadline today or earlier. Filters Keep just one (carry) as the app does: only the oldest open occurrence per recurring task is shown. Only the current one (skip) is not filtered here.

Instructions

Get open tasks and projects with a deadline today or earlier. Filters Keep just one (carry) as the app does: only the oldest open occurrence per recurring task is shown. Only the current one (skip) is not filtered here. The mode is read only for recurring tasks with an open occurrence before today and cached until local midnight; changes made in the app take effect by the next day at the latest. The response gives hidden_count; include_hidden=true includes all.

Input Schema

NameRequiredDescriptionDefault
byNoDeadline up to and including YYYY-MM-DD; omit for today
include_hiddenNoTrue = include occurrences the app hides (Keep just one)

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.7.3
    • addedInput schema / properties / include_hidden
      Added value: +{
+  "default": false,
+  "description": "True = include occurrences the app hides (Keep just one)",
+  "type": "boolean"
+}
  2. First observedv1.3.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint, leaving the description to carry behavioral weight. It discloses substantive traits: which recurring occurrences are filtered, that results are cached until local midnight, and that app-side changes may lag by a day — genuine operational context an agent needs to interpret staleness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is correctly front-loaded in sentence one. However, the middle sentences are dense and jargon-laden ('Keep just one (carry)', 'Only the current one (skip) is not filtered here'), so some sentences obscure more than they earn.

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?

For a read-only query with an output schema and complete annotation coverage, the description supplies everything needed: scope, recurrence filtering, caching/staleness, and the hidden-item behavior. Return-format details are correctly left to the output schema.

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 adds meaning to include_hidden by explaining the underlying 'Keep just one (carry)' filter it toggles. The 'by' parameter gets no extra meaning, but the added filter semantics push this above the baseline.

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?

States a specific verb+resource+scope: 'Get open tasks and projects with a deadline today or earlier.' The scope is precise, but it never references the sibling get_today_items, whose overlap with this tool ('deadline today or earlier' vs. today's items) is left for the agent to infer.

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

Usage Guidelines2/5

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

The description explains internal filtering behavior but never states when to choose this tool over get_today_items, get_done_items, or get_tracked_item. No prerequisites, no explicit exclusions, no alternative naming — the agent must infer selection from scope alone.

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