Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Bullet MCP show me my overdue tasks"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the Bullet API. Manage tasks, notes, and events from Claude Desktop, Claude Code, VS Code, Cursor, or any MCP client.
Types are generated from the OpenAPI spec. Tool input schemas use Zod that mirrors the API contract. Registration tests verify they stay in sync. The MCP server version matches the Bullet API version.
Tool | Description |
| List entries with filtering by view ( |
| Create a task, note, or event. Omit |
| Get a single entry by UUID. Optionally expand collection/tags. |
| Update an entry's title. |
| Soft-delete an entry. |
| List all collections. Filter by archived status. |
| Get a single collection by UUID. |
| List all tags. Filter by archived status. |
| Get a single tag by UUID. |
Related MCP server: ticktick-cli
Go to bullet.to → Settings → API. Tokens start with blt_.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"bullet": {
"command": "npx",
"args": ["-y", "@davebream/bullet-mcp"],
"env": {
"BULLET_API_TOKEN": "blt_your_token_here"
}
}
}
}claude mcp add bullet -e BULLET_API_TOKEN=blt_your_token_here -- npx -y @davebream/bullet-mcpOpen MCP config (Ctrl+Shift+P → "MCP: Open User Configuration"):
{
"servers": {
"bullet": {
"command": "npx",
"args": ["-y", "@davebream/bullet-mcp"],
"env": {
"BULLET_API_TOKEN": "blt_your_token_here"
}
}
}
}Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"bullet": {
"command": "npx",
"args": ["-y", "@davebream/bullet-mcp"],
"env": {
"BULLET_API_TOKEN": "blt_your_token_here"
}
}
}
}bun install # install dependencies
bun run test # run all tests
bun run lint # biome lint + format check
bun run typecheck # type-check
bun run build # compile to dist/
bun run generate # regenerate types from OpenAPI specspec/openapi.json ← source of truth (Bullet API contract)
↓ bun run generate
src/client/types.generated.ts ← auto-generated types (don't edit)
src/client/types.ts ← re-exports for convenience
src/client/api.ts ← typed HTTP client
src/tools/definitions.ts ← Zod schemas for MCP tool inputs
src/tools/entries.ts ← pure handlers: (client, params) → string
src/tools/collections.ts
src/tools/tags.ts
src/tools/format.ts ← pure formatters
src/index.ts ← MCP server wiring (only file with side effects)Tool handlers are pure functions — pass in a client and params, get a string back. Tests use stub clients, no HTTP mocking.
Lefthook runs biome + gitleaks on commit, typecheck + tests on push:
lefthook installTest tools interactively with MCP Inspector:
BULLET_API_TOKEN=blt_xxx npx @modelcontextprotocol/inspector node dist/index.jsCreate a task, note, or event in Bullet. Set 'start' to schedule it on a date/time, or omit 'start' to put it in the inbox. Tasks track completion status, notes don't, events support timezone-aware datetimes.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Entry type: task (has status), note (no status), or event. | |
| start | No | When this entry is scheduled. Omit to place in inbox. Accepts: YYYY-MM-DD (date), YYYY-MM (month), YYYY (year), or ISO 8601 datetime with timezone for events. The period parameter controls how date-only values are interpreted. | |
| title | Yes | Entry title (1-500 characters). | |
| period | No | Schedule granularity. Controls how a date-only 'start' is interpreted: 'day' = that specific day, 'week' = the week containing that date, etc. Defaults to 'day'. Only meaningful when 'start' is set. | |
| importance | No | Priority level: 1 = low, 2 = medium, 3 = high. Omit for default. |
| Name | Required | Description |
|---|---|---|
| entry | Yes |
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.
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.
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.
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.
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.
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.
Soft-delete an entry. Idempotent — succeeds even if already deleted.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Entry ID (UUID) to delete. Succeeds even if already deleted. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| deleted | Yes |
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.
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.
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.
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.
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.
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.
Get a single collection by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Collection ID (UUID). Get IDs from list_collections. |
| Name | Required | Description |
|---|---|---|
| collection | Yes |
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.
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.
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.
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.
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.
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.
Get a single entry by ID with full details. Use expand to include the collection and/or tags inline instead of just IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Entry ID (UUID). Get IDs from list_entries. | |
| expand | No | Include related objects. 'collection' inlines the collection, 'tags' inlines tags. Pass an array for both. |
| Name | Required | Description |
|---|---|---|
| entry | Yes |
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.
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.
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.
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.
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.
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.
Get a single tag by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Tag ID (UUID). Get IDs from list_tags. |
| Name | Required | Description |
|---|---|---|
| tag | Yes |
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.
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.
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.
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.
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.
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.
List all collections (folders for organizing entries). Returns IDs needed for filtering entries by collection.
| Name | Required | Description | Default |
|---|---|---|---|
| archived | No | Filter by archived status. true = only archived, false = only active, omit = all. |
| Name | Required | Description |
|---|---|---|
| collections | Yes |
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.
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.
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.
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.
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.
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.
Get scheduled entries for the current period plus any overdue items. Defaults to today. Use when the user asks what's on today, this week, this month, or wants a daily/weekly overview.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Include related objects. 'collection' inlines the collection, 'tags' inlines tags. Pass an array for both. | |
| period | No | Time scope. 'day' = today, 'week' = this week, 'month' = this month, 'year' = this year. Defaults to 'day'. |
| Name | Required | Description |
|---|---|---|
| period | Yes | |
| current | Yes | |
| overdue | Yes |
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.
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.
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.
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.
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.
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.
List tasks, notes, and events from Bullet. Two modes: (1) use 'view' for presets (inbox=unscheduled, overdue=past-due), or (2) use period+date for calendar queries. Each mode has different valid filters — see parameter descriptions. Returns paginated results; use cursor for next page.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag ID. Pass an array to match any. Works with view=overdue or without a view. Not valid with view=inbox. Use list_tags to find IDs. | |
| date | No | Anchor date for period queries. Format must match period: YYYY-MM-DD for day/week, YYYY-MM for month, YYYY for year. Defaults to current date if omitted. Cannot be used with a view. | |
| kind | No | Filter by entry type. Pass an array to match any. Works with view=inbox or without a view. Not valid with view=overdue. | |
| view | No | Preset view. 'inbox' = unscheduled entries (supports status, kind filters). 'overdue' = past-due tasks (supports collection, tag filters). Omit to query by period/date instead. | |
| limit | No | Max entries to return (1-200, default 50). | |
| cursor | No | Pagination cursor from a previous list_entries response. Pass this to get the next page. | |
| expand | No | Include related objects in the response. 'collection' inlines the collection object, 'tags' inlines tag objects. Pass an array for both. | |
| period | No | Time granularity for date-based queries. Cannot be used with a view. If date is set, period controls its scope (day=single day, week=that week, etc). Defaults date to now if omitted. | |
| status | No | Filter by task status. Pass an array to match any. Works with view=inbox or without a view. Not valid with view=overdue. | |
| collection | No | Filter by collection ID. Pass an array to match any. Works with view=overdue or without a view. Not valid with view=inbox. Use list_collections to find IDs. |
| Name | Required | Description |
|---|---|---|
| cursor | Yes | |
| entries | Yes | |
| has_more | Yes |
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.
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.
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.
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.
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.
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.
List all tags (labels for categorizing entries). Returns IDs needed for filtering entries by tag.
| Name | Required | Description | Default |
|---|---|---|---|
| archived | No | Filter by archived status. true = only archived, false = only active, omit = all. |
| Name | Required | Description |
|---|---|---|
| tags | Yes |
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.
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.
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.
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.
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.
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.
Update an entry's title.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Entry ID (UUID) to update. | |
| title | Yes | New title (1-500 characters). |
| Name | Required | Description |
|---|---|---|
| entry | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.1create_entrydelete_entryget_collectionget_entryget_taglist_collectionslist_currentlist_entrieslist_tagsupdate_entryMost 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
MCP server for generating rough-draft project plans from natural-language prompts.
MCP server for Linear project management and issue tracking
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
