Skip to main content
Glama

get_task

Read-onlyIdempotent

Fetch task details, status, human-gate state, comments, artifacts, VCS links, and dependencies for agent coordination.

Instructions

Get task details: compact decision fields, active human_gate=true and status slug; descriptions and ordinary comment bodies are always complete. Comment IDs support reply/after; timestamps are UTC to the minute. Known automation comments are one-line summaries (include_auto=true restores their complete bodies). full=true restores non-capability REST fields. If status lookup is unavailable, status_id and an explicit status_lookup_error remain. Comments return the newest comments_limit entries (default 5, max 200) with pagination markers. Use since=RFC3339 from task.updated_at to avoid repeating an unchanged task and older comments.

Input Schema

NameRequiredDescriptionDefault
fullNoReturn the task (full description, non-capability fields, whole inline comments) instead of the compact view (default false).
sinceNoRFC3339 timestamp from an earlier call in this session (e.g. that response's task.updated_at, or your own last-call time). With it: include_comments returns only comments created after it, and the full task body (description and the rest) is included only if the task's own updated_at is after it too — the response then carries task_changed=true/false so you always know which you got, and a trimmed stub (id/status/assignee_name/updated_at in compact reads; status_id plus status_lookup_error if lookup fails, or the original status_id and assignee fields with full=true) instead of the full task when nothing changed, to avoid re-paying for the same ~5k tokens on a repeat call. Omit for the unfiltered default: full task body, but the comment tail still obeys comments_limit (default 5, max 200) — a longer thread needs list_comments paging.
task_idYesTask ID (full UUID or 6–12 char hex short-ID prefix).
include_autoNoReturn complete automation bodies in compact mode (ordinary comments are always complete).
comments_limitNoHow many of the NEWEST comments to include when include_comments=true (default 5, max 200). The tail is where an acting agent looks first; raise it when you need more of it. The API caps any single request at 200 — a longer thread is only readable end-to-end by paging list_comments (order=desc, page=N), never by one call here.
include_commentsNoInclude the task's most recent comments (see comments_limit for how many; the response carries comments_total_count and comments_has_more so a longer thread is never silently hidden).
include_artifactsNoInclude artifacts.
include_vcs_linksNoInclude linked PRs/MRs/commits/branches (id, provider, link_type, external_id, url, status, created_at) — use this instead of a raw REST call to diagnose a misclassified or stuck-status link.
include_dependenciesNoInclude dependencies.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.2/5.0
Behavior5/5

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

Despite annotations already declaring readOnly/idempotent/non-destructive, the description adds substantial behavioral context the annotations cannot convey: the ~5k-token cost of a repeat read, task_changed=true/false signaling, the status_lookup_error fallback when status resolution fails, and that comments silently cap at 200 per call. This is exactly the kind of disclosure the annotations leave out.

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?

It is front-loaded with the core purpose, but the body is a dense run-on of em-dash-separated clauses that partially duplicate the schema's own parameter descriptions. Much of it earns its place as return-shape detail, yet the wall-of-text format hinders scanning for the agent.

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?

With no output schema and nine parameters, the description carries the burden and largely does so: it explains the compact vs full return shapes, comment pagination markers and counts, the trimmed stub on unchanged reads, and status lookup failure. It is complete enough to call defensively, though artifact/dependency return shapes get no mention.

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 100%, so the schema already documents every parameter, including defaults and the comments_limit cap. The description largely restates those same semantics (default 5, max 200, include_auto, compact vs full) rather than adding new meaning, so the baseline 3 applies.

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?

The opening states a specific verb+resource ('Get task details') and immediately scopes what the retrieval returns: compact decision fields, active human_gate=true, status slug, descriptions and comment bodies complete. An agent can distinguish this from list_tasks, get_task_context, or get_my_tasks without opening any schema.

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?

It gives concrete when-to-use guidance for several parameters: since=RFC3339 to avoid re-paying for an unchanged task, include_auto=true to restore full automation bodies, comments_limit/list_comments paging for long threads, and include_vcs_links instead of a raw REST call. It never states when to prefer this tool over a sibling read tool like get_task_context, so it falls short of full alternative routing.

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