@aiwerk/mcp-server-clawhub

Official

by AIWerk

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v0.1.4
Disambiguation5/5
Each tool targets a distinct operation on skills or their components (search, list, versions, file fetching, scanning, moderation, download, resolution by hash). No two tools have overlapping purposes, making it clear which tool to use for each task.
Naming Consistency5/5
All tools follow a consistent 'clawhub_verb_noun' pattern using snake_case (e.g., clawhub_search, clawhub_get_version). The naming is predictable and makes the action and target clear.
Tool Count4/5
With 10 tools, the set is well-scoped for a skill catalog API. It covers all essential operations without being overly sparse or bloated. Slightly higher than the ideal lower bound but still appropriate.
Completeness5/5
The tool set provides full coverage for searching, listing, retrieving details, versions, files, scan results, moderation info, and downloading skills. There are no obvious gaps given the read-only nature of the catalog; all necessary operations are present.
Average 3.4/5 across 10 of 10 tools scored. Lowest: 2.8/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
- 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?
No annotations are provided, so the description carries full burden. It only says 'Search skills' and lists parameters, but does not disclose any behavioral traits such as authentication needs, rate limits, side effects, or return format.
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 extremely concise: two sentences front-loading the purpose and listing parameters with no extraneous words. It earns its place efficiently.
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, no annotations, and sibling tools like clawhub_list_skills, the description is insufficient. It does not explain output format, pagination, or when to use this tool over alternatives.
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 add meaning. It names the parameters but does not explain their semantics (e.g., what 'highlightedOnly' or 'nonSuspiciousOnly' mean). The schema includes constraints like minLength and maximum, but these are not elaborated in the description.
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 'Search skills', specifying the verb and resource. It mentions the catalog but does not differentiate from sibling tools like clawhub_list_skills, which may confuse the agent about when to use search vs. list.
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 lists required and optional parameters but provides no guidance on when to use this tool versus alternatives, nor any context such as prerequisites or excluded scenarios.
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. The description does not disclose that the operation is read-only, idempotent, or any potential side effects. It only states what the tool returns but lacks behavioral context beyond that.
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 short sentences contain all essential information without any redundant or extraneous text. The description is front-loaded with the core purpose and required input.
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 the tool's simplicity (one parameter, no output schema), the description is adequate but minimal. It could mention read-only behavior or that the slug must come from a list, but overall it covers the basic operation.
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 coverage is 0%, and the description adds minimal meaning beyond the schema: it only says 'Required: slug'. It does not explain what the slug represents or how to obtain it, leaving agents without necessary parameter 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 it gets full details of a skill by slug, listing included fields (latestVersion, owner, moderation). The verb 'get' and resource 'skill' are specific, and it distinguishes from siblings like clawhub_search and clawhub_list_skills.
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 siblings. It does not mention that for searching or listing skills, other tools like clawhub_search or clawhub_list_skills are appropriate. The description only states the requirement of slug, which is obvious from the schema.
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 must disclose all behavioral traits. It mentions the response includes base64-encoded zip bytes and size, but omits critical details: whether the operation is destructive, authentication requirements, error handling (e.g., missing slug), and rate limits. Insufficient for safe agentic use.
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 concise sentences deliver key information without redundancy. Every word serves a purpose, making it 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?
For a simple download tool with three parameters and no output schema, the description covers the core purpose, required/optional parameters, and response format. It lacks error scenarios or further contextual cues, but is largely sufficient given low complexity.
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 0%, so description adds essential meaning. It specifies that 'slug' is required, and 'version' and 'tag' are optional with 'defaults to latest.' This clarifies default behavior not captured in schema. However, it does not define the semantics of 'version' vs 'tag' or any constraints.
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 'Download a skill as a zip archive,' specifying a concrete action and resource. It distinguishes from siblings by focusing on the full skill download rather than search or individual file retrieval, though it does not explicitly differentiate from tools like clawhub_get_file.
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?
Provides parameter guidance (required slug, optional version or tag with default) but gives no indication of when to use this tool versus alternatives like clawhub_get_skill or clawhub_get_file. Missing when-not-to-use or comparative 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?
Description mentions returns (matching version and latest version), implying a read operation. No annotations provided, so description bears full burden. Lacks explicit disclosure on side effects, auth requirements, or rate limits. Adequate but not thorough.
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?
Extremely concise with two sentences, no fluff. Purpose and return value are front-loaded. Efficient for an AI agent to parse.
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 simple operation (resolve by hash) and no output schema, description covers core functionality and return value. But missing error conditions, hash format details, or correlation with sibling tools. Somewhat complete but leaves gaps.
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 coverage is 0% as description adds no meaning beyond parameter names. 'Required: slug, hash' is redundant with schema. Does not explain what slug or hash represent, their format, or constraints. Fails to compensate for 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?
Clearly states the verb 'resolve' and resource 'a version of a skill by content hash'. Distinguishes from siblings like get_version by using hash instead of version ID. Also explains what it returns (matching version and latest version).
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 vs alternatives. Implies usage when hash is available, but does not mention when not to use or suggest alternatives like clawhub_get_version for version ID lookup.
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 for behavioral disclosure. It only states what data is retrieved, without mentioning any side effects, authentication needs, rate limits, or that it is a read-only operation.
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 that efficiently conveys the core purpose and required parameter. It is appropriately short and front-loaded, though it could optionally include additional context without becoming verbose.
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 tool with one required parameter and no output schema or annotations, the description provides an adequate overview of the return data (verdict, reasonCodes, evidence). However, it lacks detail on response structure or potential error conditions.
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 one parameter (slug) with minLength:1 but no description for it, yielding 0% schema description coverage. The description says 'Required: slug' but does not clarify what slug represents (e.g., skill ID or name) or its format, adding minimal semantics 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 it retrieves moderation details (verdict, reasonCodes, evidence) for a skill, requiring a slug. It uses a specific verb ('Get') and resource ('moderation details for a skill'), distinguishing it from sibling tools like get_skill or get_scan which serve different purposes.
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 indicates the requirement for 'slug', which is a necessary condition for use. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., clawhub_get_skill) or any 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?
No annotations provided, so description carries full burden. Only mentions 'Get' (read behavior) but does not disclose rate limits, auth needs, or potential side effects. Minimal disclosure.
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: first states purpose and return, second states requirements. No fluff, front-loaded with essential 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?
With no output schema, the description should detail return value more. Vague 'including files and security snapshot' is insufficient for an agent to fully understand output. Also lacks context about parameters beyond required status.
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 has 0% description coverage; description only restates that slug and version are required. Does not explain what 'slug' or 'version' refer to (e.g., skill slug? version string format?), failing to add semantic meaning.
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?
Clearly states the action (Get), resource (specific version of a skill), and what is included (files and security snapshot). Distinguishes from sibling tools like clawhub_list_versions or clawhub_get_skill.
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?
Explicitly lists required parameters (slug, version) implying prerequisites. While not explicitly stating when to use vs siblings, the action and resource are distinct, so agent can infer usage context.
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. It implies idempotence ('list') but does not explicitly state it is read-only or non-destructive. It also fails to explain pagination behavior despite the presence of a cursor parameter, leaving significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with one sentence and a clear list of parameters. It avoids unnecessary words, but could benefit from better structure (e.g., separating purpose and usage).
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 3 parameters and no output schema. The description omits crucial context such as return format, pagination mechanics, whether unpublished versions are included, and the nature of the slug parameter. For a list operation, these details are essential 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 coverage is 0%, so the description must compensate. It only lists parameter names and required/optional status without explaining their meanings (e.g., what 'slug' refers to, how 'limit' and 'cursor' control pagination). This adds minimal value over 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 'List all versions of a skill,' which specifies the verb (list) and resource (versions of a skill). This distinguishes it from sibling tools like clawhub_get_version (single version) and clawhub_list_skills (list of skills).
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 indicates required and optional parameters, establishing when to use the tool. However, it lacks explicit when-not-to-use or alternative tool recommendations, though the sibling tool names imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only mentions that the result is for a skill version and defaults to latest. It does not state that the operation is read-only, or describe permissions, rate limits, or 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 a bullet-like list of parameter requirements, achieving maximum conciseness with no wasted words.
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 the absence of annotations and output schema, the description covers identifying the resource and parameter rules. However, it lacks details about the return format or edge cases (e.g., no scan result found).
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 must compensate. It explains that slug is required, version or tag are optional, and defaults to latest. This adds basic semantics but does not deeply explain parameter formats or constraints.
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 explicitly states 'Get the security scan result for a skill version,' which clearly identifies the verb (get), resource (security scan result), and context (for a skill version). This effectively distinguishes it from sibling tools like clawhub_get_version or clawhub_get_moderation.
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 specifies required (slug) and optional (version, tag) parameters and notes the default for version or tag. However, it does not provide guidance on when to prefer this over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether it is read-only, rate limits, side effects, or auth requirements. It only describes the core function, leaving the agent without important safety or behavior 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 sentence with all key information front-loaded: the action, resource, and pagination method. It lists optional parameters concisely without extraneous words, earning its space.
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 lacks details about the response format (e.g., list of skills, presence of nextCursor) and does not mention error handling or rate limits. Given the absence of an output schema and annotations, the description alone is not fully complete for an agent to confidently invoke the tool, though it covers the basics.
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?
With 0% schema description coverage, the description adds meaning to all three parameters: notes that cursor comes from previous response.nextCursor and that nonSuspiciousOnly is a boolean filter. This compensates for the lack of schema descriptions, though it could be more detailed (e.g., default values).
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 'List skills in the catalog with cursor pagination', specifying the verb 'list' and the resource 'skills'. This distinguishes it from sibling tools like clawhub_search (search) and clawhub_get_skill (single item).
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 usage by mentioning optional parameters (limit, cursor, nonSuspiciousOnly) and how to obtain cursor from previous response.nextCursor. However, it does not explicitly state when to use this tool over alternatives like clawhub_search, though the distinction is implied.
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 burden. It mentions return type ('Returns the file as text') and optional parameters with defaults, but lacks details on error handling, permissions, or size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It is front-loaded with the core purpose and immediately lists required and optional parameters.
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 4 parameters (2 required), no output schema, and no annotations, the description is fairly complete. It explains what the tool returns (text) and default version behavior. Could mention file type or error scenarios, but overall adequate.
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?
With 0% schema description coverage, the description compensates by explaining the purpose of slug, path, and optional version/tag, including the default behavior of 'latest.' This adds significant meaning beyond the bare 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 'Fetch a single raw file from a skill package,' using a specific verb and resource. It distinguishes from siblings like clawhub_search or clawhub_get_skill by focusing on raw file retrieval.
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 lists required (slug, path) and optional parameters (version or tag) with default behavior, providing clear context. However, it does not explicitly state when not to use this tool or suggest alternative sibling tools.
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:

[![mcp-server-clawhub MCP server](https://glama.ai/mcp/servers/AIWerk/mcp-server-clawhub/badges/card.svg)](https://glama.ai/mcp/servers/AIWerk/mcp-server-clawhub)

Score Badge

Copy to your README.md:

[![mcp-server-clawhub MCP server](https://glama.ai/mcp/servers/AIWerk/mcp-server-clawhub/badges/score.svg)](https://glama.ai/mcp/servers/AIWerk/mcp-server-clawhub)

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/AIWerk/mcp-server-clawhub'

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