Motion MCP Server

Server Quality Checklist

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

Latest release: v2.8.0
Disambiguation5/5
Each tool targets a distinct resource: tasks, schedules, projects, workspaces, users, search, comments, custom fields, recurring tasks, and statuses. There is no overlap in purpose, and even tasks vs recurring tasks are clearly differentiated by their descriptions.
Naming Consistency5/5
All tool names follow a consistent motion_<resource> pattern using plural nouns. This uniform convention makes the tool set predictable and easy to navigate.
Tool Count5/5
With 10 tools, the server is well-scoped for the Motion API domain. Each tool covers a core entity or operation without unnecessary redundancy or bloat.
Completeness4/5
Tasks have full lifecycle coverage, and most entities have list/create/delete/update as appropriate. However, projects lack update/delete operations and recurring tasks lack update, leaving minor gaps that agents can work around.
Average 3.2/5 across 10 of 10 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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. It only says 'Manage comments' which implies both read and write, but does not disclose pagination, return format, side effects, or prerequisites. The schema enum partially reveals operations, but the description offers no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasteful words, but it is under-specified for a tool with 4 parameters and 2 operations. It is not a tautology but lacks essential detail, making it too thin for its complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, 2 operations, no output schema, and no annotations, yet the description provides almost no contextual information. It fails to explain list/create behavior, return values, pagination, or operational prerequisites, making it inadequate for reliable tool selection.
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%, with all four parameters described in the input schema. The description itself adds no parameter detail beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manage comments on tasks' identifies the resource (comments on tasks) but the verb 'manage' is vague and covers list/create without specifying either. It does not distinguish this tool from siblings like motion_tasks or motion_projects, since 'manage' is generic.
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 given on when to use this tool versus alternatives, or when to use 'list' versus 'create' operations. The description provides no context about use cases or exclusions.
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 provided, the description carries the full burden of disclosing behavioral traits. 'Manage' implies possible mutation, while 'get current user information' suggests a read operation, but the description does not clarify whether operations are read-only or have side effects. It also omits details about authentication requirements, rate limits, or any potential impact on data.
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 a single concise sentence with no wasted words. It front-loads the purpose ('Manage users') and adds a specific sub-purpose ('get current user information'). While it is brief, it is not overly verbose and is easy to parse.
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?
Given the tool has 4 parameters, a required operation enum, and no output schema, the description is insufficient. It does not mention that 'operation' is required, what the two enum values do, or which parameters apply to each operation. An agent relying on this description would lack critical information to invoke the 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%, so each parameter has a description in the schema. The tool description does not add additional meaning beyond the schema, but the baseline for high coverage is 3. The description vaguely maps 'manage users' to the parameters but does not explain how teamId, workspaceId, or workspaceName are used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'users' as the resource and includes 'get current user information', which implies a specific action. However, the verb 'manage' is vague and could suggest CRUD operations, not clearly distinguishing this tool from sibling tools like motion_workspaces or motion_projects. The description does not explicitly state the operations 'list' and 'current' that the schema defines, making it less specific than ideal.
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 use this tool versus alternatives such as motion_workspaces or motion_projects. The description does not mention any exclusions, prerequisites, or context that would help an agent decide between tools. It merely states a broad purpose without actionable usage direction.
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 of behavioral disclosure, but it only lists operation names without any caveats, side effects, permissions, or reversibility. The inclusion of 'delete' hints at destructiveness, but no additional context is provided, matching the level of the 'update_drive' example that scored 2.
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?
At one sentence, the description is concise and front-loaded with the tool's subject ('Manage Motion tasks'). However, it is arguably too sparse, sacrificing substance for brevity, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 19 parameters and 8 operations, the one-line description is far too minimal to provide a complete understanding. It omits return values, parameter-operation mapping, and behavioral nuances, and there is no output schema to fill the gap. This is a complex tool with a wholly inadequate description.
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 detailed parameter descriptions, so the tool description's lack of parameter info is acceptable. The baseline is 3 because the schema does the heavy lifting, and the description adds no additional parameter semantics.
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 explicitly enumerates supported operations (create, list, get, update, delete, move, unassign, list_all_uncompleted), making the tool's scope clear. It distinguishes from sibling tools by focusing on tasks, though 'Manage' is somewhat generic. The operation list adds specificity, justifying a 4 rather than 5.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention operation-specific contexts. Cross-references like 'Use motion_statuses' and 'Use motion_schedules' appear only in schema parameter descriptions, not in the tool description, leaving the agent without explicit usage direction.
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. It discloses that create, list, and get operations are supported, but does not mention side effects (e.g., creating a project requires a name), authentication needs, rate limits, or any state changes. This is a significant gap for a tool that performs write operations.
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 clearly states the tool's purpose. It contains no filler or redundant information, and every word contributes to the meaning. For a simple CRUD-style tool, this level of conciseness is appropriate.
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?
Given the tool has 7 parameters, no annotations, and no output schema, the description is too thin to provide complete context. It does not explain return values, error behavior, or how the operations interact with parameters like workspaceId and allWorkspaces. Users would need to rely entirely on the schema, which is insufficient for task 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 baseline is 3. The description itself adds no parameter-level detail, but the schema already contains thorough descriptions for all seven parameters, including the enum for operation and caveats for allWorkspaces. Thus the description does not need to compensate.
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 states the tool manages Motion projects and explicitly lists 'create, list, and get' operations, giving a clear verb+resource. It distinguishes from sibling tools by focusing on the 'project' resource, though the verb 'manage' is somewhat generic and doesn't highlight specific unique capabilities.
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 use this tool versus alternatives like motion_tasks or motion_workspaces. The operation enum (create/list/get) implies usage, but the description does not provide decision criteria, prerequisites, or exclusions, leaving the agent to infer when each operation is appropriate.
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 of behavioral disclosure. It only says 'search,' implying a read operation, but provides no detail on result limits, matching logic, or the fact that the operation is constrained to 'content' as shown in the schema.
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 a single sentence with no unnecessary wording. It is appropriately concise for conveying the core purpose, though it omits important context that would make it more helpful.
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 search tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It does not explain behaviors like search scoping, workspace filtering, or what the returned data looks like.
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 description adds 'by query,' which highlights the query parameter but does not elaborate beyond the schema's existing parameter descriptions.
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 (Search), resource (Motion tasks and projects), and mechanism (by query). It clearly distinguishes from sibling tools like motion_tasks and motion_projects by covering both entities.
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 exclusions or prerequisites. The single sentence only states what it does, not when it should be used.
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 provided, the description carries the full burden of behavioral disclosure. It states the supported operations but does not clarify whether they are read-only, whether special permissions are required, or what the return payload looks like. It also omits potential side effects or limits, leaving significant behavioral unknowns.
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 concise sentence that front-loads the resource and operations. It contains no filler, redundant phrasing, or unnecessary details, making it highly efficient and easy to parse.
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 simplicity of the tool, the description is minimally sufficient, but it lacks context about workspace scope, return payload structure, or usage scenarios beyond the schema's operation enum. There is no output schema and no annotations, so the description leaves a few gaps that could hinder an agent's full understanding.
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 documents both parameters with descriptions (operation enum and workspaceId with a note about required for get), giving 100% schema description coverage. The tool description adds no additional meaning beyond what the schema provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Motion workspaces) and the supported operations (list and get), making the tool's purpose easy to grasp. However, the verb 'manage' is generic, and it does not explicitly distinguish this tool from sibling tools beyond the resource name, so it lacks the specificity of a top-tier description.
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 when to use the tool by listing the operations (list and get), but it provides no explicit guidance on when to prefer this tool over alternatives or when not to use it. No alternative tools or exclusions are mentioned, leaving the agent to infer usage from the operation enum.
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 disclosing behavioral traits. However, it only lists required parameters per operation and does not mention side effects (e.g., deletion is irreversible), permissions required, or any limitations. This is a significant gap for a mutation-heavy tool.
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 front-loaded with the purpose, then concisely lists required params per operation. It is dense but each clause carries relevant information. A more structured bullet list would improve scannability, but as a single paragraph it is acceptable.
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 tool has 12 parameters, no output schema, and no annotations, the description covers the parameter requirements thoroughly. However, it omits any information about return values, errors, or side effects, which is necessary for a management tool with multiple operations. The absence of output schema makes this gap more noticeable.
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 each parameter already includes 'Required for' notes. The description adds value by regrouping parameters by operation, which is convenient but does not introduce new semantic meaning beyond the schema. It also does not clarify value types or edge cases 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 begins with 'Manage custom fields for tasks and projects', which clearly identifies the resource and general action. It then enumerates all supported operations (list, create, delete, add/remove to/from project/task), distinguishing this tool from siblings like motion_tasks and motion_projects that handle other entities.
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 listing operations, but does not explicitly state when to prefer this tool over alternatives or when not to use it. It lacks phrases like 'use for' or 'instead of', so guidance is only implicit from the tool's name and scope.
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 must disclose behavior. It only lists required parameters and does not mention side effects, return values, or the destructive nature of delete. It lacks transparency about what happens when the tool is invoked.
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 a single sentence with a clear colon-delimited breakdown of operations, making it easy to scan. It is concise but slightly dense; however, every part contributes to understanding.
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?
With 15 parameters, a nested frequency object, and no output schema, the description only provides the minimum required params. It lacks context about return values, behavior, or edge cases, leaving significant gaps for a complex 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 coverage is 100%, so baseline is 3. The description adds value by specifying which parameters are required for each operation, which is not evident from the schema alone. However, it does not elaborate further on parameter formats or interactions.
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 states 'Manage recurring tasks' and lists operation-specific required parameters, making it clear that this tool handles CRUD operations for recurring tasks. It distinguishes from siblings like motion_tasks by focusing on recurring tasks, though the verb 'manage' is generic.
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 explicit required parameters for each operation (list, create, delete), giving clear context for when to use which operation. It does not mention exclusions or alternatives explicitly, but the per-operation breakdown is helpful.
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 must carry the full burden of behavioral disclosure. It correctly implies a read-only operation via 'Get', but it does not describe response format, pagination, or the behavior when workspaceId is omitted (though the schema does mention the latter). No contradictions exist.
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 concise sentence that leads with the verb and resource. It contains no extraneous information, and every word serves a purpose, making it highly efficient.
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 simplicity (one optional parameter, no output schema), the description combined with the schema provides sufficient information for an agent to invoke it correctly. The main gap is the lack of explicit usage guidance, but the read-only purpose and default behavior are covered elsewhere.
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%, with workspaceId fully described including its optional default behavior. The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline but does not exceed it.
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 (Get), the resource (task/project statuses), and the context (for a workspace). It distinguishes itself from sibling tools by focusing specifically on statuses, a unique resource not covered by other tools like motion_tasks or motion_projects.
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 when statuses are needed for a workspace, but it provides no explicit guidance on when to choose this tool over siblings, nor any exclusions. The context is clear enough, but there are no stated alternatives or when-not-to-use scenarios.
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. It discloses an important behavioral trait—'The Motion API returns all schedules with no filtering options'—and implies a read-only GET operation. However, it does not mention pagination, response shape, or any potential limitations beyond filtering.
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 concise sentences, no filler. The first sentence states the purpose and expected content; the second clarifies the lack of filtering. 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 list tool with one parameter and no output schema, the description adequately conveys what the agent will get (all schedules, weekly working hours, time zones) and the absence of filtering. It could add explicit return format details, but the tool's simplicity keeps the description sufficient.
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% for the single 'operation' parameter, which is an enum with 'list'. The description adds no new parameter-level detail; the phrase 'no filtering options' reinforces the enum but does not go beyond what the schema already states. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all schedules and specifies the kind of data they show (weekly working hours, time zones). It distinguishes itself from sibling tools by naming a unique resource type.
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 establishes when to use this tool: when you need schedules, and especially since it explicitly notes 'no filtering options,' it implies this is the go-to for all schedules rather than a filtered subset. It does not explicitly name alternatives, but sibling tool names make the resource distinction clear.
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:

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

Score Badge

Copy to your README.md:

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

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/chadramos/motion-mcp-server'

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