omniplan-mcp

by johntrandall

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.4.5
Disambiguation5/5
Each tool targets a distinct operation on tasks, resources, assignments, dependencies, project info, or documents. No two tools have overlapping purposes; e.g., create_task and create_tasks differ in batch vs. single, and query_tasks vs. find_task serve different query patterns.
Naming Consistency5/5
All 22 tools follow a consistent verb_noun snake_case pattern (e.g., add_dependency, assign_resource, create_task). There are no deviations or mixed conventions, making the naming predictable and intuitive.
Tool Count4/5
With 22 tools, the server is slightly above the typical well-scoped range (3-15) but still reasonable for a project management domain. The count is justified by the need to cover tasks, resources, assignments, dependencies, project settings, and document operations.
Completeness5/5
The tool surface covers full CRUD for tasks and resources, plus assignments, dependencies, project info, and document management. Batched creation and query/find variants are included. There are no obvious gaps for core project scheduling workflows.
Average 4.3/5 across 22 of 22 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 7, 2026
- 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 full burden. It only states 'delete,' implying destruction but lacks details on irreversibility, cascade effects, permissions, or error handling.
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?
Short and front-loaded with purpose. The docstring format is efficient, though slightly verbose for a single parameter.
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 deletion tool, the description is incomplete. It lacks behavioral context (irreversibility, effects on dependencies) and error conditions, despite an output schema existing.
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 coverage is 0%, so description must compensate. It mentions task_id and its purpose but adds no format, source, or validation beyond what the schema provides.
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 'Delete a task by its unique ID,' specifying the verb (delete), resource (task), and parameter (unique ID). It distinguishes from sibling tools like create_task and update_task.
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 on when to use this tool versus alternatives (e.g., move_task, update_task). No prerequisites, conditions, or restrictions are mentioned.
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 provided, so the description bears full burden. It only says 'Create a new task' without disclosing behavioral traits such as idempotency, permissions, side effects, or constraints on document state. The description lacks transparency beyond the basic action.
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 uses a clear docstring format with an introductory line and an Args section. It is well-structured and readable, though the parameter list repeats information present in the schema, making it slightly longer than necessary. However, it remains concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, 1 required, and an output schema presumably documenting return values, the description covers all input semantics thoroughly. It does not explain return values, which is acceptable given the output schema. Some behavioral context is missing, but overall it is sufficiently complete for parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), but the description provides detailed explanations for all 10 parameters, including examples like 'effort_seconds: Total effort in person-seconds (e.g. 14400 for 4h)'. This adds significant meaning beyond the schema's type information.
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 'Create a new task' and the resource 'OmniPlan document', with specific verb and resource. It distinguishes from sibling tools like 'update_task' and 'delete_task', and the singular 'task' differentiates from batch 'create_tasks'.
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 explicit guidance on when to use this tool vs alternatives. Since there is a sibling 'create_tasks' for batch creation, the description should mention when to use the singular version. The description omits any usage context or when-not-to-use.
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 full burden. It discloses that the tool returns a boolean indicating success, and notes behavior when no matching assignment is found (returns false). However, it does not mention potential side effects, permissions needed, or error conditions (e.g., invalid task_id).
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 extremely concise: one introductory sentence, then a clear Args list and Returns statement. Every sentence adds value, and the action is front-loaded. No wasted words.
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?
Given the simplicity of the operation (two string parameters, a boolean return) and the existence of an output schema (implied by the return description), the description is sufficiently complete. It covers the core function, parameters, and return format. Minor missing details (e.g., error handling) are not critical for a straightforward 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 explains that task_id is the 'uniqueID of the task' and resource_id is the 'uniqueID of the resource', adding clear semantics beyond the schema's type and title. This is adequate for clarity.
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: 'Remove a resource assignment from a task.' It uses a specific verb (remove) and resource (assignment from task), and distinguishes from siblings like assign_resource (which adds) and list_assignments (which lists).
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 usage guidelines are provided. The description does not indicate when to use this tool instead of alternatives, such as when an assignment exists versus when it doesn't, or prerequisites like the task and resource must exist.
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 burden. It indicates a read operation ('get'), which is inherently non-destructive, but does not mention permissions, error handling (e.g., if task not found), or any side effects. Adequate for a simple retrieval but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences with a clear 'Args' section. No fluff or redundancy. Front-loaded with purpose. Efficient and well-structured.
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?
Given the tool has an output schema (not shown), explanation of return values is unnecessary. The description covers the single required parameter and the action. It could mention that the response contains full details, but it's already implied. Lacks nothing critical for a simple getter.
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?
The schema has 1 parameter (task_id) with 0% description coverage. The tool description adds 'The uniqueID of the task,' which essentially repeats the schema field title and type without additional detail (e.g., format, examples, constraints). This adds minimal value 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?
Description clearly states 'Get full details of a single task by its unique ID.' This uses a specific verb (get) and resource (task), and the phrase 'by its unique ID' distinguishes it from sibling tools like query_tasks or find_task which may use filters.
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?
Description implies usage for retrieving details of a single task. However, it does not provide explicit guidance on when to use this over alternatives like query_tasks or when not to use it (e.g., for batch retrieval). Still, the purpose is clear and appropriate.
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?
Despite no annotations, the description discloses that deleting a resource assigned to tasks succeeds and strips assignments. It also details the return value format. This adds important behavioral context beyond a simple 'delete'.
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 concise, front-loaded with the purpose, and uses clear structure (Args, Returns, additional note). Every sentence adds value.
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 description covers purpose, parameter meaning, return value, and a notable side effect. However, it lacks usage guidelines and does not mention error cases beyond the return value. Still fairly complete for a simple delete 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?
The schema has 0% description coverage, but the description explains 'resource_id: uniqueID of the resource to delete,' providing essential meaning that the schema alone does not.
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 'Delete a resource by uniqueID,' specifying the action, resource, and identifier. It distinguishes from siblings like create_resource or list_resources.
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 is provided on when to use this tool versus alternatives, nor any prerequisites or conditions for use. This is a notable gap.
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 full burden. It discloses that uniqueID is preserved, describes the underlying omniJS method, explains automatic index filling, and specifies the return format. However, it omits error conditions or permission requirements, which would improve transparency.
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 well-structured with clear sections (purpose, method details, args, returns). It is front-loaded with the main action. However, the omniJS version and build details add unnecessary length for an AI agent; trimming would improve conciseness.
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?
Given the tool complexity (3 parameters, output schema), the description covers core behaviors: reparenting without ID change, default index behavior, and return format. It is sufficient for typical usage but lacks details on error handling or constraints (e.g., cycles).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It provides detailed semantics for each: resource_id (required), new_parent_id (defaults to root), and index (defaults to append). Adds context beyond schema, such as automatic index handling, which is critical for correct usage.
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 tool's purpose: 'Reparent a resource without changing its uniqueID.' It uses a specific verb (move) and resource (resource), and distinguishes itself from siblings like 'move_task' and 'create_resource' by focusing on moving within the hierarchy.
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 behavior (preserves uniqueID, fills index if omitted) but lacks explicit guidance on when to use this tool over alternatives like delete-and-recreate. It implies usage for re-parenting but does not state exclusions or contexts where other tools would be more appropriate.
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 burden. It discloses that the tool returns a JSON indicating success or failure, but it does not mention idempotency, permissions, or side effects. Adequate but not comprehensive.
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 concise and well-structured, with a clear one-line purpose followed by bullet-pointed arguments and return value. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 parameters, clear return type), the description fully explains inputs and outputs. The output schema is described in the return section, making the description complete for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear, human-readable explanations for both parameters (predecessor_id and successor_id) beyond the schema's type-only information.
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 'Remove the dependency between two tasks,' using a specific verb and resource. It distinguishes from siblings like add_dependency and list_dependencies by focusing on 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 description does not explicitly state when to use this tool vs alternatives, but the sibling list provides implicit context. No when-not-to-use or precondition information is provided.
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?
Despite no annotations, the description discloses key behavioral traits: it confirms mutation ('Update'), explains partial update semantics ('Only provided fields are changed'), and details parameter-specific behaviors like clearing dates with empty strings and leaving fields unchanged with null omission. However, it does not mention error handling or idempotency.
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 efficiently front-loaded with the core purpose, then lists parameters in a clear, readable format. While it is lengthy due to 14 parameters, every line adds value without redundancy. A slightly more structured list format could improve scannability.
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?
Given the tool's complexity (14 parameters), the description covers all input semantics thoroughly. The presence of an output schema absolves the need to describe return values. The description could be improved by mentioning behavior for non-existent task_id or other error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by detailing each parameter's purpose, format (ISO dates), units (person-seconds), and special values (0 to set, None to omit). It also clarifies internal field mappings for date constraints. This goes well beyond the schema's minimal type info.
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?
Description clearly states 'Update an existing task' with a specific verb and resource, and adds the important qualifier 'Only provided fields are changed' to distinguish from full replacement. This is distinct from sibling tools like create_task and delete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use for updating existing tasks but provides no explicit guidance on when to use this tool vs alternatives (e.g., move_task, assign_resource). No preconditions or when-not-to-use advice is given.
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 fully discloses the round-trip behavior for units, the default value when omitted (1.0), and that mapping is to an internal accessor. This exceeds minimal expectations.
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 well-structured with 'Args' and 'Returns' sections, front-loaded with the purpose. Every sentence adds unique value, and the length is appropriate for the tool's complexity.
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 description covers parameters, return format, and side effects (round-trip, defaults). It lacks error handling or prerequisite info, but the presence of an output schema reduces the burden. Nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds detailed semantics for all three parameters: task_id and resource_id are explained as 'uniqueID', and units gets a full explanation including type, default, round-trip behavior, and boundary handling.
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 'Assign a resource to a task' which is a specific verb+resource pairing. It clearly distinguishes from siblings like 'unassign_resource' (reverse operation) and 'list_assignments' (read-only).
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 explicit guidance on when to use this tool versus alternatives (e.g., when to assign vs. unassign, or prerequisites like existing resource/task). The description focuses on mechanics, not usage 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 explains key behaviors: writes go through Decimal.fromString (avoiding float precision issues), returns a JSON with id, name, type, email, cost_per_use. It does not mention auth requirements or prerequisites like an existing document, but covers the most important behavioral 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?
The description is concise and well-structured with Args and Returns sections. Every sentence provides value; no redundancy. It is appropriately sized for the tool's complexity.
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 description covers creation, parameters, and return. Missing high-level context such as the need for an existing document or error states, but given the output schema exists and parameters are well-documented, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates: name is described as 'Resource name', type lists all possible values and default, email clarifies relevance for staff, cost_per_use explains Decimal storage. This adds crucial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new resource at the document's resource root.' It specifies the verb (create) and resource (resource), and distinguishes from sibling tools like create_task by focusing on resources. 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a new resource is needed, but does not explicitly state when to use this tool versus alternatives (e.g., create_task) or when not to use it. No exclusion criteria or context for choosing this over other creation tools.
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 fully bears the burden of transparency. It details the return format, data sources (JXA SDEF surface vs omniJS), and known implementation quirks like date and currency persistence issues, offering deep behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose but includes extensive implementation details and surface gap notes. While each sentence adds value, the length could be reduced for quick consumption.
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?
Despite no output schema provided in the input, the description fully specifies the return shape (JSON fields and their meanings) including edge cases and known bugs, making the tool's behavior completely understandable.
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?
No parameters exist, and schema coverage is 100%. Baseline for zero-parameter tools is 4; the description adds no redundant parameter info, which 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 clearly states 'Return project-level info for the front document,' specifying the verb (return), resource (project-level info), and scope (front document). This distinguishes it from siblings like get_task or list_documents.
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 for obtaining project-level details but does not explicitly contrast with alternatives or advise when not to use it. No exclusions or sibling references are provided.
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. It discloses depth-first traversal and flattening of group resources, which adds behavioral context beyond the simple listing. It also specifies the return format.
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 concise with two clear paragraphs. The first sentence states the purpose, and the second explains the return format and behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema externally, the description provides the return format and traversal behavior. It is complete for a simple list tool with no parameters, covering purpose, behavior, and output.
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?
The tool has zero parameters, and schema coverage is 100% (no params). According to the rubric, baseline is 4. The description adds no parameter info, which is unnecessary.
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 'List all resources in the document' with a specific verb and resource. It distinguishes from sibling tools like create_resource, delete_resource, etc., by focusing on listing.
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 for listing resources but provides no explicit guidance on when to use this tool over alternatives like list_assignments or list_dependencies. No when-not or context cues.
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?
The description details filter behavior (case-insensitive keyword, date filtering, detail levels) but does not explicitly state read-only nature or potential performance implications.
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 concise and well-structured, with a summary line followed by a clear list of parameters, each earning 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?
Given the output schema exists, the description covers input parameters thoroughly. It lacks mention of error handling or edge cases, but is otherwise complete for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description provides complete explanations for all 7 parameters, including types, defaults, and behavior, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries tasks with optional filters, distinguishing it from sibling tools like create_task or get_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains each filter but does not provide explicit guidance on when to use this tool versus alternatives like get_task or list_assignments.
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 fully discloses behavior: it adds a dependency, returns JSON with round-trip values, explains the `lead_time_seconds` read-back via `dep.leadTimeDuration.workSeconds`, and notes edge case when `lead_time_seconds=0`. No contradictions.
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?
Well-structured with clear 'Args' and 'Returns' sections. The first sentence is concise. Slightly lengthy due to detailed parameter descriptions, but justified given the schema lacks descriptions. No superfluous content.
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?
Covers parameters, return format, and important nuances like round-trip and default behavior. Lacks discussion of error conditions (e.g., duplicate dependencies), but overall complete for typical usage. Output schema exists but description adds useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds full meaning. It explains each parameter's role, default values, allowed enum values for 'kind', and constraints on 'lead_time_seconds'. Substantially adds value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Add a dependency from predecessor to successor.' It uses specific verb+resource and distinguishes from sibling 'remove_dependency'.
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?
No explicit guidance on when to use this tool versus alternatives like 'remove_dependency' or 'list_dependencies'. Usage is implied by the tool name but not elaborated.
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. It discloses that the tool reads `assignment.unitsAssigned` directly, returns an empty array for no assignments, and is clearly a read-only operation. It could mention if there are any prerequisites, but overall it is 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?
The description is succinct, using a clear structure with Args and Returns sections. Every sentence adds value, and there is no unnecessary 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?
For a simple listing tool with one parameter and a documented return format, the description is complete. It explains the output structure, empty array behavior, and even mentions the internal field read. The output schema exists to provide further details, but the description suffices on its own.
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?
The input schema has 0% description coverage, so the description must add meaning. It describes the task_id parameter as 'uniqueID of the task', which provides clarity beyond the schema that only defines it as a string. This compensates well 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 explicitly states it lists resource assignments on a task, using a specific verb and resource. It clearly distinguishes from sibling tools like assign_resource and unassign_resource by focusing on read-only listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is for viewing assignments on a given task. Although it does not explicitly mention when not to use it, the context from sibling tools and the task_id parameter make the usage clear.
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 must convey behavioral traits. It indicates the tool lists 'currently open' documents, implying a read-only operation with no destructive side effects. However, it does not explicitly state that it is non-modifying, but the verb 'list' and the context of OmniPlan suggest safety.
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 extremely concise: two sentences with no wasted words. The core purpose is front-loaded, and the note provides additional context without redundancy.
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 simple no-parameter list tool, the description covers the essential behavior (listing open documents) and the note about task tools adds valuable context. The existence of an output schema handles return values, so no further details are needed.
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?
The tool has no parameters, so the input schema fully covers them. The description adds no parameter information because none is needed, meeting the baseline for zero parameters.
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 'List all currently open OmniPlan documents,' which is a specific verb ('list') and resource ('documents'), and distinguishes this tool from sibling tools like list_assignments or list_resources by focusing on documents.
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 context that listing documents is about open documents, and the note about task tools operating on the current front document hints at when this tool might be used (e.g., to check which document is active), but it does not explicitly state when to use this versus other list tools.
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 bears full responsibility for behavioral disclosure. It thoroughly explains the return format, including fields and the special handling of lead_time_seconds when null.
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 concise and well-structured: a brief intro line followed by Args and Returns sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter and the presence of an output schema, the description fully covers behavior and return details, making it complete for a simple list 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?
With 0% schema coverage, the description compensates by explaining the task_id parameter's effect: optional, filters when provided, otherwise returns all. It adds meaning beyond the schema's type definition.
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 'List dependencies in the document,' specifying the verb (list) and resource (dependencies). This distinguishes it from siblings like add_dependency and remove_dependency.
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 explains the optional filtering by task_id and the default behavior of listing all dependencies. It provides clear context but does not explicitly state when not to use it or list alternatives.
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 fully discloses behavioral traits: preserves uniqueID, maintains dependencies/resource assignments, fills in index when omitted, and specifies the underlying omniJS method and version. No contradictions.
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 well-structured with clear sections (main purpose, context, Args, Returns). While slightly lengthy, every sentence serves a purpose. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of reparenting and the existence of sibling tools like move_resource, the description covers inputs, behavior, output format, edge cases (omitted params), and version requirements. It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section explains all three parameters: task_id (required), new_parent_id (defaults to root), index (defaults to append at end). This adds complete meaning beyond the schema's type and required fields.
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 'Reparent a task without changing its uniqueID.' It uses specific verbs ('reparent') and distinguishes from alternative approaches (clone-and-rebuild) by emphasizing preservation of uniqueID, dependencies, and assignments.
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 implicitly guides usage by highlighting when to use (to preserve uniqueID and dependencies) but does not explicitly mention when not to use or enumerate alternatives like delete_task+create_task. The context is clear but lacks explicit exclusions.
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 present, so the description carries full burden. It discloses performance characteristics (1-3s per round-trip), atomic validation (raises ValueError before any creation), and batching behavior. However, it does not explicitly state whether the operation is fully transactional or mention required permissions.
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 well-structured with clear sections (Performance, Args, Returns, Raises). Every sentence adds value—no fluff. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still adds useful return details. It covers error handling, parameter constraints, and performance context. All relevant aspects are addressed for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides exhaustive semantics for the `tasks` parameter: lists accepted fields (title, parent_id, etc.), explains the extra `parent_index` field, and clarifies constraints (at most one of parent_id/parent_index). This fully compensates for the schema's lack of detail.
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 multiple tasks in a single JXA call.' It clearly distinguishes from the sibling `create_task` by highlighting the batch nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool over `create_task` by quantifying the performance cost of multiple individual calls (50-150s) versus one batch call.
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 fully discloses behavior: it is a read operation, returns lightweight identifiers, default case-insensitive substring matching, exact option, empty array on no match, and depth-first order. This covers all essential behavioral aspects.
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 well-structured with a clear one-sentence purpose, a context paragraph, and formatted Args/Returns sections. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no annotations, an output schema mentioned), the description provides complete information: what it does, when to use, parameter semantics, return format, and ordering. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so effectively by explaining that 'name' is matched case-insensitively by default, and 'exact' changes to exact case-sensitive match. It also describes the return format, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'look up' and the resource 'tasks by title', with a specific goal: returning lightweight identifiers. It explicitly contrasts with the 'list everything → grep → use ID' pattern, distinguishing it from more extensive listing tools like query_tasks.
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 tells when to use this tool: 'when an agent knows the title but not the uniqueID.' It also explains the two matching modes (default case-insensitive substring, exact case-sensitive). However, it does not explicitly mention alternatives like get_task for when the ID is known, leaving a minor gap.
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 fully carries the behavioral transparency burden. It discloses persistence across calls, rejection of empty string for start_date, and explicitly warns that currency and working_hours writes are non-persistent, providing live probing 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?
The description is well-structured with Args, Returns, and Note sections, each sentence adding value. It is front-loaded with the main action and contains no fluff, making it concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and existence of an output schema (returning get_project_info shape), the description covers all necessary aspects: parameter mapping, constraints, unsupported fields, and return shape. It is fully sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining start_date as an ISO date mapping to document.project.actual.startDate, and notes that empty string is rejected, adding significant meaning beyond the schema's type and default.
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 'Update project-level fields on the front document,' with a specific verb and resource. It further elaborates on the start_date parameter, distinguishing it from sibling tools like update_task by focusing on project-level updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating start_date and provides a note that currency and working_hours are not supported, offering negative guidance. However, it lacks explicit instructions on when to use this tool versus alternatives like add_dependency or get_project_info.
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 fully discloses behavior: saves to disk, verifies dirty flag after save, and provides empirical evidence about lack of autosave. Return format is detailed.
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?
Reasonably concise, front-loaded with purpose and context, though the empirical verification section is slightly verbose. Still well-structured and every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with no parameters, the description covers purpose, necessity, and return format completely. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is trivially 100%. The description adds rich meaning about what the tool does and its return value, far beyond the empty 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?
Clearly states 'Save the front OmniPlan document to disk', a specific verb and resource. No sibling tool performs save, so it is well distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes that OmniPlan does not autosave and that explicit save is the only way to persist changes, providing clear when-to-use guidance and context for necessity.
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:

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

Score Badge

Copy to your README.md:

[![omniplan-mcp MCP server](https://glama.ai/mcp/servers/johntrandall/omniplan-mcp/badges/score.svg)](https://glama.ai/mcp/servers/johntrandall/omniplan-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/johntrandall/omniplan-mcp'

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