@lastbluetape/mcp-server

by vulkanr

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct resource and action: list, item, activity, upgrade. There is no overlap in purpose; an agent can clearly distinguish between creating a list, getting a list, listing items, adding items, updating items, changing status, flagging, viewing activity, and upgrading. No ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., create_list, list_items, set_item_status, upgrade_list). The verb is always placed first and is descriptive of the action, making the set predictable and easy to navigate for an agent.
Tool Count5/5
With 10 tools, the server is well-scoped for a punch list management system. Each tool addresses a core operation without bloat, covering list creation, retrieval, item management, status changes, flagging, activity logging, and upgrade. The count feels complete yet focused.
Completeness3/5
The tool surface covers most common operations for a punch list, but notable gaps exist: there is no tool to delete a list or delete an item, and no way to update list metadata (e.g., name, description). These missing delete and update operations could leave agents unable to complete certain workflows, such as removing outdated entries.
Average 3.5/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral semantics. It states 'Change' implying mutation, but offers no details on reversibility, permission requirements, side effects, or whether the change is logged. The description adds minimal behavioral insight beyond what the tool name already implies.
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 wastes no words. It immediately communicates the action and scope. Given that the schema and parameter names are self-explanatory, no additional structure or expansion is needed.
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 description only covers the most basic purpose. It omits usage guidelines, return behavior (no output schema), and how this tool fits alongside siblings like 'update_item'. For a simple mutation tool, more context about lifecycle and when to use this versus similar tools is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description ('to open, in_progress, or done') echoes the schema's enum for 'status' but adds no new meaning about the parameter relationships, mandatory order, or semantics of the IDs. It is acceptable but provides no added value over schema 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 action ('Change'), the resource ('punch list item status'), and the specific allowed values ('open, in_progress, or done'). This precisely defines the tool's function and distinguishes it from siblings like 'update_item' by focusing solely on status transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 siblings like 'update_item' or 'flag_item'. It lacks prerequisites, context about the punch list workflow, or any mention of typical scenarios. The agent is left without decision criteria for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing consequences (e.g., whether the flag is a toggle, permission requirements, or what happens if the item is already flagged). Minimal behavioral disclosure.
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?
Single sentence, 10 words, front-loaded with action. Concise and clear, though it could be slightly more informative without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean toggle tool with three required parameters and no output schema, the description is minimally adequate. It tells the action but lacks context about return values, side effects, or when to use it. Not fully complete given the possibility of confusion with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('flag or unflag') and the resource ('punch list item'). It distinguishes from sibling tools like update_item and set_item_status by focusing specifically on the toggle of attention status.
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. For example, it does not differentiate between flagging and setting a status or updating the item. No when-to-use or when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the bare action without covering return format, pagination, ordering, permissions, or whether all items (including closed/archived) are included. This is insufficient for a read operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It front-loads the action verb and object, making it immediately scannable and efficient.
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 no output schema and no annotations, so the description must compensate by explaining return behavior, scope, and constraints. It merely says 'list all items' without specifying what is returned (e.g., fields, pagination) or any filtering nuances, which is incomplete for an agent selecting among similar list-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter list_id is fully described in the schema ('The list ID'), giving 100% schema coverage. The description adds no additional parameter context, but since the schema already documents the parameter, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'List' with the resource 'items in a punch list', clearly distinguishing it from sibling tools that manage lists themselves (e.g., list_my_lists, get_list) or mutate items (e.g., add_item, update_item).
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 list_my_lists (lists lists) or get_list (retrieves a list). The description lacks any mention of preferred contexts, exclusions, or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'update' without explaining mutation semantics (e.g., whether partial updates are allowed, idempotency, required permissions, or error conditions). The description is too brief to provide adequate transparency.
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 sentence, which is efficient but overly brief. It sacrifices important details (like return value, prerequisites) for brevity. While it is not verbose, it could be more informative without being longer.
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 absence of an output schema and annotations, the description should provide more context about what happens after a successful update, error handling, or whether the item must exist. The 4-parameter complexity and lack of return value information make this description incomplete.
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 schema already describes all 4 parameters with 100% coverage. The description adds value by confirming that only 'title' and 'description' are updatable fields, while item_id and list_id serve as identifiers. The 'and/or' phrasing clarifies that either one or both fields can be updated, which is not explicit in 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 action ('Update') and the resource ('punch list item'), and specifies the fields ('title and/or description'). This distinguishes it from sibling tools like add_item (create) or set_item_status (status change), as it is specifically for updating text fields.
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. For example, it does not mention that to change an item's status one should use set_item_status, or that to add a new item one should use add_item. The description lacks any situational context or 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?
No annotations are provided, so the description must carry full weight. It confirms mutation ('create') and mentions return values, but lacks details on permissions, idempotency, error states, or constraints (e.g., duplicate titles). The behavior is adequately but not thoroughly 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?
The description is a single sentence that efficiently states the action and the key return outputs. No superfluous words; every piece of information earns its place. It is front-loaded with the primary action.
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?
With 4 parameters (2 required) and no output schema, the description partially compensates by listing three return elements. However, it does not detail the structure of 'list details' (e.g., whether an ID is returned) or mention error behavior. It is adequate but leaves some gaps for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-level meaning beyond what the schema already provides (e.g., no elaboration on what 'title' or 'creator_name' entail, or hints on how the optional description field affects 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 clearly states the verb 'create' and the resource 'punch list', and specifies what is returned (details, share token, shareable URL). It is distinct from sibling tools (no other create tool in the list), so the agent can easily identify its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, no exclusions, and no mention of context where another tool might be more appropriate. For example, it does not clarify that this should be used only when creating a new list, not for retrieving or modifying existing ones (though that is implicit).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Get the activity log' without revealing any behavioral traits such as read-only safety, return format, sorting, or pagination 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 a single direct sentence with no extraneous words. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no annotations and no output schema, the description provides minimal context. It lacks details about the return structure or behavior of the limit parameter, though the core purpose is clear enough for a basic getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a specific resource 'activity log for a punch list', clearly stating what the tool does. It distinguishes itself from sibling tools that manage lists/items rather than retrieving activity logs.
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?
There is no explicit guidance on when to use this tool versus alternatives. The usage is implied by the description but lacks any exclusions, prerequisites, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. While 'Get' implies a read-only operation without side effects, the description does not explicitly confirm idempotency, error behavior (e.g., missing list), or any rate limits. The statement is minimally acceptable but lacks depth expected for a tool with no annotation support.
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 conveys the core purpose without any filler. Every word contributes to clarity, and the structure is optimal for a tool with a simple interface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (one parameter, no output schema) and a straightforward purpose. The description covers the basic function but is vague about what 'details and stats' specifically include—no return structure or field details are hinted. Given the lack of an output schema, the description could be more complete by enumerating typical fields returned. However, for a simple retrieval tool, it is passable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (one parameter, list_id, with description 'The list ID'). The description adds no additional semantic meaning beyond what the schema already provides—it simply restates that the tool operates on a specific list. Per the rubric, this baseline 3 is appropriate when the schema already handles the parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('details and stats for a specific punch list'). It clearly distinguishes from sibling tools like list_my_lists (which presumably lists all lists) and list_items (which deals with items), making the tool's singular focus unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_my_lists for enumerating lists or get_activity for historical data. No exclusions or context about prerequisites (e.g., 'list must exist') are mentioned, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the main action and the side effect (cache refresh), which is good. However, it does not mention whether the operation is read-only on the underlying data, any rate limits, or what the output format is (e.g., array of objects). This leaves some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded with the primary purpose. No redundant words. Every sentence adds value. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a simple listing action, the description covers the core function and a notable side effect. However, without an output schema, it should describe the return format (e.g., list of objects with fields) to be fully self-contained. The side effect is useful but not enough to reach completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so the baseline is 3. The description adds no parameter information (none needed), but also does not elaborate on the input context beyond what is already clear from 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 action ('List all punch lists') and the resource scope ('linked to your API key'). It distinguishes from sibling tools like get_list (singular) and list_items (items within a list) by specifying the full collection. The side effect ('refreshes token cache') adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when not to use it, alternative tools, or prerequisites. The side effect about cache refresh is incidental but not a directive for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns the created item and list stats, including remaining capacity for free lists—a useful behavioral detail. However, it does not mention idempotency, error conditions, or side effects (e.g., does it fail if list is full?). No contradictions with annotations (none exist).
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 tight sentences with no wasted words. The first sentence front-loads the core purpose, and the second sentence adds valuable return information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the lack of an output schema, the description adequately explains the return value (item + stats + capacity info). However, it omits error conditions, authentication requirements, and prerequisites (e.g., list must exist). The mention of 'free lists' hints at a capacity limit, but the behavior when full is not described. Sibling 'upgrade_list' suggests a related concept, but cross-reference is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning to the parameters beyond what the schema already provides (e.g., 'list_id' is just 'The list ID'). No value is added by the description for parameter understanding.
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 ('Add') and resource ('item to a punch list'), clearly stating the action. It distinguishes from sibling tools like 'create_list' (which creates lists) and 'list_items' (which lists items), leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for adding items, but does not explicitly state when to use it versus alternatives like 'update_item' or 'flag_item'. No exclusions or context about prerequisites (e.g., list must exist) are provided, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses the one-time charge, the required env var, and the effect on limits. However, it does not mention whether the operation is reversible, what happens on failure, or if it is idempotent.
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?
Three brief sentences, each adding essential information: action & price, prerequisite, and effect. No wasted words; the description is well-front-loaded and easy to parse.
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 (single parameter, no output schema, no annotations), the description covers purpose, prerequisite, and effect. It could be more complete by mentioning the return value or error handling, but it is largely sufficient for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so the baseline is 3. The description adds no additional semantics for the list_id parameter beyond what the schema already provides, but it does add overall context about the upgrade's purpose.
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 ('Upgrade a punch list to Pro'), the resource (punch list), and the specific outcome (removes limits). It is distinct from all sibling tools, which handle CRUD and item management, not upgrades.
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 explicitly requires a Stripe payment method via environment variable, providing a clear prerequisite. It does not explicitly state when to avoid using the tool (e.g., if already Pro), but the context is sufficient for a single-purpose upgrade action.
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

@lastbluetape/mcp-server MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![@lastbluetape/mcp-server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/vulkanr/lastbluetape-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vulkanr/lastbluetape-mcp)

Score Badge

Copy to your README.md:

[![@lastbluetape/mcp-server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/vulkanr/lastbluetape-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vulkanr/lastbluetape-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/vulkanr/lastbluetape-mcp'

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