mcp-cronos

by mauriziomocci

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: v1.0.0
Disambiguation5/5
Each tool targets a distinct operation: adding new entries vs. appending to existing ones, reading vs. searching, consolidation vs. closure, listing projects vs. month status, etc. There is no significant overlap that would confuse an agent.
Naming Consistency3/5
Most tools use the imperative verb+noun pattern (e.g., aggiungi_entry, cerca, leggi_diario), but several are noun phrases (fine_giornata, riassunto_standup, lista_mese, settimana) and one uses a noun as verb (lista). This mixing of conventions reduces consistency.
Tool Count5/5
With 14 tools covering diary management, search, consolidation, summaries, and planning, the count is well-scoped for the domain. Each tool earns its place without being too few or excessive.
Completeness4/5
The surface covers creation, reading, searching, updating blockers, consolidation, summaries, and weekly reports. Missing are explicit update or delete operations for individual diary entries, but the consolidate tool can restructure content, so gaps are minor.
Average 4.3/5 across 14 of 14 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 98 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses file creation behavior and naming format, but lacks details on side effects (e.g., appending vs overwriting), permissions, or concurrency. Provides average transparency for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear purpose statement, file behavior details, and a parameter list. Slightly verbose due to parameter repetition, but each section earns its place. Concise enough for quick understanding.
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 12 parameters, no output schema, and no annotations, the description covers file creation, naming, return value, and parameter defaults. Misses details on concurrency and error handling, but overall sufficient 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%, but the description adds value with concrete examples (e.g., 'SmarTicket' for progetto) and clarifies defaults (e.g., data defaults to today). Enhances usability beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a new entry to a work diary, specifying the resource and action. It does not explicitly differentiate from siblings like 'cronos_aggiungi_a_progetto', but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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; does not mention context or prerequisites. The description only explains functionality without usage recommendations.
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?
The description ambiguously says it 'rileggendolo e riscrivendolo' (rereading and rewriting) but then says it returns instructions for rewriting, leaving unclear whether it actually modifies the file. No annotations are provided to clarify side effects or 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 well-structured with purpose, usage triggers, parameter list, and return value, all in a concise format with no wasted words.
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?
While the description covers purpose, usage, and parameters, it fails to clarify whether the tool performs the rewrite automatically or just provides instructions, leaving a significant gap given the lack of output schema and annotations.
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 only parameter 'data' is fully documented in the schema (100% coverage) and the description merely repeats the schema info without adding additional meaning. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Consolida' and resource 'diario', and includes example user phrases that trigger usage, distinguishing it from sibling tools like cronos_leggi_diario or cronos_aggiungi_entry.
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 lists when to use the tool with example user commands, but does not specify when not to use it or mention alternatives beyond the sibling list.
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 bears full burden. It discloses that the tool returns aggregated data with daily flags and entry counts, and lists which artifacts are checked. This is transparent for a read-only reporting tool, though it could explicitly state it is non-destructive.
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 a clear progression: output overview, details, use case, parameters, return. It is slightly wordy (7 sentences) but every part 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?
For a tool with 2 optional params and no output schema, the description adequately explains the return format (summary + daily details with flags). It covers the essential aspects, though could mention if there are limits or pagination.
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?
Both parameters (mese, anno) are documented in the schema with 100% coverage. The description repeats the defaults but adds no additional semantic nuance, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists the diary status for each day of a month, providing a monthly view with artifact presence and entry counts. This distinctively differentiates it from siblings like cronos_leggi_diario (single day) and cronos_settimana (weekly).
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 positions the tool as a 'quick glance' dashboard for the month, indicating when to use it. However, it does not provide explicit exclusions or alternatives, though the context of sibling tools makes 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?
With no annotations, the description carries the full burden. It states the tool reads entries and returns instructions, implying a read-only operation. It does not detail side effects like caching or logging, but the core behavior 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 well-structured with a clear overview, explicit trigger examples, and a numbered list of outputs. Every sentence adds 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description adequately explains that it returns diary entries with style instructions for generation. The low complexity and single optional parameter make this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description of the 'data' parameter with format and default, achieving 100% coverage. The description adds no extra meaning beyond what is in the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Chiusura di fine giornata' (end-of-day closure) and explains it reads diary entries and returns instructions for restructuring. It lists four specific outputs, distinguishing it from siblings like cronos_scrivi_fine_giornata which probably writes the final output.
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 lists trigger phrases such as 'Fine giornata' and 'Chiudi la giornata', providing clear context for when to use this tool. It does not explicitly state when not to use it, but the examples and context signals from sibling tools imply appropriate usage.
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 explains the input parameters and their defaults (e.g., ultimi_giorni default 30), and the return value (list of projects with occurrences and dates). It doesn't describe side effects, but as a read-like query that is acceptable.
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 three paragraphs but very concise. It front-loads the purpose and then details parameters and return. No unnecessary information. Could be slightly more structured but overall 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 no output schema, the description explains the return value adequately. All parameters are covered. The tool is simple (list projects) and the description provides enough context for an agent to use it 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?
Schema coverage is 100%, so baseline 3. The description adds value by explaining the fallback behavior: if no dates provided, it uses ultimi_giorni with a default of 30. This goes beyond the schema's 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 clearly states it lists projects mentioned in the diary over a period. It distinguishes from siblings like cronos_leggi_diario (reading full diary) and cronos_lista_mese (monthly list) by focusing specifically on projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Utile per avere una panoramica dei progetti su cui si e' lavorato' (useful for an overview of projects worked on), giving clear context for when to use it. It does not explicitly mention when not to use or list alternatives, but the purpose is clear enough.
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 describes the output (diary content with style instructions) and style constraints, but it does not explicitly state that the tool is read-only or that it does not modify data. Since the purpose implies reading, the lack of side-effect disclosure is a minor gap.
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: purpose, return value, style guidelines, usage triggers, and parameters. It is slightly longer than minimal but each section contributes meaningfully. The purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return value adequately. The three optional parameters are covered with clear usage notes. The description is complete for a tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by specifying defaults (e.g., 'data' defaults to 'last working day') and clarifying the range parameters. This augments the schema 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 clearly states the tool's purpose: 'Genera un riassunto discorsivo del diario per lo standup.' It specifies the resource (diary) and action (generating a discursive summary) for standup, distinguishing it from sibling tools that handle diary entries, projects, or other operations.
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?
The description explicitly lists common user queries that trigger this tool, such as 'Un riassunto per lo standup', 'Cosa dico allo standup?', 'Riassumi cosa ho fatto [data]', and 'Fammi un riassunto discorsivo'. This provides clear when-to-use guidance without needing to mention 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 provided, so the description bears full responsibility. It correctly identifies the tool as a read operation (non-destructive) and describes the return content (entries, projects, blockers). It lacks details about edge cases or permissions, but for a straightforward read tool, this is sufficient.
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 structured with bullet points for modes and parameters, front-loading key information. It is clear but slightly redundant (e.g., repeating 'Legge il contenuto del diario' in the return statement). A bit more conciseness could improve it.
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 no output schema, the description adequately covers the tool's functionality and return content. It explains all parameter combinations and expected results. Minor omissions like pagination or empty state handling do not detract significantly.
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 100% with basic descriptions, but the description adds significant value by grouping parameters into usage modes and explaining mutual exclusivity. This goes beyond schema semantics, making parameter relationships clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Legge il contenuto del diario' (reads diary content), specifying both the verb (read) and the resource (diary). The name and description distinguish it from siblings like cronos_aggiungi_entry (write) and cronos_leggi_todo (read todo), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description enumerates four mutually exclusive usage modes (single date, date range, last N days, default today), providing explicit guidance on how to invoke the tool. However, it does not mention when to avoid using this tool or suggest alternative tools for similar tasks (e.g., cronos_cerca for searching).
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 provided, but description discloses what is returned (markdown content, path, backup info) and implies read-only behavior; additional context about backup file adds transparency beyond basic function.
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 efficient with three sentences and a parameter list, front-loading the main action and delivering essential information without waste.
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 tool with one optional parameter and no output schema, description fully covers purpose, parameter, return values, and context (backup info), meeting completeness needs.
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 covers 100% of parameters with description already including format and optionality; description adds default behavior (oggi) and purpose, providing extra meaning beyond 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 'Legge il file todo.md di una data' with specific verb and resource, and distinguishes from siblings by focusing on reading a date-specific todo file, useful for answering 'che dovevo fare oggi?'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use (reading today's or specific date's todo) and mentions related backup from cronos_prepara_domani, but lacks explicit exclusions or comparisons to 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 behavior: todo.md is always overwritten, raw.md is created only if not exists, default date logic (weekday calculation), and optional explicit date. It also describes the return value.
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 sections for default, behavior, usage, and parameters. It is concise yet comprehensive, using bullet points effectively.
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?
The description covers all necessary aspects: purpose, behavior, parameter details, default calculation, and return value. It is complete for a tool with no output schema and moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal extra context beyond the schema: it explains the default date logic but does not significantly enhance parameter meaning.
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 prepares the next working day's folder with todo.md and raw.md skeleton. It specifies the exact files created and the conditional behavior, differentiating it from sibling tools like cronos_scrivi_fine_giornata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: after cronos_scrivi_fine_giornata or manually for future planning. It provides clear context but does not explicitly mention when not to use it.
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?
Without annotations, the description carries full burden. It states it writes a file, takes content and optional date, and returns a confirmation with the file path. This is sufficient for an agent to understand the action, though it could explicitly mention overwrite 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 concise (4 sentences) with a clear structure: purpose, usage instruction, parameter list, return value. Every sentence adds value, and the critical usage order is front-loaded.
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 absence of output schema and annotations, the description covers all essential aspects: what the tool does, when to use it (after cronos_fine_giornata), required/optional parameters, and the return type. No critical gaps.
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 both parameters well-described. The description repeats the schema descriptions exactly, adding no additional meaning or constraints. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Scrive il file di fine giornata con il contenuto generato.' It specifies the verb and resource, and distinguishes from sibling tool cronos_fine_giornata by noting the sequence order.
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?
The description explicitly directs to use this tool AFTER cronos_fine_giornata: 'Usa questo tool DOPO cronos_fine_giornata: prima generi il contenuto ... poi chiami questo tool.' This provides clear when-to-use guidance and implies when not to use (before generating content).
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 provided; description implies read-only behavior by stating it shows days worked per project. It is transparent about being a summary tool, with no indication of destructive actions.
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 front-loaded with purpose, followed by usage guidance and parameter explanation. Every sentence adds value with no fluff or repetition.
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 tool with one optional parameter and no output schema, the description fully explains input and expected output (summary by project with days, dates, activities). No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides the parameter 'data' with format and default, complementing the 100% schema coverage. It adds the default behavior context not evident from schema alone.
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's a weekly summary grouped by project. It distinguishes from siblings like cronos_leggi_diario (daily read) and cronos_riassunto_standup (standup summary) by specifying the weekly timeframe.
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?
Explicitly lists example user queries and says 'Use this tool when the user asks:' followed by examples. Does not specify when not to use, but the guidance is clear and actionable.
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?
Despite no annotations, the description fully discloses key behavioral traits: full-text search, case-insensitivity, regex support, default sources (all three), and the return format including fields for each source.
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: begins with purpose, then features, usage examples, and parameter list. It is slightly verbose but each section adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return structure in detail. All parameters are covered, and the usage examples cover typical scenarios. The tool is simple and the description is complete.
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% (all parameters have descriptions), but the description adds value by explaining defaults (ultimi_giorni=90, tipo defaults to all) and providing usage context for each parameter.
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 text in diary files (raw, todo, chiusura), and among sibling tools it's the only search tool, making its purpose distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit examples of user queries that trigger this tool and guides on using the 'tipo' parameter to filter sources. It doesn't mention when not to use, but the context makes it 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?
With no annotations, the description carries full burden. It discloses the prerequisite (file must exist) and return type, but lacks details on error handling or auth needs. Still, it provides adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and well-structured: purpose first, then prerequisite, then parameter list. Every sentence is informative and not redundant.
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 tool with 2 parameters and no output schema, the description is fairly complete. It covers purpose, prerequisite, parameters, and return value. Could mention error cases (e.g., file not found) but overall sufficient.
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 the default value for data ('oggi') and instructing to use 'Nessuno' when there are no blockers, which goes 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 ('Imposta o aggiorna') and resource ('sezione Bloccanti del diario'), distinguishing it from sibling tools like cronos_aggiungi_entry which creates files.
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 says the file must exist and references cronos_aggiungi_entry as the alternative to create it, providing clear guidance on when to use this tool.
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?
Discloses key behavioral traits: if entry exists, adds H4 sub-section avoiding fragmentation; if not, creates standard entry. Also describes return confirmation modes. No annotations exist, so description carries full burden and satisfies it well.
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?
Well-structured with three clear sections: behavior, usage guidance, and parameters. No redundant sentences, front-loaded with key purpose. Every sentence earns its place.
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 11 parameters, 3 required, and no output schema, the description fully covers behavior, usage, parameter meanings, and return type expectation. No gaps identified.
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. Description adds value by noting constraints like 'Nome esatto del progetto (deve corrispondere all'H3 esistente)' which supplements schema. Parameters are explained clearly but mostly align with 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 adds content to an existing project entry in the diary, distinguishing between adding to an existing entry or creating a new one. It explicitly differentiates from sibling tool cronos_aggiungi_entry by specifying use cases.
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 when-to-use scenarios (adding work to a project already in today's diary, with example phrases) and clearly names the alternative (cronos_aggiungi_entry) for new project entries.
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-cronos MCP server](https://glama.ai/mcp/servers/mauriziomocci/mcp-cronos/badges/card.svg)](https://glama.ai/mcp/servers/mauriziomocci/mcp-cronos)

Score Badge

Copy to your README.md:

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

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/mauriziomocci/mcp-cronos'

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