Focus Timer AI MCP
Server Quality Checklist
Latest release: v1.0.11
- Disambiguation5/5
Each tool has a distinct, clearly defined purpose: start, end, pause, resume focus; start break; get sessions; get analytics; update settings. No ambiguity between them.
Naming Consistency5/5All tool names follow a consistent verb_noun pattern in snake_case (e.g., start_focus, get_analytics, update_settings). No deviations.
Tool Count5/58 tools is well-scoped for a focus timer server, covering the core lifecycle and management actions without being excessive or insufficient.
Completeness4/5Covers start, end, pause, resume, break, sessions, analytics, and settings. Lacks a tool to view current session/state or settings directly, but the core workflow is complete.
Average 2.1/5 across 8 of 8 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool is read-only and stateless, which contradicts the action of pausing a session (likely state change). No annotations exist, so the description carries full burden but is incorrect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with irrelevant boilerplate about analysis, rate limits, and idempotency that doesn't apply to pausing a focus session. It lacks conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given siblings like start_focus, end_focus, resume_focus, this tool needs context on what pausing means and how it differs from ending. The description provides none, and the output schema is irrelevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description's 'Args' section uses placeholder text for session_id and api_key, offering no real meaning for pausing a focus session. Parameters appear copied from another tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The first line states 'Pause the current focus session,' which is clear. However, the rest of the description describes an unrelated analysis tool, making the overall purpose misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' and 'When NOT to use' sections refer to structured analysis, not pausing a focus session. No guidance on when to pause or alternatives like end_focus or resume_focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims read-only and stateless behavior, which directly contradicts the tool's likely stateful nature of starting a timer session. Despite detailed transparency text, it is incorrect for the actual tool, leading to confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly long and repetitive, with a 'Behavior' section and a longer 'Behavioral Transparency' section that repeats the same points. It lacks conciseness and logical organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 3 parameters and an output schema, the description does not explain actual timer behavior, session management, or how to use the tool alongside siblings. It is completely inadequate for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description merely lists parameter names and types without explaining their purpose (e.g., what 'minutes' and 'task' mean for a timer). With 0% schema description coverage, this fails to add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Start a new focus timer session' but then immediately describes read-only analysis, contradicting the name and sibling tools which imply stateful session control. The purpose is misleading and unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides generic 'when to use' and 'when NOT to use' that describe analysis tasks, not focus timer usage. It fails to differentiate from siblings like end_focus, pause_focus, etc., and gives no context for when to start a timer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details read-only, idempotent, and stateless behavior, which contradicts the tool name implying mutation. Without annotations, the description should disclose actual behavior but instead misleads.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly long with redundant sections (Behavior, Behavioral Transparency) repeating the same points. It lacks conciseness and important information is not highlighted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool name and siblings, this is likely a timer settings update tool. The description is completely off-topic, providing no relevant information for the actual tool function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The 'Args' section merely repeats parameter names with vague descriptions like 'The work duration to analyze or process', which does not clarify their role in an update context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description claims to 'Update timer settings' but then describes a read-only analysis tool. The purpose is contradictory and misleading, providing no clarity on what 'update_settings' actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'When to use' and 'When NOT to use' sections, but they pertain to an analysis tool, not an update tool. This provides some structure but is irrelevant to the tool's actual purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although the 'Behavioral Transparency' section is detailed, it describes a read-only, stateless analysis tool, which directly contradicts the tool's intended mutation of a focus session. This inconsistency undermines transparency severely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly long and repetitive, duplicating behavior details in multiple sections. It lacks focus and includes irrelevant information for the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's name implies state mutation, the description omits critical details like what happens upon resuming, return values, and error conditions. The presence of an output schema is unaddressed, leaving the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description's 'Args' section merely repeats parameter names with generic phrases ('The session id to analyze or process'), failing to explain their role in resuming a focus session.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Resume a paused focus session' which is clear, but the subsequent behavior section contradicts this by claiming the tool is read-only and produces analysis output without modifying state. This creates ambiguity about the actual purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' and 'When NOT to use' sections are present but are generic and mismatched (e.g., suggest use for analysis/classification, not for resuming focus). They do not guide the agent on when to use this tool versus siblings like start_focus or pause_focus.
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?
A detailed 'Behavioral Transparency' section exists but describes a read-only tool, contradicting the action of starting a timer. Side effects and idempotency claims are false for a timer start, making the transparency misleading despite its depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly long with redundant sections (e.g., 'Behavior' and 'Behavioral Transparency' repeat similar points). It lacks focus and wastes space on irrelevant details for a timer start tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to explain the core functionality: how starting a break timer works, how to end it, or its relationship to focus sessions. Despite context signals indicating an output schema, its content is unknown, and the description does not compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter descriptions are generic and unhelpful, e.g., 'The break type to analyze or process.' With 0% schema coverage, the description fails to explain valid values, meaning of custom_minutes, or api_key usage. No enumeration or format hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description initially states 'Start a break timer' but then extensively describes a read-only analysis/classification tool, creating a contradiction. The verb 'start' implies state mutation, yet the behavior claims idempotence and statelessness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' and 'When NOT to use' sections are present but refer to analysis/classification, not break timer initiation. No guidance is given on how this tool differs from siblings like start_focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool is 'read-only and stateless' and 'produces analysis output without modifying any external systems', which directly contradicts the action of ending a focus session (which presumably changes session state). No annotations are provided to clarify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy with boilerplate content that does not belong (e.g., analysis framework talk). The first sentence is concise, but the rest is poorly structured and includes irrelevant sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and simple parameters, the description fails to explain essential details: what it means to end a focus session, the effect of the 'completed' flag, authentication requirements, or how it differs from sibling tools. The description is largely irrelevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'Args' section merely restates parameter names with generic phrases like 'to analyze or process'. With 0% schema description coverage, the description adds no meaningful information beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence 'End a focus session early' clearly states the tool's primary function. However, the subsequent description diverges into generic analysis/classification language that is irrelevant to ending a focus session, causing confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' and 'When NOT to use' sections discuss structured analysis and classification, which are unrelated to ending a focus session. No guidance is provided on when to use this tool vs. siblings like pause_focus or start_break.
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 comprehensively covers side effects (read-only), idempotency, rate limits, authentication needs, error handling, and data privacy. This fully informs the agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly long and repetitive, with 'Behavior' and 'Behavioral Transparency' sections saying the same things. Generic sections like 'When to use' add no value for this specific tool. It could be cut by 60% without losing meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, return values are covered, but parameter semantics are severely lacking. The description fails to clarify what 'date' and 'limit' do in context of sessions, and no example or further details are given. The tool's stats output is not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The 'Args' section merely repeats parameter names and types with a useless 'to analyze or process' suffix. No explanation of date format, limit's effect, or api_key usage is provided, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states 'Get all focus sessions with stats', specifying both the action and resource. This distinguishes it from siblings like get_analytics. However, the description later includes generic text about 'structured analysis or classification' which dilutes the focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' and 'When NOT to use' sections are generic templates not tailored to this tool. They reference 'structured analysis' and 'classification', which are unrelated to fetching sessions. No guidance is given on when to prefer this tool over siblings like end_focus or start_focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers exceptional transparency. A dedicated section covers side effects (read-only, no side effects), authentication (none for basic), rate limits (free vs pro), error handling (structured errors), idempotency (fully idempotent), and data privacy (local processing). This exceeds expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings and sections, making it easy to scan. However, it is somewhat verbose, repeating details about idempotency and error handling that could be condensed. Overall, good organization but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 optional parameters and an output schema exists, the description covers behavior thoroughly but fails to specify what analytics are produced (e.g., usage counts, trends). The vague reference to 'frameworks or standards' does not clarify the output, leaving a gap in context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description's 'Args' section provides only generic descriptions ('The period to analyze or process') that add no meaningful meaning beyond the parameter names. No acceptable values, constraints, or examples are given for 'period' or 'api_key' defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns productivity analytics and describes behavior as generating structured output. However, it lacks specificity about what data is returned (e.g., session metrics, trends). This ambiguous purpose is not clearly differentiated from sibling get_sessions, which might provide raw session data rather than analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to use' and 'When NOT to use' sections, providing clear context for appropriate usage (structured analysis) and caution against real-time decisions without human review. However, it does not directly compare to sibling tools or explain when to choose analytics over session-focused tools.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/CSOAI-ORG/focus-timer-ai-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server