Bullet MCP

Server Quality Checklist

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

Latest release: v1.2.1
Disambiguation4/5
Most tools have clear, distinct purposes: entry CRUD, collection read, tag read. The only potential confusion is between list_entries and list_current, as both return scheduled items, but the descriptions clarify list_current is for the current period/overdue while list_entries uses presets or calendar queries.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern for the majority of tools: list_entries, create_entry, get_entry, update_entry, delete_entry, list_collections, get_collection, list_tags, get_tag. The outlier is list_current, which uses an adjective instead of a noun, but it's still readable and not jarring.
Tool Count5/5
With 10 tools, the server is well-scoped for its purpose of managing Bullet entries and referencing collections/tags. Each tool serves a distinct function and the count is within the ideal 3-15 range, making the surface neither too sparse nor overwhelming.
Completeness2/5
Entry CRUD is partially covered: create, list, get, and delete are present, but update_entry only changes the title, leaving no way to update status, schedule, or associations. Collections and tags are read-only, with no create/update/delete, so agents cannot manage these entities through the server, which is a significant functional gap.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 12, 2026
- 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.
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?
The description does not disclose any behavioral traits beyond the fact that it updates a title. The idempotentHint annotation already exists, but the description adds no additional context about effects on other fields, error cases, or preconditions. Since it adds nothing beyond the annotation, the score is low.
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 accurately and efficiently states the tool's function. There is no redundant content, and the key information 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?
For a simple two-parameter tool with an output schema and idempotentHint annotation, the description is minimally sufficient. However, it omits any contextual guidance about preconditions (e.g., entry must exist) or behavior on missing entries, which could lower completeness for an AI 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 input schema thoroughly describes both parameters (id as UUID, title with length constraints), so the description adds no additional parameter meaning. With 100% schema coverage, the 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 (update) and the specific resource attribute (entry's title), which distinguishes it from create/get/delete/list operations among its siblings. The verb and noun are specific 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 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, no prerequisites, and no exclusions. It relies on the tool name and schema to convey usage, which is less helpful for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the tool as read-only, and the description's 'Get' is consistent with that. However, the description adds no additional behavioral context such as error cases, permissions, or side effects, so it does not extend beyond the annotation's 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 a single sentence with no filler, front-loading the action and object. It is appropriately sized for the tool's simplicity.
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 a simple single-parameter tool with a rich input schema and output schema, the description provides enough context to understand the tool's purpose and usage. It is complete for the agent to select and invoke correctly, though it could mention error behavior but that is not necessary here.
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 describes the 'id' parameter with its type and source (list_tags), so the description's reference to 'by ID' adds no new meaning. With 100% schema coverage, a baseline of 3 is warranted.
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 ('Get') and resource ('tag'), and the qualifier 'single' distinguishes it from list_tags. This clearly indicates the tool retrieves one tag by identifier, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a specific tag by ID, but does not explicitly state when to use this versus list_tags or other siblings. No exclusions or alternative guidance is provided, so it earns a 3.
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?
Annotations declare readOnlyHint=true, so the read-only nature is already disclosed. The description adds no further behavioral context such as return format, pagination, or error handling, but this is partially mitigated by the output schema. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the core purpose effectively and is appropriately sized for a simple get-by-ID tool.
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 one required parameter, full schema coverage, and an output schema, the description is mostly complete. It doesn't elaborate on return structure, but the output schema covers that. A slight mention of what the collection object contains could improve it, but it's adequate.
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% (the id parameter has a clear description including a UUID hint and pointer to list_collections). The tool description merely restates 'by ID' without adding additional semantic meaning 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 uses a specific verb ('Get') and resource ('collection') with scope ('by ID'), clearly distinguishing this from sibling tools like list_collections (plural) and get_tag. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies singular retrieval by ID, and the schema description for the ID parameter explicitly instructs to get IDs from list_collections, providing a clear prerequisite/alternative. However, it does not explicitly state when to use this over list_collections beyond the singular/plural distinction.
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?
The description goes beyond the annotations by clarifying 'soft-delete' (non-permanent) and explaining idempotent behavior ('succeeds even if already deleted'), which is practical context. It does not mention auth or side effects, but for a simple soft-delete with annotations present, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action. The second sentence adds essential behavioral context without waste, making it appropriately concise.
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 one-parameter soft-delete tool with strong annotations (idempotentHint, destructiveHint) and a fully documented schema plus output schema, the description covers the key operational aspects. There are no gaps in necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the only parameter ('Entry ID (UUID) to delete. Succeeds even if already deleted.'). The tool description adds no new parameter semantics beyond reinforcing idempotency, so the baseline 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 'Soft-delete an entry' with a specific verb and resource, distinguishing it from siblings like update_entry and get_entry. The 'soft' nuance adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting entries but does not explicitly contrast with alternative tools such as permanent deletion or update_entry. It provides no when-not guidance, though the idempotency note gives some operational context.
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?
Annotations already declare readOnlyHint=true, and the description adds guidance about 'full details' and expand behavior. However, it does not disclose additional traits like auth requirements, rate limits, or error scenarios. The expand explanation is more about parameter semantics than deep behavioral transparency, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: the first clearly states purpose, the second explains the key optional parameter. The structure is front-loaded and efficient.
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 read-only get-by-id tool with a rich output schema and readOnlyHint annotation, the description is complete. It covers the core purpose and the expand option, and does not need to explain return values since output schema exists.
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%; the schema already thoroughly explains 'id' (UUID from list_entries) and 'expand' (inline collection/tags, array for both). The description's expand note adds minimal value beyond the schema, so baseline 3 is fitting.
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 a single entry by ID with full details, distinguishing it from sibling tools like list_entries (which lists multiple) and create_entry/update_entry/delete_entry (which modify). The verb 'Get' and resource 'entry' are specific 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 implies usage for retrieving a single entry by ID, contrasting with list_entries for multiple entries. It provides clear context but does not explicitly name alternatives or state when not to use this tool, so it falls just 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?
The readOnlyHint annotation already declares the tool is safe and non-destructive. The description adds modest context about returning IDs but does not disclose other behavioral traits like pagination or default filtering (beyond what the schema already explains). With annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with the main action front-loaded. Every word serves a purpose, with no filler or redundancy.
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 read-only list tool with one optional parameter and an output schema, the description is sufficient. It explains the tool's purpose, what it returns, and why (IDs for filtering). The output schema handles return structure, so the description doesn't need to elaborate further.
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 'archived' is fully documented in the schema, so the description adds no additional parameter-level meaning beyond what's already provided. The baseline of 3 applies due to high schema description 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 clearly states the tool lists all collections, defines them as folders for organizing entries, and explains the purpose of the returned IDs. This distinguishes it from get_collection, which fetches a single collection, and from other list tools for entries and tags.
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 gives clear context: use this to enumerate all collections and obtain IDs for filtering entries. However, it does not explicitly name alternatives or exclusion criteria (e.g., when to use get_collection instead), 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?
The readOnlyHint annotation already declares this as a safe read operation, and the description adds the context that it returns IDs useful for filtering. However, it does not disclose additional behavioral details such as pagination, sorting, or the behavior of the archived filter beyond what the schema already provides.
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 long, front-loaded with the primary action, and every clause adds value. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an output schema, the description is complete. It explains what the tool does, why the returned IDs matter, and pairs well with the readOnlyHint annotation and schema.
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 covers the one parameter ('archived') with a comprehensive description (true/false/omit), so the description adds no additional meaning. Since schema coverage is 100%, the 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 verb 'List' and resource 'tags', and adds context that tags are labels for categorizing entries. It also explains the purpose (returning IDs for filtering), which distinguishes it from siblings like list_collections or get_tag.
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 usage context by stating that the returned IDs are needed for filtering entries by tag. This implies when to use the tool, though it does not explicitly mention alternatives or 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?
Beyond the readOnlyHint annotation, the description discloses pagination behavior ('Returns paginated results; use cursor for next page') and mode-dependent filter constraints. It adds useful behavioral context without contradicting annotations.
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, front-loaded with purpose, and efficiently explains modes and pagination in three sentences. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 10 parameters and two modes, the description effectively summarizes core behavior and directs users to parameter descriptions. It also mentions pagination and assumes output schema covers return format, making it complete enough for most invocation scenarios.
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 has 100% description coverage, so the tool description pointing to parameter descriptions is sufficient. It does not add extra parameter meaning beyond the schema, but also does not need to.
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 lists tasks, notes, and events from Bullet, using specific verbs and resource types. It distinguishes from siblings like list_collections and list_tags by focusing on entries, and outlines two distinct query modes.
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 guidance on when to use 'view' presets vs. period+date calendar queries, and mentions that filters vary by mode. It does not explicitly name alternatives among siblings, but the mode explanation gives sufficient context for 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?
Beyond the readOnlyHint annotation, the description adds behavioral context: it returns overdue items and defaults to today. This gives the agent a clearer picture of what to expect without contradicting the annotation.
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: the first states the core function, the second provides usage guidance. It is concise, front-loaded, and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two optional parameters, a detailed schema, an output schema, and a readOnly annotation, the description offers sufficient context for correct invocation. The usage guidance and behavioral notes make it fully complete for this 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 schema already describes both parameters in full (100% coverage), including defaults. The description reinforces the period default ('Defaults to today') but does not add new parameter semantics 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 tool's function: 'Get scheduled entries for the current period plus any overdue items.' This distinguishes it from sibling tools like list_entries by specifying a time-scoped scope and the inclusion of overdue items.
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 context for when to use the tool: 'Use when the user asks what's on today, this week, this month, or wants a daily/weekly overview.' However, it does not mention when not to use it or explicitly name alternative tools.
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 burden of behavioral disclosure. It explains that tasks track completion status, notes do not, and events support timezone-aware datetimes—key behaviors beyond what the schema states. It also clarifies 'start' omission results in inbox placement. It does not mention error cases or side effects, but for a create tool this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and every clause adds value. It avoids repetition of schema details and is free of fluff, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core facets: what the tool creates, the key 'start' decision, and behavioral distinctions among entry kinds. It relies on the schema for parameter details and the output schema for return values, which is appropriate. It could mention 'period' explicitly, but the schema covers that.
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 semantic context beyond the schema by explaining how 'start' interacts with scheduling/inbox and how 'kind' affects behavior (status tracking, timezone support). This enriches the schema's mention of the 'period' parameter and the meaning of 'importance' is left to 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 states a specific verb ('Create') and resource ('task, note, or event in Bullet'), clearly distinguishing it from sibling tools like list_entries, get_entry, update_entry, and delete_entry. It also adds subtype semantics (tasks, notes, events) that further clarify its scope.
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 guidance on when to set 'start' (to schedule) versus omit it (to put into the inbox), and explains the differences between tasks, notes, and events. It does not explicitly name alternatives (e.g., 'use update_entry to modify'), but the context is sufficient for selecting this tool for creation.
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:

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

Score Badge

Copy to your README.md:

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

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/davebream/bullet-mcp'

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