Bundled Notes MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a specific resource and action combination, with only minor overlap between update_entry and set_entry_state around pin state. Descriptions clearly distinguish attachment reference removal from account storage deletion.
Naming Consistency5/5
All tools share the bundled_ prefix and follow a consistent verb_noun structure, with the only exceptions being status and current_user which are intuitively named. No style mixing.
Tool Count2/5
At 33 tools, the set is substantial, exceeding the 25-tool threshold for appropriate scope. While each tool has a clear purpose, the number may overwhelm agents.
Completeness5/5
The surface covers the full lifecycle for bundles, entries, tags, templates, attachments, and Kanban configuration, with no obvious dead ends. The only minor gap is lack of template update or attachment download, but these are not critical.
Average 3.4/5 across 33 of 33 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI 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?
With annotations already declaring destructive and idempotent hints, the description adds minimal behavioral context. It doesn't mention the 'confirm' parameter or explain what 'partial' means in terms of field updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. However, it is under-specified and lacks structured detail that would help the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters with a nested spec object and no output schema, but the description is one sentence. No mention of confirmation requirements, parameter effects, or expected behavior, leaving the agent to infer from names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no parameter information. The 'spec' object, 'confirm', and 'global_tag' semantics are entirely unexplained.
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 clear verb ('update') and resource ('tag definition'), with scope ('local or global') that distinguishes it from create/delete/apply siblings. However, it omits the 'task' aspect from the title, making it slightly less precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create or delete. It only states the action, with no context or exclusions.
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?
Annotations already indicate this is not read-only and not idempotent, so the agent knows it's a mutating operation. However, the description adds no further transparency: it doesn't explain the confirm parameter (likely requiring user confirmation), the effect of default_bundle, or any side effects. For a non-read-only tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically simple sentence with no fluff, which is concise. However, given the tool has 4 parameters and nuanced behavior (confirm, default_bundle), the description is too sparse to be considered well-structured. It is efficiently short but not appropriately sized for the tool's complexity.
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 4 parameters, no output schema, and no annotation hints about behavior, this description is incomplete. It does not explain how confirmation works, what default_bundle affects, or what happens after creation. It provides only the core action without the contextual details needed for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters with 0% description coverage, and the tool description mentions none of them. It only hints at 'template' (template_id) but completely fails to explain name, confirm, and default_bundle. With such low coverage, the description was obligated to compensate, and it does not.
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 (create) and the resource (a new bundle) with a specific source (from a custom template). It distinguishes itself from sibling tools like bundled_create_bundle, which likely creates a bundle without a template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like bundled_create_bundle or bundled_duplicate_entry. It does not mention any prerequisites (e.g., the template must exist) or exclusions. The only implied context is that it's for creating bundles from custom templates, but no explicit when/when-not guidance is given.
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?
Annotations already indicate readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds only 'ordered tag IDs as columns,' which is more parameter-related than behavioral. It does not disclose what gets replaced or destroyed when reconfiguring, the role of the confirm parameter, or the effect of enabled=false. Minimal added context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It is concise and easy to parse, though the brevity sacrifices necessary detail for a configuration tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and seven parameters, the description is too sparse to provide complete context. It lacks information about return behavior, the effect of flags like confirm and enabled, and whether the board configuration is fully replaced or merged. The agent would need to infer much of the tool's behavior from parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that column_tag_ids are ordered and represent columns, adding meaning to one parameter. However, it leaves six other parameters (confirm, enabled, backlog_name, show_all_column, hide_backlog_if_empty) entirely unexplained, which is inadequate for a tool with several behavioral flags.
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 (Enable/configure) and resource (a board) with a key detail (ordered tag IDs as columns), which clearly distinguishes it from sibling tools like move_kanban_entry. It doesn't explicitly differentiate from update_bundle, but the kanban-specific wording makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are prerequisites (e.g., tags existing, bundle type) or workflow context mentioned. The description implies usage for kanban board setup but offers no exclusions or alternative recommendations.
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?
Annotations provide only basic flags (readOnlyHint false, idempotentHint false), leaving the description to disclose behavioral implications. The description only says 'Create a Markdown entry' and omits details about the confirm parameter, side effects, idempotency, or return values. It adds little beyond what the annotations already imply.
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 conveys the core purpose efficiently and earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested parameters and no output schema, yet the description does not explain what the tool returns, when confirmation is needed, or how the spec fields interact. This is insufficient for an agent to invoke the tool correctly beyond its basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters. The 'spec' object, 'confirm' flag, and 'bundle_id' are mentioned only in the schema; their semantics and relationships are undocumented. The description fails to compensate for the low coverage.
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 clearly states a specific action (create) and resource (Markdown entry in a bundle), which identifies its function. It is distinct from sibling tools like bundled_update_entry or bundled_duplicate_entry, though it does not explicitly contrast them.
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. There is no mention of exclusions, prerequisites, or situations where a sibling tool might be more appropriate, such as creating a template or bundle.
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?
The description aligns with destructiveHint and idempotentHint but omits critical behavioral details such as the role of the confirm parameter and potential side effects of moving an entry across columns. It adds only the null-to-backlog behavior, which is insufficient for a destructive tool with a confirmation flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, front-loaded with the action. However, it is so brief that it sacrifices essential operational details, making it structurally efficient but not fully helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and a confirm flag, yet the description is only one sentence. It fails to explain confirmation semantics, prerequisites like configured kanban columns, or what 'configured column' means, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It clarifies target_column_tag_id via 'configured column' and 'backlog with null,' but entry_id, bundle_id, and especially confirm are left completely unexplained.
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 'Move' with a clear object 'entry' and destination 'configured column' or 'backlog with null.' It clearly identifies the kanban scope, though it does not explicitly compare itself to sibling bundled_move_entry, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives or when not to use it. There is no mention of prerequisites like configured kanban columns, and the only hint (null for backlog) is parameter-specific rather than tool-selection advice.
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 description adds value beyond annotations by disclosing that the tool can execute 'completion/archive/swap actions' optionally, which gives context to the destructiveHint and idempotentHint. However, it does not elaborate on the nature or consequences of these actions, leaving the full behavioral impact vague. No contradiction with 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 of 14 words. It efficiently conveys the primary function and optional behavior without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and complex side effects. The description is insufficiently complete for an agent to understand prerequisite steps, parameter dependencies (e.g., when confirm is required), return values, or the detailed effects of apply_actions. It leaves significant gaps for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but only explains the apply_actions parameter implicitly via 'optionally execute its completion/archive/swap actions.' It completely omits the meaning or purpose of tag_id, entry_id, bundle_id, and confirm. The description provides minimal semantic value beyond the raw schema.
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 clearly states a specific action: 'Apply a tag; optionally execute its completion/archive/swap actions.' This distinguishes it from tag CRUD siblings like create_tag, update_tag, remove_tag, and delete_tag by implying attachment of an existing tag. However, it does not explicitly state what the tag is applied to (e.g., an entry), leaving some ambiguity for the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as bundled_remove_tag or bundled_update_tag. There is no mention of context, prerequisites, or when not to use it. The description only explains what it does, not when to choose it.
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 description is consistent with the annotations: it describes a write operation (readOnlyHint=false) and a destructive-capable update (destructiveHint=true). It adds a useful behavioral detail by stating 'partially update,' indicating that unspecified fields remain unchanged, which goes beyond what annotations provide. However, it does not disclose the role of the 'confirm' parameter or any destructive implications beyond the annotation, so it adds limited additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains no fluff. Every word contributes to understanding the tool's core function. It is appropriately sized for a simple update operation, though arguably too brief for the schema complexity.
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?
Given the tool's complexity—nested 'spec' object, a 'confirm' parameter, and destructive annotations—the description is insufficient. It does not explain what 'confirm' does, how partial updates handle nulls, or what the return value is (no output schema). Agents cannot reliably invoke this tool correctly without additional context, making the description incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It maps 'text' to title/content, 'tags' to tag_ids, and 'pin state' to pinned, but it does not explain the 'spec' nested structure or the 'confirm' parameter at all. The description gives a high-level overview of updatable fields but leaves critical parameters (especially confirm) undefined, which is a significant gap.
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 clearly states the tool's purpose: 'Partially update entry text, tags, or pin state.' It specifies the verb (update), resource (entry), and scope (text, tags, pin state), which distinguishes it from sibling tools like bundled_set_entry_state (which updates state) or bundled_delete_entry. However, it does not explicitly name alternatives, so it falls slightly short of a perfect score.
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 offers no guidance on when to use this tool versus alternatives, such as using bundled_set_entry_state for state changes or bundled_create_entry for creation. The phrase 'Partially update' implicitly suggests it is for partial modifications, but there are no explicit conditions, prerequisites, or exclusions. This leaves the agent to infer usage 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=false, destructiveHint=true, and idempotentHint=true, so the safety profile is covered. The description adds minimal behavioral context beyond 'remove one tag reference,' such as clarifying that only the reference is removed, not the tag. It does not mention the confirm parameter or potential side effects, but annotations carry much of the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is immediately action-oriented and easy to parse. It contains no filler and effectively captures the core function.
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?
Given the tool's complexity and the presence of a confirm parameter with no documentation, the description is incomplete. An agent would not know whether confirm must be set to true to execute the removal, nor what happens if the tag reference does not exist. The description and schema together leave out essential invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain any of the four parameters (tag_id, confirm, entry_id, bundle_id). The confirm parameter is particularly ambiguous—it is a boolean with a default, yet neither the description nor schema clarifies its purpose. The description adds no meaningful parameter-level information.
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 'Remove one tag reference from an entry,' which includes a specific verb ('remove'), a resource ('tag reference'), and a context ('from an entry'). It clearly distinguishes this from sibling tools like bundled_delete_tag (which likely deletes the tag definition) and bundled_apply_tag (which adds a reference).
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, nor does it mention exclusions or prerequisites. While the name and verb imply the use case, there is no explicit mention of related tools such as bundled_apply_tag or bundled_delete_tag, leaving the agent to infer the appropriate 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?
The description adds the behavioral requirement 'Requires confirm=true' and discloses the supported bundle types, which goes beyond the annotations (all false). However, it does not explain what happens if confirm is false, what the response looks like, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence, front-loaded with the core purpose and ending with a key requirement. No unnecessary words, though a bit more detail could be helpful without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested spec object and no output schema, but the description does not explain what a bundle is, what the spec fields mean, or how confirmation affects the operation. This is incomplete for an AI agent to invoke the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaning for 'confirm' and implicitly for 'template' via 'Notes, List, or Board', but leaves 'spec.name', 'spec.description', and 'spec.default_bundle' semantically unexplained, partially failing to compensate.
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 'Create' and the resource 'bundle', specifying the supported types 'Notes, List, or Board'. This distinguishes it from sibling tools like update, delete, or list bundles.
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 explicit guidance is given on when to use this tool versus alternatives. The mention of 'Requires confirm=true' is a precondition, not a selection guideline, and there are no exclusions or alternative tool names provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to restate safety. It adds useful information about the response contents, but no additional behavioral traits (e.g., error handling, auth) are disclosed.
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, front-loaded sentence that efficiently communicates the tool's purpose and return value without any redundant or extraneous text.
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 read-only get tool with strong annotations, the description covers the key output elements. There is no output schema, but for this simple case the description is adequate, though it omits potential edge-case behaviors like 'entry not found'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, leaving the description to compensate. However, the description does not explain bundle_id or entry_id beyond their names, which are already visible in the schema. No guidance on format, constraints, or relationships between the parameters is provided.
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 clearly states the tool fetches an entry and lists key contents (Markdown content, tag IDs, state, attachment metadata), distinguishing it from sibling tools like list_entries or get_bundle. However, it does not explicitly mention that it operates on a single entry by ID, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like bundled_list_entries or bundled_search_entries. The description implies the general purpose but does not state exclusions or prerequisite context (e.g., needing an entry_id).
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 indicate read-only and idempotent behavior. The description adds 'client-side' and 'local search semantics,' providing additional context, but lacks details on pagination, return format, or how filters interact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that front-loads the core purpose with no filler words. However, it is so brief that it sacrifices necessary details for full understanding.
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 five parameters and no output schema, the description is insufficient. It does not describe search behavior, result structure, or filter semantics, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to explain the purpose of query, limit, tag_id, bundle_id, and include_archived. It provides no parameter-level details, leaving users to infer semantics solely from parameter names.
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 identifies a search operation with 'Client-side text search' and scopes it to 'the web app's local title/content search semantics,' which distinguishes it from sibling list/get tools by indicating text-based 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 description implies usage for text search on titles/content, but it does not explicitly state when to use this tool versus alternatives like bundled_list_entries. No exclusions or alternative tool names are mentioned, leaving context inferred.
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 are all false (readOnly, openWorld, idempotent, destructive), so they provide little insight. The description does disclose the optional 'task actions' (completion, archive, tag-swap), which is useful behavioral context. However, it does not explain the impact of these actions on existing entries, nor does it mention the 'confirm' parameter that might gate destructive or irreversible changes.
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, tightly packed sentence. It front-loads the main purpose and lists the optional actions without extraneous words. Every phrase earns its place, making it highly concise.
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?
Given the nested spec object, three top-level parameters, and no output schema, the description is far from complete. It fails to clarify the distinction between creating a tag vs a task (despite the title saying 'Create Tag or Task'), does not explain the confirm parameter, and leaves the semantics of 'task actions' ambiguous. The tool's potential side effects on entries through swap_tag_ids, mark_complete, and archive_note are not adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears full responsibility. It indirectly hints at global_tag ('local/global') and the task-action booleans (mark_complete, archive_note, swap_tag_ids) via 'completion, archive, or tag-swap,' but it does not explicitly explain bundle_id, spec.name, color, default_tag, task, or confirm. The hints are insufficient to understand the full parameter semantics.
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 core purpose: 'Create a local/global tag' with optional 'completion, archive, or tag-swap task actions.' This uses a specific verb and resource, and the mention of 'local/global' plus 'task actions' helps distinguish it from sibling create tools like bundled_create_bundle or bundled_create_entry.
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 offers no guidance on when to use this tool versus alternatives. There are no exclusions or context cues, such as 'use this instead of applying an existing tag.' For example, it doesn't clarify when to choose this over bundled_apply_tag or bundled_create_tag variants.
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?
The description discloses that it copies local tags and optionally entries, but does not explain the 'confirm' parameter's behavior, potential side effects, or what creation entails. Annotations provide no safety signals (all false), so the description carries the full burden and falls short.
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 clear sentence that front-loads the action. It contains no filler and each word adds information.
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 mutation tool with no output schema and no positive annotation signals, the description does not explain the confirmation flow, return value, or any side effects. It covers the core purpose but leaves significant operational context unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains include_entries via 'optionally entries' and alludes to bundle_id and name, but leaves 'confirm' and 'description' unexplained. The confirm parameter's semantics are non-obvious and underexplained.
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 ('Create') and resource ('custom template'), and specifies the source ('from a bundle') and key behavior ('copying local tags and optionally entries'). This clearly distinguishes it from sibling tools like bundled_apply_template and bundled_create_bundle.
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 when to use the tool (when creating a template from a bundle) but provides no explicit guidance on when not to use it or how it compares to sibling tools. It lacks any mention of alternatives or prerequisites beyond the required bundle_id.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds valuable context by stating the delete is permanent and cascades to 'copied tags/entries'. This provides side-effect information beyond the structured 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 that directly conveys the core purpose and side effects. No wasted words or redundant information.
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?
Despite having annotations and a clear purpose, the description omits the confirm parameter's role, which is essential for a destructive tool. It also does not describe return values or error behavior, and the tool lacks an output schema. The description is incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0%; the description does not mention the required 'template_id' or the critical 'confirm' parameter. The agent is left without any explanation that 'confirm' must be set to actually delete, which is a significant gap for a destructive operation.
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 ('Permanently delete'), the target resource ('a custom template'), and adds a specific scope ('and its copied tags/entries'). This distinguishes it from sibling tools like create/list/apply templates and other delete tools.
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 on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or comparisons to sibling delete tools (e.g., bundled_delete_entry or bundled_delete_bundle). The usage context is only implied by the name and description.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context by clarifying that the operation does NOT delete contents, which nuances the destructive annotation. It also implies the action toggles an archived state, but does not detail side effects or confirmation requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core action and includes a key clarification. Every word adds value.
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?
While the tool is simple, the description omits the role of the 'confirm' parameter and does not explicitly map 'archived' to true/false states. With no output schema and no parameter docs, this leaves a noticeable gap for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters. 'archived' is only implied by the title, and 'confirm' is entirely unexplained. This leaves the agent without critical information about parameter meanings.
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 purpose: archiving or restoring a bundle, and explicitly distinguishes it from deletion ('without deleting its contents'). This differentiates it from sibling delete_bundle and update_bundle tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_bundle or delete_bundle. The description only states what it does, not the context or exclusions.
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 signal destructiveHint=true and idempotentHint=true. The description adds 'partially update' which conveys a merge-like behavior, but it does not explain the confirm parameter or potential side effects (e.g., irreversible changes). It neither contradicts nor substantially extends the annotations, leaving some behavioral context to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence that is front-loaded with the verb and object. Every word contributes to the core purpose, with no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested spec with over 20 fields, a confirmation flag, and no output schema. The description fails to provide enough context for safe and correct invocation—spec construction, confirmation semantics, or what happens on destructive actions. It is too sparse for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not explain any of the top-level parameters. The nested 'spec' object's many fields are unmentioned except for a vague high-level summary. Critically, the 'confirm' boolean (default false) is not clarified, and the format for partial updates is left entirely 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 clearly states the verb ('partially update') and the resource ('bundle'), specifying the scope via 'details, layout, sorting, or display settings.' This distinguishes it from sibling bundle operations like delete or set_archived and from updates to other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as set_bundle_archived, configure_kanban, or even create_bundle. The phrase 'partially update' implies a subset of bundle modification capabilities but does not explicitly contrast with other update operations or mention prerequisites or confirmation flows.
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 adds meaningful context beyond the annotations: "Permanently" conveys irreversibility, and "Account-storage files are not deleted" clarifies the scope of the deletion. These details complement the destructiveHint and idempotentHint annotations without contradicting them.
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 consists of two short, direct sentences that front-load the core action. Every word contributes to the meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation, the description covers the essential action and a key nuance (storage files not deleted), but it omits important context: the purpose of the confirm parameter, effects on attachments or references, and expected behavior if the entry does not exist. The annotations help, but the missing parameter semantics and lack of output schema leave gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must clarify parameter roles, but it does not explain bundle_id, entry_id, or confirm. The phrase "one entry" only trivially implies entry_id, and confirm remains entirely undocumented, leaving the agent without sufficient information to correctly set parameters.
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 with a specific verb and resource: "Permanently delete one entry." The additional clarification that "Account-storage files are not deleted" helps distinguish this from related deletion operations on attachments or account storage.
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 such as bundled_set_entry_state or bundled_delete_bundle. It simply describes the action without mentioning exclusions, prerequisites, or context that would help an agent decide between this and sibling 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?
The description goes beyond the annotations by disclosing that the tool refuses deletion by default if references exist. While annotations already indicate destructive and idempotent behavior, the description adds the safety default, which is valuable context for an agent deciding whether to invoke this tool. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the primary action and a key behavioral caveat. It wastes no words, but the terseness leaves significant information unpresented; a second sentence explaining the override parameters would improve completeness without harming conciseness.
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 tool with 5 parameters and no output schema, the description is critically incomplete. It covers only the default refusal behavior and leaves out parameter semantics, prerequisites, side effects, and guidance on handling references. The 0% schema coverage makes this gap even more severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters like 'confirm', 'global_tag', and 'allow_dangling_references'. The description only says 'by default refuses', which alludes to the need for flags but never names or explains any parameter. An agent has no way to know how to override the default or what 'dangling references' means without additional context.
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 ('Delete a tag') and adds a distinguishing behavioral detail ('By default refuses when entries or Kanban still reference it'). This separates it from sibling tools like bundled_remove_tag or bundled_apply_tag, which operate on tag associations rather than deleting the tag itself.
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 when to use the tool (when you want to delete a tag) and hints at a prerequisite (referencing entries/Kanban must be handled), but it does not explicitly mention alternatives or provide 'when not to use' guidance. The mention of the default refusal is a partial contextual cue, but no concrete exclusions or alternate tool names are given.
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 annotations already declare the tool to be read-only, idempotent, and non-destructive. The description adds minimal context by specifying the scope 'in one bundle', but it does not disclose behaviors such as default filtering of archived entries or pagination via the limit parameter.
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 precise sentence that immediately states the action and scope. No wasted words, and it is appropriately sized for a simple listing operation.
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?
Given there is no output schema, the description does not clarify what the response format looks like, nor does it explain how limit or include_archived affect the result. The purpose is clear, but behavioral depth is lacking for a tool with 3 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the three parameters (bundle_id, limit, include_archived). The agent must rely on parameter names and defaults in the schema; the description adds no explanatory value.
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 'List' and identifies the resource as 'notes/entries' with the scope 'in one bundle', which clearly distinguishes this from sibling tools like bundled_list_bundles or bundled_search_entries.
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 such as bundled_search_entries or bundled_get_entry. It only gives a terse statement of the operation, failing to mention exclusions or preferred contexts.
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 readOnly, idempotent, and non-destructive behavior. The description adds the scope of listing both local and subscribed global tags, which is useful, but it does not disclose other behavioral details like pagination, ordering, or what 'subscribed' precisely entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and object. Every word earns its place with no redundancy or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 parameters and good annotations, but the description lacks information about return format or how the include_global parameter modifies behavior. While not needed for simple use, the ambiguity around global tags and the lack of output schema leave some gaps for an agent deciding how to invoke it correctly.
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?
With 0% schema description coverage, the description carries the burden. It adds meaning by mentioning 'bundle-local' and 'global tags', but it does not clarify the role of the include_global parameter or how it controls the inclusion of global tags. The parameter names are self-explanatory, but the description does not fully compensate for the missing schema documentation.
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 clearly states a specific action ('List') and resource ('bundle tags'), and distinguishes between local and subscribed global tags. It is unambiguous and unique among sibling tools, but it does not explicitly differentiate itself from alternatives.
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 listing tags in a bundle context but does not explicitly state when to use this tool versus alternatives or any prerequisites. There is no 'when not to use' guidance, but the purpose is clear enough to infer typical 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?
The description adds a critical behavioral detail beyond annotations: the delete cascades to all entry and tag subdocuments, and 'permanently' reinforces irreversibility. This is valuable context not available from the annotations alone. The lack of confirm parameter explanation is a gap, but the description still meaningfully extends transparency.
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 or redundant information. Every word contributes to the core purpose, making it highly concise and well-structured.
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?
Despite clear purpose and good annotations, the description omits the role of the 'confirm' parameter, which is essential for a destructive operation. Without explaining whether confirmation is required or what happens when set to false, the description is not complete enough for reliable invocation. The cascade detail helps, but the missing confirm semantics is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no additional meaning for the parameters. The purpose of 'confirm' is completely unexplained—it is unclear whether it is a safety gate that must be true or merely a flag. bundle_id is somewhat implied by 'bundle', but the description fails to clarify the critical confirmation 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 uses a specific verb phrase 'Permanently delete' and clearly identifies the resource ('a bundle') and the full scope ('plus all entry and tag subdocuments'). This effectively distinguishes the tool from siblings like set_bundle_archived or update_bundle, which offer non-destructive or partial modifications.
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 word 'permanently' implies this tool is for final removal rather than archiving (e.g., set_bundle_archived), and the existence of a sibling archive tool provides context. However, there is no explicit guidance about when to use this tool versus alternatives, nor any prerequisites or exclusions.
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 discloses that the copy receives a new document and numeric ID, and that destination tags are explicit (not automatically inherited). This adds valuable behavioral context beyond the schema. However, it does not explain the 'confirm' parameter or other potential side effects, so it is not fully transparent.
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 only two sentences and is front-loaded with 'Copy an entry.' Every word earns its place, with no fluff or repetition. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal annotations, the description is incomplete for a 5-parameter tool. It omits the meaning of the 'confirm' parameter and the behavior when target_tag_ids is null. The core copy action is clear, but the overall context is insufficient for an agent to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters with 0% description coverage. The description only addresses target_tag_ids ('destination tags are explicit'); it does not explain source_bundle_id, target_bundle_id, entry_id, or confirm semantics. With no other guidance, the description fails to compensate for the missing schema descriptions.
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 begins with 'Copy an entry,' a specific verb-resource pair. It also clarifies that the copy gets a new document and numeric ID, which distinguishes this tool from a move or update. This is clear 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like bundled_create_entry or bundled_move_entry. However, 'Copy an entry' clearly implies duplication use cases, and the mention of new IDs provides context. There are no exclusions or alternative references, so usage guidance remains implied rather than explicit.
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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the 'user-created' scope, clarifying that system templates are not included. However, it does not disclose additional behavior like pagination or return format, which is acceptable given the strong 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 communicates the core purpose effectively and concisely.
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 read-only list tool with strong annotations and one optional parameter, the description is largely adequate. The lack of output schema means the agent won't know the structure of returned templates, but this is somewhat standard for a list operation and not a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (limit) with 0% description coverage, and the description does not mention or explain this parameter. The agent must infer its meaning from the name and default value (300), which is a clear gap in parameter documentation.
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 ('user-created bundle templates'), distinguishing it from sibling template operations like create/apply/delete. The title reinforces the purpose and leaves no ambiguity.
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 (when you need to see existing templates) but provides no explicit guidance on when to use this tool vs alternatives, such as distinguishing it from bundled_list_bundles or other list tools. No exclusions or alternative tool references are mentioned.
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 indicate a non-read-only operation. The description adds the 400 MiB size limit, which is useful, but does not disclose other behavioral traits like whether the attachment replaces an existing one, the confirmation flow via the 'confirm' parameter, or any side effects.
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. It front-loads the verb and resource, making it efficient and easy to scan.
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?
Given the tool has 4 parameters, no output schema, and relatively sparse annotations, the description is too minimal. It does not cover what happens after upload (e.g., return value), the purpose of the confirm parameter, or any potential destructive aspects, leaving the agent under-informed for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for the unnamed parameters. It vaguely aligns file_path with 'local file' and entry_id with 'entry', but does not explain bundle_id or the confirm parameter. The parameter names are somewhat self-explanatory, but the description adds little 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 specific action: uploading a local file to account storage and attaching it to an entry. It distinguishes itself from sibling attachment tools (e.g., list/remove/delete) by focusing on the upload+attach operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (uploading local files and attaching to entries) but does not explicitly state when to avoid using it or mention alternatives. Since there are no direct overlapping tools, the clarity is sufficient.
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, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds the archived-bundle filtering behavior, but does not disclose pagination behavior, response format, or default limits beyond the schema. This is moderate additional context.
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, direct sentence: 'List bundles, optionally including archived bundles.' It is concise, front-loaded with the action and resource, and contains no filler or 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 tool's simplicity and strong annotations, the description is largely adequate. It clearly states the core purpose and the key optional behavior. However, it omits any mention of the 'limit' parameter's effect on results and there is no output schema, leaving minor gaps about pagination and return details. Overall, it is sufficiently complete for a basic list operation.
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 0%, so the description must compensate. It explicitly explains 'include_archived' via 'optionally including archived bundles', but it does not mention 'limit'. While 'limit' is self-explanatory, the description does not fully carry the burden for all parameters, providing only partial compensation.
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: 'List bundles, optionally including archived bundles.' The verb 'List' and resource 'bundles' are specific, and the optional archived filter adds scope. This distinguishes it from sibling tools like bundled_list_templates or bundled_get_bundle.
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's use case by stating what it lists, but it does not explicitly mention when to prefer this over alternatives like bundled_get_bundle for a single bundle or bundled_set_bundle_archived for changing archive status. No exclusions or alternative tool references are provided.
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?
Annotations already declare destructive and idempotent hints. The description adds valuable details: the copy-verify-delete sequence and rollback on failure, which goes beyond the annotation flags. No contradiction.
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?
One sentence, 18 words, front-loaded with the action. Every word serves a purpose; no redundancy.
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 core behavior is explained but missing parameter semantics and return value details. Given no output schema and 5 parameters, the description is somewhat incomplete but adequate for a simple move operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only implies source and target via 'source' and 'destination' but doesn't explain the 'confirm' boolean or 'target_tag_ids'. The agent lacks critical info on how to correctly set parameters, especially whether confirm=true is required.
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 'Copy... delete' to describe a move operation, clearly distinguishing it from 'duplicate' (copy without delete) and 'delete' (delete without copy). It identifies the resource (entry) and the two bundles involved.
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 a move operation but doesn't explicitly state when to use this tool over alternatives like bundled_duplicate_entry or bundled_move_kanban_entry. No exclusions or alternative guidance provided.
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?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds value by specifying 'permanently delete' (irreversibility) and 'detach references first' (a prerequisite), plus what exactly is destroyed (catalog record and storage object). This goes beyond the annotations without contradicting them.
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, tightly packed sentence that efficiently conveys action, target, and prerequisite. No filler words or repetition; it earns 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 description covers the core destructive action and the detach-first prerequisite, but it omits how the confirm parameter works, what happens if references aren't detached, and any permission requirements. Given there is no output schema, the description could be more complete about the invocation flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter information. The attachment_id parameter is somewhat inferable from the tool name, but the confirm parameter's purpose is entirely unexplained, leaving the agent without critical guidance for safe invocation.
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: it permanently deletes the account catalog record and storage object. This distinguishes it from siblings like bundled_remove_attachment (which likely only detaches) and bundled_delete_entry (which deletes entries), making the resource and action 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 gives clear context: it is for permanent deletion and instructs to detach references first, implying a prerequisite workflow. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusion criteria.
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, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds that the tool returns presentation/Kanban settings, which is useful, but doesn't disclose additional behaviors like error handling or permissions. This aligns with the 3 baseline for read-only tools with good 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, concise sentence with no filler. It front-loads the verb 'Get' and immediately specifies the resource and scope.
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 tool with one parameter and no output schema, the description is sufficient. It states what is returned (the bundle plus presentation/Kanban settings), and the annotations cover the operational context. No further details are necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only indirectly references bundle_id by saying 'one bundle', without explaining the purpose or format of the parameter. Given the low coverage, this is a clear gap.
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 'Get', the resource 'bundle', and specifies that it also returns presentation/Kanban settings. This distinguishes it from sibling tools like bundled_list_bundles and bundled_get_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate context: use this tool when you need a single bundle's details including its presentation/Kanban settings. It doesn't explicitly name alternatives or exclusions, but the purpose is clear enough to guide selection.
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?
Annotations already indicate destructive and idempotent behavior. The description adds meaningful nuance by clarifying that the operation removes only the reference, not the actual file, which is valuable context not captured by annotations. However, it does not mention the confirm parameter or any side effects, so it falls short of fully disclosing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one succinct sentence, front-loaded with the verb 'Remove'. It conveys the core action and the key nuance ('keep the account-storage file') without any filler or repetition. Every word adds value.
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 core purpose is clearly conveyed, and the distinction from file deletion is valuable. However, the tool has four parameters, including a confirm flag whose behavior is not described, and there is no output schema. For a destructive operation, the missing confirmation flow is a significant gap, making the description only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly explains entry_id and attachment_id via the action, but bundle_id is left undefined, and the confirm parameter—critical for a destructive operation—is completely omitted. Without an explanation of confirm, an agent may invoke the tool incorrectly.
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 ('Remove an attachment reference') and the specific resource ('from an entry'), while the clause 'but keep the account-storage file' distinguishes this from deleting the file. The title 'Detach File from Entry' reinforces this purpose, making it unambiguous and well-differentiated from sibling tools like bundled_delete_account_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you want to detach an attachment from an entry but preserve the underlying file. It implicitly contrasts with deletion tools, though it does not explicitly name alternatives such as bundled_delete_account_attachment. The distinction is clear enough for an agent to infer usage, but lacks an explicit 'use this instead of...' statement.
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?
Annotations already cover safety (read-only, non-destructive, idempotent). The description adds useful behavioral context by stating 'without download tokens', implying outputs are metadata only, not content or URLs. This goes beyond annotation coverage without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that directly states the action and key limitation. There is no unnecessary information or repetition.
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 listing tool with one optional parameter and strong annotations, the description covers the essential purpose and a key behavioral constraint. However, without an output schema, it does not detail the exact metadata fields returned, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. Since the schema only provides the type and default, the description should have explained the purpose/behavior of 'limit' (e.g., max items returned, pagination). It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a clear resource ('account-level Files & Photos metadata'), and a key qualifier ('without download tokens'). This distinguishes it from sibling tools like upload/remove/delete and clarifies it is strictly a list operation.
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?
It provides clear context: this is for account-level files/photos metadata, not for downloading or mutation. However, it does not explicitly name alternative tools for when tokens are needed or for upload/delete operations, so it lacks explicit when-not 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?
Annotations already disclose mutation (readOnlyHint false), destructiveness (destructiveHint true), idempotence (idempotentHint true). The description adds the key behavioral guarantee 'never toggles blindly,' clarifying that values are set deterministically. This goes beyond the structured metadata, though it doesn't elaborate on the confirm parameter or specific destructive effects.
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?
One sentence, front-loaded with the action and scope, no filler. The key caveat ('never toggles blindly') is packed efficiently without 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?
For a mutation tool with destructive hints, the description plus annotations give a solid overview, but the confirm parameter's necessity/behavior is undocumented and there's no mention of return values or failure modes. This is a minor gap; the tool's core operation is clear enough for an AI to use it correctly in most cases.
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 0%, so the description must compensate. It clarifies the 'state' parameter by listing its valid values (archived, markedAsComplete, pinned), which is valuable. However, it leaves 'value' and especially 'confirm' unexplained; 'confirm' likely gates destructive actions but the description doesn't say. Partial compensation for the coverage gap.
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 ('Set') with explicit resource ('entry state') and enumerates the exact fields (archived, markedAsComplete, pinned). It clearly distinguishes from siblings like bundled_set_bundle_archived and bundled_update_entry by emphasizing 'explicitly' rather than toggling.
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 conveys when to use this tool (when you want to explicitly set one of three states) and implicitly warns against blind toggling. However, it does not name alternative tools or describe when not to use it (e.g., for other entry fields, prefer bundled_update_entry), stopping short of a full 5.
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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description carries a lower bar. It adds valuable behavioral context by disclosing that purchase and authentication tokens are always omitted, which is not apparent from the annotations alone. This helps the agent understand the response shape.
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. It front-loads the action ('Return a safe account projection') and adds a crucial caveat ('tokens are always omitted') without being verbose.
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 zero parameters, an output schema present, and clear annotations, the description fully covers the tool's role. It explains the key behavior (safe projection omitting sensitive tokens) and requires no further explanation of return values since the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is complete with no properties. The description has nothing to add regarding parameters, and for a zero-param tool this is fully adequate. The baseline for zero params is 4, and the clean handling earns a 5.
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 clear verb 'Return' and identifies the resource as an 'account projection'. The safety qualifier ('safe', tokens omitted) distinguishes it from sibling tools like bundled_status and bundled_get_bundle, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The intended context (fetching current user account info without sensitive tokens) is implied but not stated as a comparison against other tools. It would benefit from naming alternatives like bundled_status or noting this is the only user-account tool.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by explaining that validation happens via a 'real read', which is meaningful behavioral context beyond the annotations. It does not contradict the 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, well-structured sentence that communicates both the reporting and validation functions without any redundant information. It is concise and front-loaded with the primary purpose.
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 the tool has no parameters, a rich output schema, and strong annotations, the description covers all necessary operational context. It clearly specifies what the tool does and how it validates, which is complete for a simple status endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter detail to add. According to the rubric, 0 params earns a baseline of 4. The description accurately communicates that no input is needed to run this status check.
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 specific verbs 'Report' and 'validate' with a clear resource (configuration and Firebase refresh token). It clearly distinguishes itself from the many data-manipulation siblings by describing a status/diagnostic operation.
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 phrase 'validate the Firebase refresh token with a real read' gives clear context for when this tool is appropriate: as a health check or configuration verification. It does not explicitly name alternatives or exclusions, but the intended use case is evident.
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:

[![bundled-notes-mcp MCP server](https://glama.ai/mcp/servers/guipmilek/bundled-notes-mcp/badges/card.svg)](https://glama.ai/mcp/servers/guipmilek/bundled-notes-mcp)

Score Badge

Copy to your README.md:

[![bundled-notes-mcp MCP server](https://glama.ai/mcp/servers/guipmilek/bundled-notes-mcp/badges/score.svg)](https://glama.ai/mcp/servers/guipmilek/bundled-notes-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/guipmilek/bundled-notes-mcp'

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