omnifocus-mcp

by steveardis

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
Disambiguation5/5
Each tool targets a distinct resource/action combination: folders, tags, projects, and tasks each have their own CRUD and lifecycle tools. Overlapping verbs like complete, drop, and delete are clearly differentiated by their status-only versus destructive semantics.
Naming Consistency5/5
Tool names consistently follow a verb_noun snake_case pattern: list_projects, get_task, create_folder, edit_tag, delete_project, complete_task, drop_project, and move_task. The naming style is uniform across all resources, making the set predictable and easy to navigate.
Tool Count2/5
27 tools exceeds the 25+ threshold and feels heavy even though the server covers four distinct OmniFocus entity types. Each tool has a clear purpose, but the overall surface is larger than a typical well-scoped MCP server needs.
Completeness4/5
The tool set provides strong lifecycle coverage for folders, tags, projects, and tasks, including list/get/create/edit/delete plus task/project state transitions and moves. Minor gaps exist, such as no direct way to move folders or tags after creation and no explicit reopen/restore operation, but most workflows are well supported.
Average 4/5 across 27 of 27 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Rename' implies a mutation, but there is no disclosure about permissions, side effects, reversibility, error behavior, or what happens if the folder ID does not exist. The behavioral picture is thin.
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?
The description is a single clear sentence with action and resource first. Every word earns its place; there is no irrelevant detail or redundancy.
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-parameter rename, the description is serviceable, but with no annotations and no output schema, the agent does not know the return format, error conditions, or any broader constraints. Missing this context makes it less than fully complete.
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 0%, so the description must compensate. 'By its ID' clarifies the id parameter's role, and 'rename' implies name is the new folder name. However, it does not explicitly map each parameter, and the simple param names already convey much of the meaning.
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 clearly states the action (rename), the resource (existing OmniFocus folder), and the identifying mechanism (by its ID). This distinguishes it from siblings like create_folder, delete_folder, and get_folder, though it does not explicitly name alternatives.
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 implies the tool should be used when renaming a folder, but it gives no explicit guidance on when to use it versus create_folder/delete_folder, no mention of any constraints or prerequisites, and no exclusion conditions. This is minimal implied usage rather than real guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state the outcome and return value, but it omits whether completion cascades to subtasks, whether it is reversible, whether permissions are needed, or what happens if the task is already complete.
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?
The description is two short sentences with no filler. The action and identification mechanism are front-loaded, and the return-value sentence adds useful information without bloating the description.
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 single-parameter mutation, the core invocation details are present: what the tool does, how to identify the resource, and what it returns. However, without annotations or an output schema, it lacks side-effect and reversibility caveats and does not steer the agent to sibling tools like complete_project.
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 100% for the single id parameter, so the baseline is 3. The description adds the useful clarification that the ID is stable, reinforcing that it is the primaryKey, but it does not provide additional format or source details beyond what the schema already states.
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 uses a specific verb and resource: 'Mark a task complete' and distinguishes this from siblings like complete_project and delete_task. 'By its stable ID' also clarifies that the task is referenced by primary key rather than by name, which differentiates it from name-resolution tools.
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 gives no when-to-use or when-not-to-use guidance. It does not mention that complete_project is the counterpart for projects, nor does it explain when complete_task is preferable to edit_task or other task mutations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the return behavior ('Returns the updated project detail'), but it omits mutation consequences entirely: whether completing cascades to child tasks, whether the action is reversible, and what happens if the project is already complete.
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?
Two sentences with the action front-loaded and the return behavior as the only supplementary detail. Every word earns its place with no waste.
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?
For a mutating tool with zero annotations and no output schema, the description is too thin: it discloses the action and return but leaves side effects, reversibility, and the relationship to sibling edit/delete operations unspecified. An agent cannot predict the consequences of calling it.
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 100%, with the id parameter already documented as the project's primary key. The description adds no parameter meaning beyond the schema, 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?
States a specific action ('Mark a project as done') with the resource clearly identified, and the parenthetical '(complete)' removes ambiguity about the state change. The dedicated completion semantics distinguish it from sibling operations like edit_project or delete_project, which cover modification and removal.
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 intended use — completing a project — is implied by the action verb, but the description gives no explicit context about when to choose this over edit_project (which could set a status) or drop_project, nor any exclusions. There is no 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates a state-changing operation and states that the updated project detail is returned. However, it does not disclose whether dropping is reversible, idempotent, or affects related tasks/resources, which would be helpful for a status-mutating tool.
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?
The description is two short sentences with no filler. The primary action is front-loaded, and the return behavior is stated clearly. Every word earns its place.
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 single-parameter tool, the description covers the core action and return value. However, without annotations or an output schema, it leaves some gaps: it does not clarify how 'dropped' differs from other project statuses, whether the action is reversible, or what side effects (if any) occur. This is adequate but not fully complete.
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?
The single parameter 'id' is fully documented in the schema with 100% coverage, so the description does not need to add much. It adds no extra meaning beyond what the schema already provides, which is acceptable given the high schema coverage.
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 uses a specific verb ('Mark') and resource ('project') with a clear state change ('as dropped'). It is easily distinguishable from sibling tools like delete_project (physical removal) and complete_project (completion status), even without explicit comparisons.
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?
There is no guidance about when to use this tool versus alternatives. The description states what it does but not when it should be chosen over complete_project or delete_project, nor any conditions or prerequisites for marking a project as dropped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the mutation ('Mark a task dropped') and the return value ('Returns the updated task detail'), but it does not disclose whether the action is reversible, what 'dropped' means relative to other states, or any side effects such as cascading to subtasks. This is acceptable for a simple state-change tool but not thorough.
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?
Two short sentences, zero wasted words, and the action is stated first with the return value second. The entire definition is scannable and directly on point for a single-parameter tool.
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?
For a tool with one parameter, no output schema, and no nested objects, the description is nearly complete: it names the action, the target, the identifying property, and the return value. The only missing context is usage criteria relative to alternate state-changing siblings, but for a simple operation this is adequate.
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?
The schema provides 100% coverage with a clear description of 'id' as 'The task's id.primaryKey'. The description's phrase 'stable ID' adds minimal semantic enrichment by implying the ID is persistent, but it does not meaningfully exceed what the schema already communicates. Baseline 3 is appropriate given the high schema coverage.
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 uses a specific verb ('Mark'), a specific resource ('a task'), and a distinct outcome ('dropped') that differentiates it from sibling tools like delete_task and complete_task. The phrase 'by its stable ID' also clarifies the exact input mechanism.
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 implies when to use the tool (when you want to mark a task dropped) but provides no guidance on alternatives or exclusions. It does not mention how this relates to delete_task, complete_task, or other task state changes, leaving the agent to infer the decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses an error condition and parent/child placement semantics. It does not discuss permissions, side effects, idempotency, or what happens on invalid IDs, but it is more transparent than a bare 'create task'.
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?
Three short sentences, front-loaded with the purpose, and the placement rules are compressed without redundancy.
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?
For an 11-parameter creation tool with no annotations and no output schema, the description explains only placement. It leaves out how the remaining parameters behave, response/return behavior, and error handling beyond the conflicting-ID case. That is a significant coverage gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so this description must compensate. It meaningfully explains projectId and parentTaskId and their mutual exclusivity, but it says nothing about the other nine properties (tagIds, dueDate, repetitionRule, etc.), many of which have no descriptions in the schema either.
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 opens with a specific verb and resource ('Create a new task') and then clarifies the three placement variants, which separates it from the unrelated create_* siblings though it doesn't name them.
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 explicit conditions for placement: omit both for inbox, include projectId for project, include parentTaskId for subtask, and states the error case for both together. It doesn't name alternative tools, but the placement guidance is sufficient for selecting this tool over edit/complete/drop.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It discloses the folder placement behavior and optional attribute settings, but it is silent on response shape, required name, defaults, validation failures, and side effects. This is useful but not deeply transparent.
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?
Two sentences with no filler. The placement guidance is front-loaded, followed by the optional parameters, and every clause adds distinct value.
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?
Given the complexity (10 parameters, nested object, no output schema, no annotations), the description gives a usable mental model for basic creation and folder placement. However, it does not explain return values, defaults for unspecified fields, or error behavior, so an agent is left with open questions for edge cases.
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 0%, so the description is the only prose for parameters. It adds real meaning for folderId and names type, status, reviewInterval, and tags with their enum/behavioral context, but it omits note, dueDate, deferDate, flagged, and the required name. It partially compensates for the schema gap but not completely.
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 uses a specific verb and resource ('Create a new OmniFocus project') and clarifies the main sub-scope: top-level vs inside a folder. This clearly distinguishes it from sibling tools like create_folder and create_task.
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 explicit placement guidance: omit folderId for top-level, provide it for inside a folder. It does not explicitly contrast with edit_project or other alternatives, but the creation context is clear and the main decision point is handled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool creates a new resource and how parent nesting affects placement, but it does not mention potential duplicate-name behavior, required existence of the parent folder, or response/return details.
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 sentence that front-loads the core purpose and then explains the only conditional parameter. Every clause adds value, with no filler or repetition of schema details.
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?
For a simple two-parameter create operation with no nested objects and no output schema, the description covers the essential calling decisions. The main gap is lack of detail about error conditions or uniqueness, but this is minor for a basic folder creation tool.
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 0%, so the description must compensate. It adds meaningful semantics for parentFolderId by explaining omission vs. provision, but name is only represented by the schema's required/minLength constraints and receives no descriptive treatment in the text.
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?
Starts with a specific verb and resource: 'Create a new OmniFocus folder.' It also clarifies the two distinct creation modes (top-level vs. nested), which distinguishes it clearly from sibling tools like edit_folder, delete_folder, and list_folders.
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?
Provides clear guidance on when to omit parentFolderId (top-level) and when to provide it (nesting inside an existing folder). It does not explicitly state exclusions or compare against alternatives, but creation is a distinct operation among the siblings, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and adds significant behavioral detail: 'Only provided fields are changed' reveals partial-update semantics, and the null-clearing and tag-set-replacement rules explain important side effects. It does not mention response format or permission requirements, but for a straightforward edit tool the key mutation behaviors are disclosed.
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?
Three tightly packed sentences with no redundancy. The purpose is front-loaded, and each additional sentence adds a distinct behavioral rule that earns its place.
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?
For a 10-parameter edit tool with no annotations or output schema, the description covers the critical behavioral nuances (partial update, clearing fields, tag replacement) while the schema covers types and enums. It is missing minor context such as what happens to unmentioned fields or whether status can be any value, but the essential information is present.
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?
Although schema coverage is 0%, the description gives meaningful semantics for the non-obvious parameters: null values for deferDate, dueDate, or reviewInterval clear those fields, and tagIds replaces the entire tag set. The remaining parameters (name, note, type, status, flagged) are self-evident and the schema already supplies enums and types.
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 opens with 'Edit an existing project,' a specific verb and resource that exactly identifies the operation. The second sentence clarifies it is a partial update, which distinguishes it from replace-style edits, and the sibling list contains no other tool that edits projects, so there is no ambiguity.
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?
There is no guidance on when to choose edit_project over siblings such as complete_project, drop_project, or move_project. The description only explains parameter-level usage (clearing dates, replacing tags) but not tool-selection criteria, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that partial updates are allowed ('any combination') and that status accepts only active/onHold/dropped, which is useful. It does not disclose error behavior for nonexistent tags, consequences of setting status to 'dropped', or any permissions/side effects, leaving some behavioral gaps.
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?
The description is a single sentence with no filler. It front-loads the core action and resource, then concisely explains the parameters and their constraints. Every clause serves a purpose.
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?
For a three-parameter edit operation with no annotations and no output schema, the description covers the essential invocation details: what the tool does, what input to provide, and the partial-update semantics. It does not describe return values or error conditions, but these are less critical for a simple tag edit tool.
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 description coverage is 0%, so the description must compensate. It does so by clarifying that id refers to an existing tag, name means rename, status has three specific allowed values, and 'any combination' indicates both fields are optional. This adds significant meaning beyond the bare schema types and enums.
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 states a specific verb ('Edit') and resource ('existing OmniFocus tag'), and clearly differentiates from sibling tools like create_tag, delete_tag, and get_tag. It also enumerates the editable fields, making the tool's scope immediately obvious.
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 'Edit an existing OmniFocus tag' implies this tool is for modifying already-created tags rather than creating or deleting them, which provides clear context. However, it does not explicitly name alternatives or state when not to use the tool, so the guidance remains implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It usefully discloses the returned fields and that lookup uses a stable ID, but it does not state error behavior, permissions, or explicitly confirm read-only semantics.
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?
One sentence that front-loads the purpose and follows with a compact, useful list of returned content. No filler or redundancy.
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?
For a simple single-parameter read tool with no output schema, the description adequately enumerates the returned fields. It would be complete at 5 if it noted error or not-found behavior, but that is a minor gap.
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 baseline is 3. The phrase 'stable ID' adds modest meaning beyond the schema's 'id.primaryKey', but there are no complex constraints requiring further explanation.
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?
Clearly specifies a read action ('Get full detail'), the resource ('project'), and the lookup key ('stable ID'). The returned field list distinguishes it from list_projects and other get_* siblings.
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 use case is evident: retrieve full details for a single project by ID. It does not explicitly name alternatives or exclusions, but the context is unambiguous for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It transparently discloses default status behavior, the optional filter, the result cap and default limit, and the exact fields included in each tag. It does not mention ordering or pagination beyond the cap, but for a read-only list tool this is solid coverage.
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?
Three tight sentences with no filler. The first sentence states the purpose, and each subsequent sentence adds one distinct useful fact: default behavior, filtering, and output fields. It is highly scannable and front-loaded.
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?
For a list tool without an output schema, the description is quite complete: it covers defaults, filtering, the limit, and return fields. Minor gaps like ordering and pagination beyond the cap prevent a perfect score, but the essentials are all present.
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 100% and both parameters are already described in the input schema, including defaults and enum values. The description restates the same information without adding new parameter-level semantics, so it does not go beyond the baseline.
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?
States a specific verb ('List') and resource ('tags in OmniFocus'), and the description clearly differentiates from the singular get_tag sibling by emphasizing that all tags are returned by default. The optional status filter and output field list further pin down exactly what the tool does.
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 description gives clear context: by default all tags are returned, and the optional filter restricts results by status. However, it does not explicitly mention when to prefer list_tags over other siblings such as get_tag or list_projects, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does a strong job by noting that complete and dropped tasks are excluded by default, that filter.status can override this, that results are capped at limit, and that returned tasks include dueDate and tagIds. It stops short of describing ordering or pagination, which keeps it from a 5.
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?
The description is compact and front-loaded, with the core action stated first, followed by concise scope guidance and the most important behavioral defaults. Every sentence adds value and there is no redundant or promotional language.
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?
For a list tool with no annotations and no output schema, the description covers the essential scope choices, default filtering, filter fields, limit cap, and a couple of return fields. It is slightly incomplete around ordering and pagination, and it omits the hasDeferDate filter from its summary, though the schema covers that field.
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 the scope requirements, filter fields, and limit default. The description adds some plain-language clarification like 'ISO datetime' and 'array of status strings', but most of this repeats existing schema descriptions. Baseline 3 is appropriate because the schema carries the semantic load.
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 opens with 'List tasks in OmniFocus within a scope', a specific verb+resource statement that clearly identifies the tool's purpose. It further disambiguates from siblings like get_task by framing the operation as a list across project, folder, inbox, or all tasks, making the scope explicit.
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 description gives clear instructions on how to scope the request ('Provide exactly one of: projectId...') and mentions default filtering behavior, but it does not explicitly state when to prefer this tool over alternatives such as get_task or list_projects. Usage is implied rather than stated with any exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the returned fields and the important parentTaskId behavior for top-level tasks vs. subtasks, which goes beyond a simple 'get task' statement. It does not mention error/not-found behavior, but 'Get' clearly signals a read-only operation.
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 dense sentence that front-loads the verb and resource before enumerating returned fields. Every piece of information earns its place, especially given the absence of an output schema.
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 one-parameter getter with no output schema and no annotations, the description is remarkably complete: it names the ID criterion, lists the returned fields, and clarifies the special parentTaskId semantics. An agent has enough context to invoke it correctly.
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?
The schema already covers the only parameter fully with id, type string, minLength, and 'id.primaryKey'. The description adds the modest semantic that the ID is 'stable', but does not need to supply much additional parameter meaning because coverage is 100%.
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 states a specific verb ('Get'), a clear resource ('task'), and a precise selection method ('stable ID'). The detailed field list distinguishes this from list_tasks and from get_project/get_folder/get_tag siblings.
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 description implies that the tool should be used when an agent already has a stable task ID and needs full detail, but it does not explicitly name list_tasks as the alternative for discovering tasks or state when not to use get_task. The usage context is clear, but exclusion guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses the nesting behavior and optionality of parentTagId. However, it does not mention potential failure modes, uniqueness constraints, or whether the created tag is returned, leaving some behavioral ambiguity.
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?
Two sentences with zero filler. The core action is front-loaded, and the parameter guidance is compactly placed second. Every word earns its place.
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?
For a simple create tool with two parameters and no output schema, the description covers the essential operation and the optional nesting behavior. It doesn't describe the return value or error handling, but those are less critical for a basic creation operation.
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 description coverage is 0%, so the description must add meaning beyond the raw schema. It does this well for parentTagId, clearly explaining the effect of omitting versus providing it. The name parameter is self-evident from the tool's purpose, so the description adequately compensates for the schema gap.
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 opens with the specific verb 'Create' and the resource 'a new OmniFocus tag', making the action unmistakable. The second sentence clarifies the two creation modes, which helps distinguish this tool from tag-related siblings like edit_tag or delete_tag.
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 gives clear context for when to use this tool: whenever a new tag needs to be created. It provides explicit instructions for both top-level and nested creation, though it does not name alternative tools or state when not to use them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It thoroughly discloses irreversibility ("THIS ACTION CANNOT BE UNDONE"), recursive destruction ("ENTIRE subtree is destroyed"), the specific contents affected (child folders, projects, tasks), and the required user confirmation. This is exemplary for a destructive operation.
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?
The description is appropriately sized and front-loaded with the core action. Each sentence carries important information: the action, the irreversibility, the full scope of destruction, and the mandatory confirmation step. Minor redundancy exists between "permanently" and "CANNOT BE UNDONE," but it serves as emphasis for a destructive tool.
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 destructive operation with no annotations and no output schema, the description is complete. It covers what will be deleted, the irreversible nature, the cascade scope, and the required pre-call confirmation. There are no significant missing warnings or instructions that an agent would need to invoke this tool correctly.
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% and the single parameter `id` is already documented as "The folder's id.primaryKey." The description adds no extra meaning about the parameter beyond what the schema provides, so the baseline score of 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 description states a specific verb and resource: "Permanently and recursively delete an OmniFocus folder." It clearly distinguishes this from sibling delete tools by naming the exact resource type (folder) and the cascade effect. An agent can tell this apart from delete_project and delete_task without opening schemas.
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 description implies usage by stating that it deletes an OmniFocus folder, but it does not explicitly compare against alternative tools or state when to choose this over delete_project or delete_task. It does provide a strong precondition: "Before calling this tool you MUST ask the user to explicitly confirm." This is a usage condition, but not a full when-to-use vs alternatives explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It explicitly discloses that the action is permanent, cannot be undone, deletes all tasks, and requires explicit user confirmation before calling. This is excellent behavioral disclosure for a destructive tool.
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?
The description is compact and front-loaded, with the core action and scope in the first sentence, followed directly by the necessary warning and confirmation requirement. Every sentence serves a clear purpose.
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?
For a single-parameter destructive delete operation, the description covers the key behavioral details and the required confirmation step. It does not explain the fate of associated folders or tags, but the explicit mention of tasks and the project itself is sufficient for the given complexity.
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?
The input schema already covers the sole parameter 'id' with 100% description coverage ('The project's id.primaryKey'). The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.
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 uses a specific verb and resource: 'Permanently delete a project and ALL its tasks.' It clearly differentiates itself from siblings like complete_project and drop_project by emphasizing permanent deletion and the cascading effect on tasks. The scope is unambiguous.
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 description provides a mandatory precondition: the user must explicitly confirm and be informed that tasks will be deleted. However, it does not explicitly state when to use this tool versus alternatives like drop_project or other project operations, so the usage context is implied rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and meets it: it discloses the default return set, the status filter semantics, the 200-result cap, and the exact returned fields including the full-path separator (▸). This goes well beyond what the input schema alone conveys.
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?
Four tight sentences with no filler: purpose first, then default behavior, filter option, then output shape. Every sentence earns its place, and the most decision-relevant facts (default scope, status values) are front-loaded ahead of the return-field detail.
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?
The definition is complete enough for practical use: parameters are fully documented in the schema, and the description compensates for the absent output schema by enumerating returned fields (id, name, full path, parentId, status). Minor omissions — result ordering and behavior beyond the cap — keep it from a perfect score.
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% — both limit and filter already have thorough schema descriptions including defaults and the exclusiveMinimum constraint. The tool description restates the default (200) and the status enum values rather than adding new parameter meaning, so it stays at the baseline 3.
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 opens with a specific verb and resource ('List folders in OmniFocus') and immediately clarifies scope by stating the default return set (all active and dropped folders). This clearly distinguishes it from siblings like get_folder (single retrieval) and list_projects/list_tasks/list_tags (different resources).
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 description explains default vs. filtered behavior well enough for an agent to decide whether to pass a status filter, but it never states when to prefer this over siblings such as get_folder or list_projects. Usage context is implied through the resource name and default-behavior detail, with no explicit exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the null-to-top-level behavior and the not-found error condition, which adds useful context. However, it does not mention permissions, reversibility, side effects on existing folder membership, or whether moving to the same folder is a no-op.
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?
Three focused sentences with no filler. The main action is front-loaded, and each sentence adds necessary detail: destination semantics, null handling, and error behavior.
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?
For a simple two-parameter mutation with no output schema, the description covers the core operation, destination semantics, and error condition. It could mention the return value or whether the move is immediate, but these are minor gaps given the tool's simplicity.
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 description coverage is 0%, so the description must compensate. It adds key meaning: folderId accepts a string to target a folder or null to target the top level, and mentions a not-found error for invalid IDs. The id parameter is only implicitly identified as the project ID, but 'Move a project' plus the parameter name makes that reasonably clear.
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?
Clearly states the action ('Move'), the resource ('a project'), and the target ('a different folder or to the top level'). This unambiguously distinguishes it from sibling move_task and from create/edit/delete project tools.
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?
Describes exactly what the tool is for and how to express the two possible destinations (folder vs top level). It does not explicitly name alternatives like move_task for tasks, but the context is clear enough that an agent can infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden, and it does so well. It discloses the critical behavior of returning all matches rather than silently selecting one, and instructs the caller to disambiguate with the path field before continuing. It does not cover edge cases like zero matches or response format, but the disclosed behavior is the most important aspect for safe use.
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?
Three concise sentences, each earning its place: the first states the core function, the second states a critical non-obvious behavior, and the third gives actionable disambiguation guidance. The most important information is front-loaded, with no filler or repetition of schema details.
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?
For a lookup tool with three params and no output schema, the description covers the essential operational guidance: what it returns, that it returns multiple matches, and how to handle disambiguation. It could be more complete by describing the no-match case or the exact response shape, but given the tool's simplicity and the 100% schema coverage, the description is sufficiently complete for correct selection and invocation.
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 all three parameters and the enum values. The description adds some context by mentioning the 'path' field in results, but it does not meaningfully elaborate on the semantics of the 'scope' parameter beyond what the schema already states. Baseline 3 is appropriate.
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 states a specific verb ('resolve') and resource ('entity name') with a clear outcome: stable ID(s). It further distinguishes itself from the sibling CRUD tools by emphasizing it returns ALL matches and never silently picks one, making its role as a lookup/disambiguation tool unmistakable.
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 clearly implies when to use this tool: when you have an entity name and need its stable ID, especially before a write operation. It also gives explicit guidance on what to do when multiple candidates are returned. It does not explicitly state when not to use it or name alternatives like get_task/get_project, but the instruction to disambiguate before writes provides solid practical context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It explicitly conveys a read-only operation via 'Get' and discloses the returned fields, which is the main behavioral context for a simple getter. It does not mention error behavior or auth, but nothing suggests hidden side effects.
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?
The description is a compact two-sentence definition with no redundant fluff. The action and resource appear first, followed by the return payload, making it easy to scan and understand quickly.
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?
This is a simple one-parameter tool with no output schema. The description sufficiently defines the lookup key and enumerates the returned fields, giving an agent everything needed to invoke and interpret the result correctly.
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 for the single parameter is 100%, so the baseline is 3. The description adds the 'stable ID' nuance, reinforcing that the ID should not change, but it does not explain how to obtain the ID or anything beyond the schema. It meets but does not raise the baseline.
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 the verb 'Get', the resource 'tag', and the retrieval key 'stable ID'. It also specifies what 'full detail' includes (path, parentId, status, child tag IDs), making it distinguishable from list_tags and other sibling tag tools.
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 phrase 'by its stable ID' and 'full detail' clearly indicate when to use this tool: when a specific tag ID is known and complete detail is needed. It does not explicitly name alternatives or exclusions, but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and includes important behavioral details: the resulting top-level/subtask state and the not-found error when any ID does not exist. It could disclose more about side effects on existing subtasks or permissions, but the core behavior and failure mode are transparent.
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?
Two sentences deliver purpose, the two modes, the exclusivity rule, and the error behavior with no filler. The key action and the exactly-one constraint are front-loaded.
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?
For a three-parameter mutation tool with no annotations and no output schema, the description covers purpose, parameter semantics, the required constraint, and error behavior. It does not describe return values or potential side effects on subtasks, but these are minor given the tool's simplicity.
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 description coverage is 0%, so the description must compensate. It explains the meaning of projectId and parentTaskId and the exclusivity constraint, which the raw schema does not convey. The id parameter is implied by 'Move a task' and is marked required in 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 names the exact verb ('Move'), the resource ('a task'), and the two modes: moving to a different project as a top-level task or making it a subtask. It is clearly distinguishable from the sibling move_project because it targets tasks, not projects.
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 explicitly states when to use projectId versus parentTaskId and the 'Exactly one' exclusivity rule. It does not name alternative sibling tools or excluded scenarios, but the usage context is sufficiently clear for an agent to select this tool over move_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description fully carries the burden of behavioral disclosure. It explicitly states irreversibility, cascading deletion of child tags, automatic removal from tasks/projects, and the mandatory user-confirmation requirement. This is comprehensive disclosure for a destructive mutation tool.
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?
Three sentences, each earning its place: the destructive action, the consequences, and the mandatory confirmation step. The most important warning is front-loaded, and there is no redundant or vague filler.
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 single-parameter destructive tool with no output schema and no annotations, the description covers everything an agent needs to invoke it correctly: scope, irreversibility, cascade behavior, side effects, and the required user confirmation. No critical operational detail is missing.
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?
The schema already documents the single id parameter with 100% coverage, so the baseline is 3. The description does not add extra semantic detail about the id beyond the schema, but no compensation is needed given full schema coverage.
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 states a specific verb ('delete'), a specific resource ('OmniFocus tag'), and a critical qualifier ('permanently'), which clearly distinguishes it from editing, creating, or non-destructive tag operations. It is immediately obvious that this tool removes a tag and is not a soft-delete or update operation.
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 gives clear context about when to use this tool: when permanently deleting a tag, and it mandates that the user must explicitly confirm before invoking it. It does not explicitly contrast with alternatives like edit_tag, but the destructive nature and confirmation requirement effectively guide an agent's decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that deletion is permanent ('THIS ACTION CANNOT BE UNDONE'), cascades to subtasks ('all its subtasks'), and requires user confirmation. These are the critical behavioral traits an agent must know before invoking a destructive tool.
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?
The description is two sentences with no fluff. It front-loads the primary action and unique consequence, then follows with the mandatory confirmation requirement. The all-caps warning earns its place and effectively draws attention to irreversibility.
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 one-parameter delete tool with no output schema and no annotations, this description covers all necessary context: what is deleted, the irreversible nature, and the required pre-step. The agent has everything needed to call the tool correctly and safely.
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?
The input schema fully documents the single id parameter with 'The task's id.primaryKey' at 100% coverage, so the baseline is 3. The description adds no additional meaning about the parameter beyond what the schema already provides, though it is consistent with the overall purpose.
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 the action: 'Permanently delete a task and all its subtasks.' This provides a specific verb (delete), resource (task), and unique scope (subtasks), distinguishing it from sibling tools like complete_task and drop_task by emphasizing permanent deletion. The irreversible nature is immediately communicated.
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 provides an explicit precondition: 'Before calling this tool you MUST ask the user to explicitly confirm...' This tells the agent exactly when the tool is appropriate to call. However, it does not name alternatives such as drop_task or complete_task, so the 'when not to use' dimension is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does disclose the operation type ('Get'), the input mechanism (stable ID), and the returned fields (path, parentId, status, child folder IDs, immediate project IDs). It does not cover error cases or auth, but for a simple read tool this is adequate.
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?
The description is a single, front-loaded sentence that names the action, the target, and the expected return values with no filler. Every word contributes to operational understanding.
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 one-parameter get-by-ID tool with no output schema, specifying the returned fields makes the call predictable. The sibling context provides enough distinction, and no required usage details are missing.
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%, and the schema already documents 'id' as the folder's id.primaryKey. The description adds the meaningful qualifier 'stable ID,' which tells the agent that this identifier is persistent and reusable across calls, going slightly 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 states a specific verb ('Get'), a resource ('folder'), and the lookup key ('stable ID'), and it enumerates the returned data. This clearly distinguishes it from list_folders and get_project even without seeing those schemas.
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 makes clear that this is the tool for retrieving detail for a single folder by ID, which implies when to use it over list_folders. It does not explicitly name alternatives or exclusions, but the context is unambiguous for a get-by-id operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the default exclusion of done and dropped projects, how to override it, the cap imposed by limit, and the exact fields returned on each project. It could add ordering or pagination details, but the disclosed behavior is substantive and clear.
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?
The description is three sentences with no filler. It front-loads the core action, then covers default behavior, filter semantics, and returned fields. Every sentence contributes necessary information.
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?
Since there is no output schema, the description properly explains returned project fields. It also covers defaults, filters, and limits, which is sufficient for a list operation with only two optional parameters. The agent can select and invoke the tool without missing critical information.
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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that filter.status overrides the default exclusion, folderId restricts to that folder's subtree, and results are capped at limit. This gives the agent practical understanding of how the parameters interact.
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 opens with a specific verb and resource: 'List projects in OmniFocus.' It clearly differentiates itself from sibling tools like get_project, list_tasks, and list_folders by naming the project resource and describing default filtering behavior. The purpose is unambiguous.
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 gives clear usage context: call this to list projects, optionally restricted by status, folderId, or flagged, and override the default done/dropped exclusion via filter.status. It does not explicitly name alternative tools for single-project retrieval or other resource listings, but the context is clear enough for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility, and it excels: it discloses partial update behavior, tag set replacement, the use of clear flags for dates, null for estimatedMinutes, and repetition rule set/clear semantics. This goes well beyond what the schema names alone would convey. No contradictory or missing critical behavioral traits for an edit operation.
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?
Every sentence adds necessary operational detail: main purpose, partial update rule, tag replacement, date clearing, estimatedMinutes null, repetition set/clear. No filler, appropriately front-loaded. The length is justified by the complexity of the edit semantics.
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?
For a 14-parameter mutation tool with no annotations and no output schema, the description covers the non-obvious behaviors comprehensively. It omits some context like whether the task ID must exist, error behavior, or return value, but these are secondary to correct invocation. The nested repetitionRule object is explained sufficiently for an agent to construct valid calls.
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 description coverage is only 29%, so the description must add meaning. It explains the nuanced behavior of tagIds (replaces full set), clearDueDate/clearDeferDate/clearPlannedDate, null for estimatedMinutes, and repetitionRule structure. However, it does not explicitly mention name, note, dueDate, flagged, deferDate, or plannedDate behavior, though those are fairly self-explanatory. Overall it compensates well for the low schema coverage.
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?
States the specific action 'Edit an existing task by its stable ID', clearly identifying the resource (task) and operation (edit). This distinguishes it from siblings like create_task, delete_task, complete_task, and get_task. The inclusion of 'stable ID' adds precision about how the task is identified.
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?
Clearly implies use when modifying fields of an existing task, and the partial-update semantics tell the agent what to expect. It does not explicitly name alternatives or state when not to use this tool, but the sibling list and opening phrase make the intended context clear. A minor gap is the absence of an explicit 'use create_task for new tasks' style exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![omnifocus-mcp MCP server](https://glama.ai/mcp/servers/steveardis/omnifocus-mcp/badges/card.svg)](https://glama.ai/mcp/servers/steveardis/omnifocus-mcp)

Score Badge

Copy to your README.md:

[![omnifocus-mcp MCP server](https://glama.ai/mcp/servers/steveardis/omnifocus-mcp/badges/score.svg)](https://glama.ai/mcp/servers/steveardis/omnifocus-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/steveardis/omnifocus-mcp'

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