trilium-bolt

by mursilsayed

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.5.0
Disambiguation5/5
Each tool targets a distinct operation: search, retrieval, tree navigation, CRUD for notes, attribute deletion, backups, and revisions. While update_note and patch_note both modify content, their descriptions clearly separate full updates from targeted find-and-replace, preventing real ambiguity.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern (search_notes, get_note, create_note, delete_attribute, create_backup). The naming style is uniform and predictable across the entire tool set.
Tool Count5/5
With 10 tools, the server is well-scoped for a note management domain. Each tool covers a meaningful operation without unnecessary bloat or redundancy.
Completeness4/5
The core note lifecycle is fully covered with create, read, update, delete, search, and hierarchy traversal. However, attribute management is one-sided (only delete_attribute, with no create/update), and revisions can be created but not listed or retrieved, leaving minor lifecycle gaps.
Average 3.6/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on August 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 states the core action but does not disclose whether the note itself is modified, whether prior revisions are preserved or overwritten, what content the snapshot captures, or what the tool returns. For a mutation-type tool this is a meaningful 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?
A single 10-word sentence with the verb front-loaded and zero filler. Every word contributes meaning, and no structured content is redundantly repeated.
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 (1 documented parameter, no output schema, no annotations), so the description is adequate for basic selection. However, it omits what happens after the call — the return value and how revisions are later accessed (notably, no sibling tool for listing/retrieving revisions exists), which leaves some invocation uncertainty.
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 documents noteId as 'ID of the note to create a revision snapshot for,' which mirrors the tool description. The description adds only marginal meaning (implying the note must already exist to snapshot), so the baseline 3 applies.
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 (create) and resource ('revision snapshot of a note's current content'), which clearly distinguishes it from siblings like create_note and update_note. It is specific enough for an agent to understand the operation, though it does not explicitly contrast itself with the similarly-named create_backup sibling.
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 given on when to use this tool versus alternatives. An agent gets no hint about whether to snapshot before edits, how this relates to update_note/patch_note workflows, or what distinguishes a revision from create_backup. No conditions, exclusions, or alternatives are mentioned.
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 carries the full burden of behavioral disclosure. It states that the tool deletes a note but does not disclose permanence, cascading effects, auth requirements, or impact on related revisions/attributes.
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 one short, front-loaded sentence with no filler. Every word contributes to identifying the action and target resource.
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?
For a destructive operation with no annotations and no output schema, the description omits critical context such as whether deletion is permanent or reversible and what side effects occur. It is sufficient to identify the tool but not to fully inform a careful 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?
Schema description coverage is 100%, and the noteId parameter is already documented in the schema. The description adds no extra parameter meaning, so 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 a specific verb, 'Delete', and a clear resource, 'a note', within 'Trilium'. It distinguishes itself well from sibling tools like create_note, get_note, update_note, and delete_attribute.
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 guidance on when to use this tool versus alternatives, no prerequisites, and no mention of consequences. Usage is only implied by the tool name and minimal description.
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 must disclose behavioral traits on its own. It only says what the tool does, not how it behaves: no mention of result format, ordering, pagination behavior, or side effects. For a search tool, an agent would benefit from knowing whether results are full note objects or IDs, and whether search is case-insensitive or respects ACLs.
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 filler. Every word earns its place, and it efficiently communicates the core function without unnecessary detail.
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?
For a tool with no output schema and no annotations, the description is too sparse to be complete. It does not explain what the search results look like, which is critical for an agent integrating the tool. It also lacks any guidance on how this tool relates to sibling retrieval tools, leaving the agent to infer usage 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?
Schema description coverage is 100%, so the schema already thoroughly documents both parameters, including detailed query syntax examples. The description adds no extra meaning about the parameters beyond what the schema provides, 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 states a specific verb ('Search'), a resource ('notes in Trilium'), and the mechanism ('full-text search or attribute queries'). This clearly distinguishes it from sibling tools like get_note and get_note_tree, which are about retrieving specific notes rather than searching.
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 verb 'Search' and the resource 'notes' imply the tool is for finding notes, which gives basic context. However, it does not explicitly say when to use this tool versus get_note or other retrieval tools, nor does it mention any exclusions or alternatives. Usage is implied, not stated.
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 alone must disclose behavioral traits. It only says a backup is created and does not mention whether existing backups are overwritten, where the backup is stored, whether it is a long-running or blocking operation, or whether the operation is safe to repeat.
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 filler. It states the action and the target resource clearly and efficiently, earning its place.
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 and its one parameter is fully documented, but the description omits important surrounding context such as side effects, return behavior, and storage location. With no annotations or output schema, this leaves some gaps, though the tool is still minimally invocable.
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, backupName, is fully described in the schema as 'Name for the backup file', giving 100% schema description coverage. The description adds no extra parameter semantics, but the baseline of 3 is appropriate since the schema already documents what an agent needs.
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 'Create' with a clear resource: a backup of the Trilium database. It is easily distinguished from sibling tools like create_note or create_revision because those target individual notes rather than the whole database.
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 intended use is implied by the name and description — you call this when you want a database backup — but there is no explicit guidance about when to choose it over alternatives or whether it should be used before other operations. No sibling tool offers a directly competing backup action, so the lack of explicit exclusions is less harmful.
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 must carry the behavioral burden. It clearly indicates a read-only tree traversal, but it does not disclose behavior around invalid note IDs, whether returned items are full notes or just metadata, or how depth affects the result.
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 with no filler, and the core action is front-loaded. It is appropriately sized for a simple read operation and every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity with two optional, well-documented parameters and no output schema, so the description plus schema are largely sufficient. The main gap is the lack of explicit return-shape details, but this does not prevent correct selection and invocation.
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 documents both parameters completely, including defaults, minimum/maximum values, and root semantics. The description adds no parameter-level meaning beyond what the schema provides, so the baseline for high schema coverage applies.
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 action ('Get') and a clear resource ('children/hierarchy of a note'), making the tool's purpose immediately understandable. It is distinguishable from sibling tools like get_note (which presumably returns a single note) and search_notes, even though it does not name those alternatives explicitly.
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 the tool should be used when an agent needs the hierarchical children of a note, which is useful but not explicit. It offers no guidance about when not to use it or which sibling tool should be preferred for flat retrieval.
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 disclosing behavioral context. It mentions that content can be markdown or HTML, but does not disclose what the tool returns, whether permissions are required, or other side effects of creating a note. This is a significant gap for a mutation tool without any annotation coverage.
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. The core action is front-loaded and the content format detail is relevant and concise.
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 schema is detailed and fully describes the parameters, defaults, enums, and attributes, so the agent has enough to construct a valid call. However, without an output schema, the description should have indicated what the tool returns (e.g., created note ID) to support chaining with sibling tools. This missing return-value context prevents a higher score.
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 schema already documents all seven parameters. The description adds no new parameter-level meaning beyond restating that content can be markdown or HTML via contentFormat, which the schema also covers.
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 and resource: 'Create a new note in Trilium.' It clearly distinguishes this tool from siblings like update_note, patch_note, get_note, and delete_note by stating that it creates a new note.
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 communicates when to use the tool: when creating a new note. It does not explicitly state when not to use it or point to alternatives like update_note/patch_note for existing notes, so it stops short of the highest level of guidance.
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 burden of behavioral disclosure. It only restates that the tool deletes an attribute; it does not mention irreversibility, side effects on related notes, permissions, or what happens when the attribute does not exist. For a delete tool, this is a significant 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 focused sentence with no filler. It front-loads the action and identifies the target resource and selection method efficiently.
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 is adequate for a simple attribute deletion, and the schema covers parameters. However, with no annotations and no output schema, the description lacks important context such as whether the operation is permanent, whether it affects the note itself, or how it differs from delete_note behaviorally. This leaves the tool minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters clearly. The description adds the parenthetical '(label or relation)' which echoes the attributeType enum, but does not provide additional semantic detail 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 clearly states the verb 'Delete', the resource ('attribute (label or relation)'), and the scope ('from a note by name'). It distinguishes this operation from sibling tools like delete_note by specifying the attribute-level target rather than a note-level target.
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 tool to remove a label or relation from a note by its name. It does not explicitly discuss alternatives or exclusions, but the resource type is specific enough to avoid confusion with note deletion or note creation.
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 behavioral burden. It discloses content conversion behavior (markdown is converted to HTML before saving) and attribute upsert semantics ('If an attribute with the same type and name exists, its value will be updated; otherwise a new attribute is created'). It does not describe what happens to existing content/title if omitted (e.g., whether omitted fields are left unchanged), response format, or auth/error behavior.
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?
Two concise sentences with the key distinction (markdown/HTML) front-loaded. The attribute semantics are in the schema, so the description being short is appropriate. Slight redundancy: 'Content can be provided as markdown (default) or HTML' is somewhat repeated in contentFormat's schema description, but the description remains efficient.
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 an update tool with 5 params and no output schema, the description covers the core behavior and the markdown/HTML distinction but lacks behavioral edge cases: what happens if title/content is omitted (preserve or clear?), whether attributes are entirely replaced or merged per-attribute, and confirmation/return behavior. Sibling patch_note exists, and without distinguishing it, the completeness is only moderate.
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 modest value by confirming contentFormat's effect ('markdown (default) or HTML') but mostly restates the schema. It does not clarify whether title/content are optional independently when updating, which is a meaningful gap given noteId is the only required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Update a note's title and/or content') and distinguishes the tool from siblings like get_note and create_note. It also highlights the markdown/HTML content choice, making the tool's purpose unmistakable.
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 conveys when to use this tool versus alternatives like create_note or delete_note, and the sibling list includes patch_note for partial updates but no exclusions are stated. It could explicitly say 'use patch_note for partial attribute updates' but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals that text note content is converted to markdown, which is beyond the schema. But it does not disclose behavior when includeContent is false, error handling, or what metadata includes. This is a moderate disclosure level for a read operation.
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 redundant wording. The core purpose is front-loaded, and the markdown detail is a valuable, concise addition. Every sentence earns its place.
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 get-by-ID tool with two parameters and no output schema, the description provides enough context: what is returned, and that content is markdown. It does not explain edge cases like includeContent=false or error handling, but these are relatively minor for a read operation and the sibling set makes the scope clear.
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 schema already documents both parameters. The description adds a small amount of value by stating content is markdown, which relates to includeContent, but it does not meaningfully clarify the noteId format or the optional parameter's behavior.
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 clear action ('Get a note by ID') with a specific resource and mentions the returned data (content and metadata). It is distinct from sibling tools like search_notes or get_note_tree because it targets retrieval by exact ID.
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 this tool is for retrieving a note when the note ID is known, and the markdown note about content suggests processing use cases. However, it does not explicitly exclude alternatives or mention when search_notes might be more appropriate, so it falls short of full explicit guidance.
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 provided, the description carries the behavioral disclosure burden, and it does well by revealing a key operational rule: the call is rejected when the search text matches zero or multiple locations unless occurrence disambiguates. It also signals that only a piece is modified rather than the whole note. Minor omissions such as return value and persistence details are not stated, but the most important edge-case behavior is covered.
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 and well-structured: the first sentence states the operation and its advantage, the second states the critical matching and disambiguation rule. There is no filler, repetition, or unnecessary schema detail.
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 mutation tool with six parameters, the schema plus description gives enough information to invoke it correctly: required fields, regex behavior, content format, and ambiguity rejection are all clear. The main gap is the lack of an output schema or description of what a successful patch returns, but this is a minor omission for a tool whose primary action is a state change.
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 all six parameters already carry detailed meanings in the input schema. The description adds framing around search and occurrence but does not supply substantial new parameter-level semantics beyond what the schema already provides.
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 names a concrete operation ('find-and-replace') on a specific resource ('a note's content') and explicitly contrasts it with resending the whole note, which distinguishes it from the sibling update_note. The verb is specific and the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first sentence establishes the intended use case: make a targeted edit to one part of a note without replacing the entire note. This gives clear context for when patch_note is preferable to a full-update tool, though it does not explicitly name alternatives or exclusions.
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:

[![trilium-bolt MCP server](https://glama.ai/mcp/servers/mursilsayed/trilium-bolt/badges/card.svg)](https://glama.ai/mcp/servers/mursilsayed/trilium-bolt)

Score Badge

Copy to your README.md:

[![trilium-bolt MCP server](https://glama.ai/mcp/servers/mursilsayed/trilium-bolt/badges/score.svg)](https://glama.ai/mcp/servers/mursilsayed/trilium-bolt)

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/mursilsayed/trilium-bolt'

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