vibecheck

by mgd34msu

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Hybrid

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 phase of the workflow: joining a session, publishing/editing/acknowledging/reading plans, claiming/updating work, and querying status or history. Even the plan-focused tools are clearly separated by action (publish vs edit vs ack vs read), and work_claim vs work_update has no boundary ambiguity.
Naming Consistency5/5
All tool names use snake_case with consistent resource prefixes: project_, plan_, and work_. The verb suffixes (join, publish, edit, ack, read, claim, update, status, history) are clear and follow a predictable pattern throughout.
Tool Count5/5
Nine tools is well-scoped for a collaborative session and work-tracking server. Each tool earns its place, covering plan management, work claims, updates, and inspection without redundant or overlapping utilities.
Completeness4/5
The tool surface covers the core lifecycle well: join a session, publish/edit/read plans, acknowledge revisions, claim work, update work, view status, and inspect history. Minor gaps exist, such as no explicit project_leave or plan deletion, but these can be worked around using existing update/status mechanisms.
Average 3.2/5 across 9 of 9 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on September 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
Annotations already provide idempotentHint=true, readOnlyHint=false, and destructiveHint=false, so the description's job is to add context. It adds only that the tool returns a 'compact status with map recovery,' which is vague and does not clarify side effects, persistence, or authorization requirements. No contradiction with annotations, but the behavioral insight is minimal.
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 compact sentence with no filler. It front-loads the main action ('Join') and then mentions the return behavior. Some terms are cryptic ('map recovery'), but structurally it is efficient and avoids redundancy.
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?
This tool has a complex nested request object with seven required sub-fields, yet no output schema exists and the description does not explain most of these fields or the meaning of 'map recovery.' The lack of usage context, side-effect details, and parameter semantics leaves the definition incomplete for an agent to invoke it confidently.
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 coverage is 0%, so the description must compensate for the nested request object and its many required fields. The description only hints at two concepts: 'explicit session identity' (likely external_session_id) and 'optional parent' (likely parent_session_id). It does not explain required fields like repository, vendor, runtime, model, or request_id, nor optional fields like effort or take_over_from.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Join') and a resource ('session'), which gives some direction, but the meaning is vague: 'Join' could mean joining a project, a session, or a workspace. 'return compact status with map recovery' is jargon that is not explained and does not clearly distinguish this from sibling tools like work_claim or project_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?
There is no guidance on when to use this tool versus the sibling tools. The description implies a use case ('Join with explicit session identity') but does not mention alternatives, prerequisites, or exclusions. An agent cannot tell whether this is the right tool for session initialization, reconnection, or something else.
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 a non-read, idempotent, non-destructive operation. The description adds little beyond 'using its expected revision,' which hints at optimistic concurrency but does not explain what happens on a revision mismatch, whether the whole plan is replaced, or what other side effects publishing may have.
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 one short sentence with no filler and front-loads the core action. While it is terse, every word contributes meaning; it simply leaves important behavioral detail unstated.
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 nested, concurrency-sensitive publish operation with no output schema, this description is under-specified. An agent cannot determine the effect of calling it with an outdated expected_revision, whether tasks fully replace existing ones, or how the identifiers connect to a previously read plan.
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, but it only maps to two of the nested fields: 'complete task plan' hints at tasks, and 'expected revision' maps directly to expected_revision. The outer request object and fields like project_id, request_id, session_id, status, depends_on, and supersedes remain 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 names a specific action ('publish') and a clear resource ('the coordinator's complete task plan'). It also highlights the concurrency key, 'using its expected revision,' which helps distinguish this from sibling plan tools. It could be stronger by explicitly contrasting with plan_edit or plan_read, but the purpose is 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?
The description offers no guidance on when to use plan_publish versus plan_edit, plan_ack, or plan_read. It does not state prerequisites, such as first reading the current plan to obtain expected_revision, nor does it explain the failure behavior if the revision does not match.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, matching the 'Read' verb. The description adds a small behavioral detail: full mode includes all current records and the task map. However, it does not disclose behaviors like default limits, pagination, or the meaning of 'since' or 'known_plan_revision'.
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 sentence with no filler and is reasonably front-loaded. However, the phrasing 'compact current work' is slightly awkward and could be clearer, so it loses a point for structural clarity.
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 parameter object, abundant optional parameters, and absence of an output schema, the description is far too terse. It does not explain request construction, output shape, or the semantics of key parameters like since and known_plan_revision, leaving the agent under-informed for correct 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 must compensate. It adds some meaning for the 'full' concept and hints at 'task map' (likely include_map), but it does not explain the outer 'request' object or parameters like limit, since, task_ids, and known_plan_revision. This is insufficient for the schema's nested structure.
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 ('Read') and names a resource ('current work'), and distinguishes compact vs full outputs. It is clear about the tool's fundamental purpose, though it does not explicitly differentiate it from sibling tools like plan_read or work_history.
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 gives no guidance on when to use this tool versus alternatives. It only contrasts compact and full modes within the tool itself, leaving the agent to infer the appropriate context relative to plan_read, work_history, or project_join.
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 idempotentHint=true and readOnlyHint=false, covering the write-but-idempotent behavior. The description adds the nuance that recording is based on explicit observation, but it does not disclose side effects, duplicate handling, or what happens when the revision is already recorded.
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, front-loaded with the core verb and object, and every word carries meaning. There is no filler or redundant restatement of the tool name.
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 a nested input schema at 0% description coverage, an agent only learns the general intent. It cannot confidently fill project_id/request_id or understand the acknowledgment semantics beyond what the annotations imply, making the description under-specified 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?
Schema description coverage is 0%, so the description must compensate. It maps 'session' to session_id and 'plan revision' to plan_revision, but leaves project_id and request_id entirely unaddressed. For a nested required object with four fields, this is insufficient for an agent to confidently construct the request.
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 ('Record') and resource ('plan revision'), with the scope 'this session explicitly observed'. This distinguishes it from obvious siblings: plan_read reads, plan_edit/plan_publish modify or publish, while plan_ack records an observation. However, it doesn't explicitly name the distinction with siblings.
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 phrase 'this session explicitly observed' implies the appropriate trigger: use when the current session has actually observed a plan revision. It does not name alternative tools or state when not to use it, leaving the agent to infer based on sibling names and general context.
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 establish that the tool is mutating, idempotent, and non-destructive. The description adds meaningful behavioral context by stating atomicity and the expected-revision concurrency control. It does not describe failure behavior on revision mismatch, but the core safety profile is already covered by 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 sentence with the core operation front-loaded and no filler. It communicates atomicity, the action, the resource, and the concurrency expectation efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex nested mutation tool, the description lacks explicit guidance on when to invoke it instead of plan_publish or plan_ack, and what happens if expected_revision is stale. However, the rich input schema and idempotent/non-destructive annotations cover much of the invocation detail, so the gaps are meaningful but not catastrophic.
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 carries the burden of explaining parameters, but it only clarifies expected_revision and the general add/update operation. It does not explain project_id, request_id, session_id, or the task field semantics beyond what the schema constraints already show. Most parameter meaning must be derived from names and schema structure.
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 identifies the operation (atomically add or update plan tasks) and the key constraint (coordinator's expected revision). It is specific about the resource and action, but it does not explicitly distinguish itself from sibling tools such as plan_publish or plan_ack beyond the 'edit' in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like plan_publish, plan_ack, or plan_read. The description does not mention prerequisites, the role of the session, or what to do if the expected revision does not match. The agent must infer usage context from the schema and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a read-only operation, and the description confirms this with 'Read'. No additional behavioral details (e.g., side effects, rate limits) are provided, but the annotation covers the key aspect.
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 that conveys the core functionality and a key alternative without any redundant or tangential 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?
The description does not explain what a 'plan revision' is, what the return value looks like (no output schema), or the default behavior when 'revision' is omitted. It also leaves the 'compare_to' parameter undefined. This lack of context may cause an agent to misuse the 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?
The schema has a nested 'request' object with project_id, revision, and compare_to, but the description provides no explanation of these parameters. The only mention is 'compare_to' in a usage context, but its semantics (e.g., what values it accepts, what it does) are undefined. Schema coverage is 0%, and the description does not 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 tool reads a complete plan revision, and explicitly mentions the compare_to option for differences. It uses a specific verb and resource, making the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use compare_to instead of reading the full plan, though it doesn't explicitly contrast with sibling tools. The guidance is implicit but useful for selecting the appropriate invocation.
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 state readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds a meaningful behavioral detail: it performs a revision check, implying the operation validates expected_revision and likely fails if the revision doesn't match. 'Record a delegated contribution' also suggests it can create a work record on behalf of someone, adding nuance beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads both core actions and the revision-check behavior. No filler, but the dual-purpose wording ('claim' or 'record delegated contribution') creates slight ambiguity that could have been unpacked in a second sentence.
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 a nested request object with seven fields, no output schema, and no per-parameter documentation; the description gives only a high-level purpose. It is adequate for an agent to guess the main intent, but missing details about location, parent_work_id, replace_work_id, and what the response returns make it incomplete for correct 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 description coverage is 0%, so the description should compensate. It only clarifies expected_revision ('revision check') and hints at the request object's purpose. The nested request object and fields like location, parent_work_id, replace_work_id remain unexplained, so the description does not fully compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Claim task ownership or record a delegated contribution with a revision check' — it names a verb and resource, but it's ambiguous whether this is two separate operations (claim vs. delegate) in one tool. Among siblings like work_update and work_history, it does not clearly distinguish when one would claim versus update work.
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 'with a revision check' implies expected_revision is used for optimistic concurrency, signaling when to use it versus work_update. However, it doesn't explicitly state when to use this tool over siblings like work_update or plan_ack, or what conditions make claiming appropriate.
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 atomicity trait, which is genuinely useful beyond the annotations. However, it does not disclose the optimistic-concurrency behavior implied by the required expected_revision field or what happens on mismatch, which is important for a mutating work-state tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes to defining the tool's core behavior and scope.
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 a highly nested schema and no output schema, the description only covers the top-level purpose. It omits guidance on the update variants, required concurrency fields, failure behavior, and return value, making it insufficient for fully self-sufficient tool 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%, and the description provides no parameter-level meaning. It gestures at the action variants, but it does not explain request, updates, work_id, expected_revision, status, or the location object, so it leaves the schema to carry all semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (work) and three concrete actions: report progress, release work, and hand work to another session. This clearly distinguishes it from sibling tools like work_claim, which has a different purpose.
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 clear usage context: use this tool when updating work state, releasing it, or handing it off. It does not explicitly name alternatives or exclusions, but the action verbs make the appropriate use case reasonably obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description is consistent with that. The description adds that the tool searches by identifiers, but it does not disclose return format, ordering, or pagination behavior beyond what the schema parameters 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 entire description is one front-loaded sentence that states the operation, resource, and key filters without filler. It earns its place and adds value without repeating schema details verbosely.
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 read-only search tool with a nested schema, the description plus annotations and structured schema constraints are largely sufficient for an agent to select and invoke it. The absence of an output schema is partially mitigated by the phrase 'recorded work and its history,' though more explicit return-value detail would improve 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?
With 0% schema description coverage, the description partially compensates by naming task, session, path, branch, and commit as filter dimensions. However, it omits the required project_id and the after/limit pagination controls, leaving those semantics 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?
States a specific action ('Find') on a clear resource ('recorded work and its history') and enumerates the search dimensions. This differentiates it from sibling tools like work_update and work_claim, which imply mutation rather than retrieval.
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 use when historical work records are needed, but it does not explicitly name alternatives or state when not to use this tool. Usage context is present but left to inference rather than being directly stated.
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

vibecheck MCP server – quality and maintenance score on Glama

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![vibecheck MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/mgd34msu/vibecheck/badges/score.svg)](https://glama.ai/mcp/servers/mgd34msu/vibecheck)