NitroStack Calculator MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clear, distinct purpose: calculation, temperature conversion, fetching notifications from specific platforms (Slack, Jira, Calendar, GitHub, Gmail), building user context, prioritizing notifications, and listing Gmail accounts. There is no ambiguity between tools, as the platform or action is explicitly stated in the name/description.
Naming Consistency2/5
Tool names follow mixed conventions: most use camelCase with a verb prefix (e.g., fetchSlackNotifications, buildUserContext), but one uses snake_case (convert_temperature) and another is a bare verb (calculate). Verbs also vary (calculate, fetch, build, prioritize, convert, list), so no consistent verb_noun pattern exists.
Tool Count4/5
At 10 tools, the count is within the typical 3-15 range and not excessive. However, the server's stated 'Calculator' purpose is served by only two tools (calculate, convert_temperature), while the majority focus on notification aggregation, so the count feels somewhat misaligned with the server name but is still reasonable for the actual feature set.
Completeness3/5
The notification aggregation workflow is fairly complete: fetching from five platforms, building user context, and prioritizing. However, the calculator functionality is minimal (basic arithmetic and temperature only), missing many expected operations like unit conversions or scientific functions. Additionally, there is no 'mark as read' or 'send' action for notifications, so the domain has notable gaps.
Average 3.6/5 across 10 of 10 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
Annotations are absent, so the description carries the full burden. It only says 'perform basic arithmetic calculations' and does not disclose edge-case behavior (e.g., division by zero), return format, or side effects. The stateless nature is implied but not stated, and error handling is completely unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant information. It is front-loaded and efficient, though very brief. No structural issues, but it could include a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should at least mention the return type or behavior, but it does not. The tool is simple, but for full contextual completeness, the description should state that it returns the numeric result and possibly note error conditions like division by zero. As it stands, an agent is left to infer these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description (e.g., 'First number', 'Second number', 'The operation to perform'). The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it performs basic arithmetic, which is clear but vague about the specific operations and operands. It doesn't explicitly mention that it takes two numbers or supports add/subtract/multiply/divide, and it doesn't distinguish itself from the sibling tool convert_temperature. The verb 'perform' and resource 'basic arithmetic calculations' are present, but the scope is under-specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any use cases, prerequisites, or exclusions, leaving the agent without context for selection. With siblings like convert_temperature, clearer differentiation would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says the tool converts temperature units and supports two modes. It omits critical behavior such as the requirement for file parameters (file_name, file_type, file_content are required in the schema), how return values are structured, and whether direct input can actually be used independently. The phrase 'direct input' conflicts with the schema's required file fields, creating confusion.
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 compact at two sentences and front-loads the primary action. However, the second sentence merely repeats the enum values already present in the schema, making it slightly redundant, though not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and a potentially complex file-or-direct-input workflow, yet the description is only two sentences. It lacks information about return values, required file format, error conditions, and how the system injects file_content, making it insufficient for an agent to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning by introducing the concept of file-based vs direct input, but it does not elaborate on the relationship between file_content and value/from_unit/to_unit. The 'Supports C and F' phrase is redundant with the schema enums.
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 uses a specific verb ('Convert') and identifies the resource (temperature units) and supported scales (C/F), making the tool's purpose clear. However, it does not explicitly distinguish this from the sibling 'calculate' tool, and the 'file content or direct input' phrasing introduces ambiguity about the exact conversion workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'calculate', nor does it mention any exclusions or prerequisites. 'File content or direct input' is the only usage context, but it fails to clarify which input path should be chosen or how the tool handles file-based vs direct values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not indicate whether the operation is read-only, whether it has side effects, requires authentication, or simply compiles already-fetched data. The lack of any mention of return format or operational characteristics leaves significant ambiguity for a tool with zero annotations and no output schema.
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 core purpose and key included data points. Every phrase earns its place, and there is no redundant or filler content.
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 (0 params, no output schema), so the description must cover what the tool does and what it returns. It lists the components of the compiled context, which helps, but it does not indicate what form the output takes (e.g., a summary object, a list) or how this tool relates to the sibling fetch tools. This is adequate for a basic understanding but leaves some gaps for an agent deciding whether to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter semantics. Per the rubric, the baseline is 4 for a no-parameter tool. The description adds value by specifying the kind of context compiled, but since there are no parameters to explain, no additional compensation is needed.
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 'compile' and identifies a distinct resource: context about the user's current work state. It further lists concrete components (active project, meetings within the hour, key collaborators), clearly differentiating it from sibling tools that simply fetch notifications or perform calculations. The purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. While siblings like fetchCalendarEvents or fetchGmailNotifications overlap with specific data sources, the description does not state that this tool should be used for a holistic overview before prioritizing, nor does it mention any exclusion criteria or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does mention that the return format is 'Notification format,' which is useful context. However, it does not explain default time ranges, result limits, ordering, authentication needs, or how the optional 'since' parameter interacts with 'upcoming and recent,' leaving ambiguity about the tool's actual 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 two short sentences. The first states the core action and scope, and the second specifies the return format. Every sentence is purposeful and contributes directly to understanding the tool, with no redundant or filler content.
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 with one optional parameter and full schema coverage, so the schema carries some weight. However, the description introduces ambiguity with 'upcoming and recent' — it does not define what counts as recent, what the default time window is when 'since' is omitted, or how many events will be returned. Without an output schema, the mention of Notification format is helpful but insufficient to fully understand the response structure.
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 description coverage is 100%, with the 'since' parameter clearly documented as 'ISO 8601 timestamp. Only returns events starting after this time.' The tool description adds no additional meaning about the parameter, so it does not go beyond the schema. 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 states 'Fetch upcoming and recent calendar events' with a specific verb 'fetch' and resource 'calendar events,' clearly distinguishing it from sibling notification tools like fetchSlackNotifications or fetchGithubNotifications. It also specifies the return format, 'a list of meetings in Notification format,' making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The tool's purpose is implied by its name and sibling context (fetching calendar notifications), but there is no statement of exclusions, prerequisites, or when to choose this tool over other notification fetchers. Usage is only implicitly conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that a flattened list is returned and lists some notification categories, but it does not specify the default time window, authentication requirements, rate limits, or side-effect/read-only status. 'Recent' is vague and leaves important behavioral details unstated.
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 with no filler. It is front-loaded with the action and resource, and every word contributes useful information.
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 tool with one optional parameter and no output schema, this description provides the basic purpose and return type. However, it lacks details about the default time interval and the structure of the returned flattened list, leaving some ambiguity for an agent.
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 single optional parameter `since` is already fully described in the schema as an ISO 8601 timestamp that filters notifications. The description adds no extra parameter detail, but with 100% schema description coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and identifies the resource 'GitHub notifications' with content examples (PR review requests, CI failures, and mentions). This clearly distinguishes it from sibling notification fetchers like fetchSlackNotifications or fetchJiraNotifications.
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?
While no explicit when-not-to-use or alternative names are mentioned, naming 'GitHub notifications' provides clear context for when this tool is appropriate. The sibling tool names make the intended scope obvious, though an explicit exclusion would strengthen this dimension.
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 of transparency. It discloses that the operation is a read (fetch), covers all connected accounts, and returns a flattened list. It does not mention auth requirements, rate limits, or what 'recent' means, but given the simplicity of the tool, the disclosed scope is a meaningful behavioral trait.
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 sentences, 18 words, and front-loads the primary action. Every word contributes to understanding the tool's purpose and return type, with no redundancy or filler.
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 with one optional parameter and no output schema. The description explains it returns a flattened list of notifications, but does not detail the notification structure, default time range, or pagination. Given the existence of sibling notification tools, this may be sufficient, but the lack of output schema places more burden on the description to clarify return format.
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 covers 100% of the parameter description, clearly explaining 'since' as an ISO 8601 timestamp filter. The tool description adds no extra parameter context, but the baseline of 3 applies when schema coverage is high, and no further details are necessary.
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 fetches recent emails from Gmail accounts, with a specific verb (fetch) and resource (Gmail emails). It explicitly distinguishes from sibling tools by focusing on Gmail, and adds the scope 'across all connected Gmail accounts' which is unique to this tool.
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 context is implied by the tool name and the mention of Gmail, making it clear when to use it over Slack/Jira/GitHub siblings. However, there is no explicit guidance on when to choose this tool vs alternatives, nor any stated exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that it returns a flattened list, but does not mention if the operation is read-only, whether it requires authentication, or how results are ordered or limited. This is a notable transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and resource. Every word adds value, with no repetitive or filler content.
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 with one parameter and no output schema. The description covers the resource and return type but omits details like result ordering, limits, or error behavior. Given its low complexity, it is adequate but not comprehensive.
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 fully documents the only parameter 'since' with an ISO 8601 timestamp, providing 100% coverage. The description adds the word 'recent' but does not add meaningful semantics beyond what the schema already provides, so a baseline of 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 action 'Fetch' and the specific resource 'recent Slack DMs, mentions, and channel messages'. It distinguishes itself from sibling tools like fetchJiraNotifications or fetchGmailNotifications by explicitly naming Slack.
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 tool is for Slack notifications, setting context for when to use it versus other platform-specific sibling tools. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states that a flattened list is returned and scopes to recent updates, but does not disclose authorization requirements, rate limits, default time range if 'since' is omitted, or any side effects. 'Fetch' implies read-only but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient sentences with no unnecessary words. It front-loads the action and resource, making it immediately clear what the tool does.
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 description covers the basic purpose and return format, but with no output schema, it lacks details about the structure of each notification. It also omits behavior when 'since' is absent and does not specify limits or ordering, leaving moderate gaps for a relatively simple tool.
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 single parameter 'since' has complete schema coverage (100%), so the schema already provides its meaning. The description adds no extra parameter detail, aligning with the baseline of 3 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 (Fetch) and clearly identifies the resource (Jira ticket updates) with examples of update types (assignments, comments, due dates). It distinctly marks this as the Jira-specific tool among sibling notification fetchers.
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 clear context for when to use the tool (to fetch recent Jira updates) but does not explicitly mention alternatives or exclusions relative to sibling tools like fetchSlackNotifications. The name and sibling list imply usage, but explicit wording like 'for Jira notifications' is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core behavior (grouping into tiers) but does not explain the prioritization criteria, whether the input is mutated, or the exact representation of the output. This is informative but lacks key behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb 'Prioritize' and contains no unnecessary words. Every word contributes to understanding the tool's function.
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 has complex nested inputs and no output schema. The description states the tier names but does not explain the output structure (e.g., grouped list or added property) or how the context influences prioritization. This leaves some ambiguity for a tool of this 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?
Both parameters have schema descriptions providing 100% coverage. The description adds no additional meaning about parameter semantics; it merely names the list and context. With high schema coverage, 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 uses the specific verb 'Prioritize' and clearly identifies the input (a list of notifications) and output (Urgent, Normal, FYI tiers) based on the user's work context. This distinguishes it effectively from sibling fetch and context-building tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after collecting notifications and building a user context, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. The intended usage is clear from the parameters, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Retrieve' implies a read-only operation, but the description doesn't elaborate on potential nuances such as auth requirements, rate limits, or empty-result behavior. This is acceptable for a simple list tool but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the essential information without any fluff. It is appropriately front-loaded and concise.
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 extremely simple (0 parameters, no output schema), and the description adequately covers its purpose and scope. It could mention that the result is a list, but 'all' implicitly conveys the list nature. Overall, it is complete for the tool's 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?
The input schema has zero parameters, so schema coverage is trivially 100%. The description correctly reflects that no parameters are required, and no additional parameter explanations are necessary.
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 'Retrieve', names the resource 'connected Gmail accounts', and scopes it to 'configured for the user'. This clearly distinguishes it from sibling tools like fetchGmailNotifications, which handle notifications rather than account lists.
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 when to use the tool: whenever a list of connected Gmail accounts is needed. Although it doesn't explicitly name alternatives or exclusions, the simple nature of the tool and distinct sibling names provide sufficient contextual 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

notification-prioritizer-mcp-app MCP server

Copy to your README.md:

[![notification-prioritizer-mcp-app MCP server](https://glama.ai/mcp/servers/harinie-4466/notification-prioritizer-mcp-app/badges/card.svg)](https://glama.ai/mcp/servers/harinie-4466/notification-prioritizer-mcp-app)

Score Badge

Copy to your README.md:

[![notification-prioritizer-mcp-app MCP server](https://glama.ai/mcp/servers/harinie-4466/notification-prioritizer-mcp-app/badges/score.svg)](https://glama.ai/mcp/servers/harinie-4466/notification-prioritizer-mcp-app)

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/harinie-4466/notification-prioritizer-mcp-app'

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