mcp-crontab-server

by jasona7

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: v2.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: list/search target entries, add/remove modify entries, get_cron_logs retrieves logs, and the three expression tools (explain, validate, next_runs) each return different outputs. There is no overlap that would confuse an agent.
Naming Consistency4/5
Most tools follow a verb_noun pattern (list_crontab, search_crontab, add_cron_entry, etc.) with consistent snake_case. The exception is 'next_runs', which is a noun phrase rather than verb-first, and 'get_cron_logs' uses 'get' while others use different verbs, but the overall pattern is still readable.
Tool Count5/5
8 tools is well-scoped for a crontab manager: entry operations (list/search/add/remove), log retrieval, and cron expression utilities (explain/validate/next_runs). Each tool serves a distinct need, and the count is appropriate.
Completeness4/5
The surface covers the core workflows: viewing (list/search), modifying (add/remove), checking execution (logs), and handling expressions (explain/validate/next_runs). An update/edit tool is missing, which would be a minor gap, but re-adding after removal is a workaround.
Average 3.8/5 across 8 of 8 tools scored.
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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic action. It does not specify what constitutes 'recent', whether logs are system-wide or user-specific, or any prerequisites. The agent lacks context about side effects, scope, or limitations.
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, direct sentence that conveys the purpose with no unnecessary words. It is appropriately sized for a simple retrieval tool.
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?
The tool is simple (one optional parameter) and has an output schema, so the description is minimally complete. However, it leaves ambiguity about the scope of 'system' and the meaning of 'recent', and does not address how to get logs for specific cron jobs (though the tool only supports a line count).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has full coverage for the only parameter 'lines' with a description, so the baseline is 3. The tool description does not add any additional meaning to this parameter, but the schema adequately documents 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 tool retrieves recent cron execution logs, using a specific verb ('Get') and resource ('cron execution logs'). This distinguishes it from sibling tools that manage cron entries, such as list_crontab or add_cron_entry.
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 inspecting logs but does not explicitly discuss when to use it versus alternatives. No exclusions or comparison with sibling tools are provided, leaving the agent to infer the use case.
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?
Without annotations, the description relies entirely on itself. It discloses a key behavior: 'Shows what will be removed,' indicating a preview or output. However, it does not state that removal is permanent/irreversible, or mention any permissions or side effects. The destructive nature is implied by the verb 'Remove' but not elaborated.
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 short sentences. It front-loads the purpose and adds one behavioral detail. No waste.
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's simplicity (one parameter) and the presence of an output schema, the description is adequate but not rich. It explains the removal action and shows behavior, but lacks a cautionary note about permanence or a connection to sibling tools. The 'Shows what will be removed' could be misinterpreted as a dry-run, so a bit more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the 'pattern' parameter ('Text pattern to match the entry to remove'), achieving 100% coverage. The description adds no additional semantics beyond that, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Remove crontab entries matching a pattern.' This is a specific verb (Remove) with a resource (crontab entries) and a matching mechanism. It also adds a distinguishing behavior ('Shows what will be removed') that separates it from list/search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like search_crontab or list_crontab. The description implies it is for removal but does not provide context on when to prefer it, prerequisites, or when not to use it. For example, it doesn't suggest using search_crontab first to preview matches.
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 mentions 'current user's crontab', which scopes the operation, but does not disclose side effects such as whether the entry is appended, whether duplicates are allowed, or whether the schedule is validated. The description is too minimal to provide adequate behavioral transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that fully states the tool's purpose and scope with no wasted words. It earns its place and is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with an output schema present, the description is adequate but sparse. It omits any mention of validation behavior or duplicate handling, but the schema and output schema likely fill some gaps. Overall it is minimally complete for the tool's simplicity, though richer context would be better.
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 provides complete descriptions for both parameters (command and schedule) with 100% coverage. The tool description itself adds no parameter-specific meaning, so it rests at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('a new entry to the current user's crontab'), clearly distinguishing it from siblings like 'list_crontab', 'remove_cron_entry', and 'validate_cron_expression'. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the intended use: when you want to create a new cron job. It does not explicitly exclude alternatives or mention 'when not to use', but the sibling set makes the context obvious, and there are no competing 'add' tools. This meets the 'clear context, no exclusions' level.
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 bears the full transparency burden. It indicates a non-mutating 'calculation' behavior, but it does not disclose details such as timezone handling, behavior with invalid cron expressions, or whether the count starts from the current time. This leaves some ambiguity about edge-case behavior.
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 with no unnecessary words. It states the core action and object clearly, making it maximally concise while remaining informative.
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 tool is simple, and an output schema is present, so the description does not need to explain return values. The core function is well captured. However, it lacks any mention of how this tool relates to sibling cron tools, such as when to use it instead of validators or log viewers, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because both 'expression' and 'count' have descriptions. The tool description adds little beyond the schema, only indirectly relating 'N' to the count parameter via the phrase 'next N execution times'. Baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'calculate' and identifies the exact resource ('next N execution times for a cron expression'). This clearly differentiates it from sibling tools like validate_cron_expression and explain_cron_expression, which serve different purposes.
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 one needs to compute future run times of a cron expression, but it does not explicitly state when to prefer this tool over siblings, nor does it mention any exclusions or alternatives. Guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the function is a validation check that returns errors, implying a read-only operation. However, since no annotations are provided, the description must disclose side-effect risks on its own; it does not explicitly state that no state is changed, nor does it mention any permissions or edge cases.
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 efficiently conveys the tool's purpose and key output behavior with 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?
For a simple one-parameter tool with an output schema, the description covers the essential purpose and return behavior. It is slightly incomplete in not providing any usage guidance, but the low complexity keeps the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'expression' parameter with 100% coverage. The description adds minimal semantic value beyond the schema, only clarifying that the expression is checked for syntactic validity.
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 validates cron expressions and returns specific errors for invalid fields. This specific verb-resource pair (check + cron expression) distinguishes it from sibling tools like list_crontab, add_cron_entry, or explain_cron_expression.
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?
Usage is implied: validate an expression before using it in other cron tools. However, there is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives (e.g., if you need an explanation, use explain_cron_expression).
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 burden. It discloses the case-insensitive matching behavior, which is useful context for an agent. However, it does not mention read-only nature, empty result behavior, or any limitations beyond the literal search semantics. This is minimal but not absent transparency.
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 with no filler words. It communicates the core action, target resource, and a key modifier (case-insensitive) efficiently.
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 parameter, output schema present), the description provides sufficient context for an agent to select and invoke it. The main gap is lack of explicit guidance on when to prefer this over list_crontab, but for a one-line search function, this is a minor omission.
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 alone says the keyword is 'Text to search for', but the description clarifies that matching is case-insensitive and uses 'containing' to imply substring matching. This adds meaningful semantic detail beyond the schema, which already covers the parameter name and type.
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 searches crontab entries for a keyword, with case-insensitivity as a key qualifier. It uses a specific verb ('Search') and resource ('crontab entries'), and distinguishes from siblings like list_crontab by implying a filtered search rather than a full 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 intended use case is implied: when you need to find crontab entries containing specific text. However, it does not explicitly mention alternatives or when not to use this tool. No exclusion criteria or comparison to sibling tools are provided, so it remains at the 'implied usage' level.
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. 'List' inherently indicates a read-only operation, and the description adds scope ('current user') and output detail ('with line numbers'). However, it does not explicitly state 'read-only' or disclose any potential side effects, which would be more 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 a single sentence that is direct and front-loaded with the action and target. Every word is meaningful with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an output schema available, the description sufficiently covers the tool's purpose and scope. It mentions the user context and line numbers, making it complete for an agent to understand the tool's function.
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 zero parameters, so schema coverage is effectively 100%. The description adds no parameter information because none exist, and the baseline for zero parameters is 4.
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 a specific verb ('List'), a specific resource ('crontab entries'), and adds scope ('for the current user') and output detail ('with line numbers'). This distinguishes it from siblings like search_crontab and get_cron_logs, which imply different purposes.
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 viewing all crontab entries but does not explicitly state when to use this tool versus alternatives. No exclusions or direct references to sibling tools are provided, so guidance is only implied.
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 transparency burden. It discloses supported input formats (5-field cron, special strings like @daily), which informs the agent about limitations. It does not mention error handling or side effects, but these are likely minimal for an explain tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the purpose, and contains no wasted words. It efficiently conveys the core function and supported input types.
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 single-parameter tool with an output schema (though not shown), the description adequately covers purpose and input constraints. No additional context is needed to invoke the tool correctly.
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 already provides strong parameter description coverage (100%), and the description adds value by clarifying which cron variants are accepted ('5-field cron and special strings'), supplementing the schema's example with broader format guidance.
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 function with a specific verb ('explain') and resource ('cron expression'), and distinguishes it from siblings like validate_cron_expression by focusing on human-readable explanation rather than validation.
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 it (to understand a cron expression) but does not explicitly contrast with alternatives like validate_cron_expression or list_crontab. It lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

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

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