Skip to main content
Glama

things_get_area

Retrieve all to-dos and projects from a specific area in Things 3 to organize and manage tasks effectively.

Instructions

Get all items in a specific area

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
area_idYes
max_resultsNoLimit number of results returned (defaults to all if not specified)

Implementation Reference

  • The logic for executing the "things_get_area" tool, which uses the area_id from the parameters to call the appropriate AppleScript file.
    } else if (toolName === 'things_get_area') {
      const areaParams = params as z.infer<typeof GetAreaSchema>;
      scriptArgs = [areaParams.area_id];
    } else if (toolName === 'things_get_todo_details') {
      const todoParams = params as z.infer<typeof GetTodoDetailsSchema>;
      scriptArgs = [todoParams.id];
      // Don't pass maxResults for todo details since it's a single item
      delete options.maxResults;
    }
    
    const output = await executeAppleScriptFile(scriptName, scriptArgs, options);
  • src/tools/get.ts:67-70 (registration)
    Registration of the "things_get_area" tool.
      name: 'things_get_area',
      description: 'Get all items in a specific area',
      schema: GetAreaSchema
    },
Behavior2/5

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

With no annotations provided, the description carries full disclosure burden but reveals almost nothing: it doesn't specify if the operation is read-only (though 'Get' implies it), what happens if area_id is invalid, whether 'items' includes completed/archived todos, or if pagination applies beyond max_results.

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?

Extremely efficient at 7 words with no redundancy. However, the brevity crosses into under-specification given the lack of annotations and sibling ambiguity. Structure is front-loaded but insufficiently informative.

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

Completeness2/5

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

Inadequate for safe invocation. No output schema, no annotations, undocumented area_id semantics, and unexplained 'items' concept in the Things domain. Should clarify relationship to sibling tools and disclose error handling for invalid area_id.

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 coverage is 50% (max_results described, area_id bare). The description adds context for area_id by referencing 'specific area', establishing it as a container identifier, but offers no format guidance (UUID vs slug) or examples. Baseline appropriate for partial schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description provides a clear verb ('Get') and resource ('items in a specific area'), but uses vague terminology ('items' undefined) and fails to explicitly distinguish from sibling 'things_get_areas' (which likely lists areas, not items within them). The scope is implied but not precise enough to prevent selection errors.

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?

No guidance provided on when to use this versus siblings like 'things_get_project', 'things_get_areas', or 'things_get_inbox'. The agent has no signal whether an 'area' is a workspace, location, or project container, nor when to prefer this over other retrieval tools.

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/hildersantos/things-mcp'

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