Skip to main content
Glama
Sign In
Task Manager

Task Manager

by vshfrost
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

set_priority

Idempotent

Change a task's priority to asap, high, or low, or clear it with none so planning focuses on the right work.

Instructions

Змінити пріоритет: asap|high|low, або 'none' щоб зняти.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "priority": "<priority>"
    },
    "name": "set_priority"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
priorityYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

The annotations already establish a non-read-only, idempotent, non-destructive operation. Beyond that, the description adds the special clearing behavior of 'none' and the supported priority values, but it gives no further validation, error, or result behavior.

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?

A single compact sentence front-loads the action and immediately supplies the accepted values and clearing convention. Every part contributes useful information, with no redundant wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-argument setter, the value list and annotations cover much of what an agent needs. However, the unnamed resource and unexplained id remain invocation gaps, and the absence of an output schema leaves the result entirely undocumented.

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?

With 0% schema description coverage, the description usefully documents priority's accepted values—'asap', 'high', 'low', and 'none'—and explains the last value's semantics. It adds nothing about id, leaving one of the two required parameters semantically undocumented.

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?

The description says "Змінити пріоритет" ("Change priority") and provides concrete values, making the operation clear. It does not explicitly name the resource whose priority changes or differentiate the tool from siblings such as edit_task.

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

Usage Guidelines3/5

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

The phrase "або 'none' щоб зняти" explains how to clear a priority rather than set it, providing limited operational guidance. There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance.

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