Skip to main content
Glama

get_item

Retrieve a task, habit, chore, or event by UUID, sequence number, canonical ref, URL, or GitHub alias. Returns compact details or full record with history and comments.

Instructions

Fetch a single item (Task / Habit / Chore / Event) by any reference.

item accepts any Ref input form and is resolved transparently:

  • a UUID (GET /items/{id});

  • a Sequence shorthand -- #123 or bare 123. This resolves against your personal org only, by design. For an item in a shared org, name it by its Canonical ref (acme-123) or its App URL instead -- both resolve across orgs;

  • a Canonical ref (slug-123, e.g. u-1y0e2v-123);

  • an App URL (https://app.defernowork.com/o/{org_slug}/items/{seq-or-id});

  • the unambiguous GitHub Alias owner/repo#N (it carries a /, so it can't be confused with a Canonical ref) -- auto-routed to the by-alias endpoint.

Deferno-# vs GitHub-# ambiguity. A bare #N always means a Deferno Sequence shorthand here; it is NOT inferred as a GitHub issue. Likewise an ambiguous string like ABC-223 collides with a Canonical ref and is therefore NOT auto-routed to alias resolution. Inferring which a user means from conversation is the job of a future context-adaptive classifier (see CONTEXT.md "Flagged ambiguities"), not this tool. Until then, use as_alias=true to force the alias path.

Args: item: Any Ref input form (or, with as_alias=true, a raw alias). full: When true, return the complete record (action history, comments, children, mood, attachments, ...) instead of the default compact projection. as_alias: When true, BYPASS the Ref classifier and look item up directly via GET /items/by-alias/{item}. This is the explicit escape-hatch for ambiguous external aliases (e.g. ABC-223) that the classifier deliberately will not auto-route. The unambiguous GitHub form owner/repo#N already routes to by-alias WITHOUT this flag.

Returns a compact projection by default (a small whitelist of fields, including description). Pass full=true for the complete record (action history, comments, children, mood, attachments, ...).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemYes
fullNo
as_aliasNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

No annotations provided, so the description carries full burden. It explains resolution behavior, default vs full response, and ambiguity handling. It does not explicitly state read-only or idempotency, but the 'get' verb and context imply it. Overall, it adds significant behavioral context.

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?

Description is well-structured: starts with a clear one-liner, then organized bullet points for input forms, and detailed explanation of ambiguity. Every sentence adds value. No wasted words.

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?

Given the complexity of input forms and ambiguity, the description is comprehensive. It covers all parameters, default behavior, and when to use flags. Output schema exists, so return values are not needed. Complete for the tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates. It explains all three parameters in detail: item (multiple forms, resolution, ambiguity), full (comparison to default), and as_alias (escape hatch). Adds rich semantics beyond 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?

The description clearly states it fetches a single item (Task/Habit/Chore/Event) by any reference. It distinguishes itself from sibling tools like search_items by focusing on single-item retrieval via various reference forms.

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?

The description implies when to use this tool (fetch a single item by reference) but does not explicitly contrast it with sibling tools like search_items or get_item_history. However, it provides detailed usage guidance for parameters, including when to use as_alias.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Circuit-Stitch/defernowork-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server