Supports retrieval of the latest Gmail monitor summary via the read_monitor_summary tool, integrating email monitoring into the Claude context.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Claude Rules MCP Server search for skills about logging"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Related MCP server: Skills MCP Server
An MCP (Model Context Protocol) server that reads Claude Code skills and rules from the filesystem and exposes them as tools. Supports HTTP and stdio transports with optional token authentication and Cloudflare Tunnel for remote access.
Serves 484 skills with progressive disclosure (metadata first, full content on demand)
17 global rules accessible individually or concatenated
Project-level rule discovery across multiple repositories
Keyword search across all skills and rules
Monitor summary integration (Gmail and court monitors)
Token authentication for HTTP transport
Dual transport: HTTP for containers/web, stdio for Claude Desktop
Node.js 20+
npm 10+
Docker (for container deployment)
npm install claude-rules-mcpOr run directly without installing:
npx claude-rules-mcp initgit clone https://github.com/jeremykenedy/claude-rules-mcp-server.git
cd claude-rules-mcp-server
npm install
npm run buildRun the interactive setup wizard:
npx claude-rules-mcp initThe wizard walks through transport selection, paths, and token auth. It creates a .env file with your configuration.
Then start the server:
npx claude-rules-mcp runTool | Description |
| Returns the full skills manifest (names and descriptions, not file contents) |
| Lists all skills with optional keyword filter |
| Reads the full SKILL.md for a specific skill by name |
| Lists and reads reference files for a skill |
| Lists all 17 global rule names |
| Reads a specific global rule by name |
| Concatenates all 17 rule files into one response |
| Reads project-level CLAUDE.md and .claude/rules/ |
| Scans for projects with .claude/ directories |
| Keyword search across skill descriptions and rule contents |
| Reads the latest Gmail/court monitor summary |
Variable | Default | Description |
|
|
|
|
| HTTP port |
|
| Path to skills, rules, and manifest |
|
| Path to project directories |
| (none) | Token for HTTP authentication (recommended for remote) |
docker build -t claude-rules-mcp:latest .
docker run -d \
--name claude-rules-mcp \
--restart unless-stopped \
-p 3456:3456 \
-e TRANSPORT=http \
-e PORT=3456 \
-e CLAUDE_DATA_PATH=/data/.claude \
-e CLAUDE_PROJECTS_DIR=/data/sites \
-e MCP_SECRET=your-secret-token \
-v /path/to/.claude:/data/.claude:ro \
-v /path/to/sites:/data/sites:ro \
claude-rules-mcp:latestHealth check:
curl http://localhost:3456/healthAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"claude-rules": {
"command": "npx",
"args": ["-y", "claude-rules-mcp", "run"]
}
}
}For remote via SSH:
{
"mcpServers": {
"claude-rules": {
"command": "ssh",
"args": [
"user@your-server",
"cd /path/to/server && TRANSPORT=stdio node dist/index.js"
]
}
}
}Settings > Customize > Connectors > + > Add custom connector:
Name: Claude Rules
URL: https://your-domain.com/mcp?token=your-secret-token# Health check
curl http://localhost:3456/health
# Test with token
curl -X POST "http://localhost:3456/mcp?token=your-token" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0.0"}}}'This package is open-sourced software licensed under the MIT license.
Read the latest monitor summary (Gmail job/legal alerts + Oregon court case updates). Check this at the start of every conversation to see if there are new job leads, legal updates, or urgent items.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a read operation, but could mention if the data is cached or if it triggers any updates. Still clear enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loads purpose and usage, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and clear purpose, the description sufficiently covers what the tool does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so description needn't add param info. Baseline 4 is appropriate as description adds no extra param details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads the latest monitor summary, specifying content types (Gmail job/legal alerts, Oregon court case updates). It distinguishes from sibling tools which are all rules-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises checking at the start of every conversation to see new items, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads and concatenates ALL 17 global rule files into one response. Use this to load your complete global ruleset into context at once. For a single rule, use rules_get_global_rule instead.
Returns: All 17 rules concatenated with section headers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying the concatenation of 17 files, section headers in return, and the bulk nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the action and result, then provide usage guidance and return format. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, parameterless tool with rich annotations, the description fully covers purpose, usage, and return format. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline for 0 params is 4. Description adds no parameter info, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb (reads and concatenates), resource (all global rule files), and scope (all 17). It distinguishes from the sibling tool rules_get_global_rule by stating when to use that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (to load complete global ruleset) and when not (for a single rule, use rules_get_global_rule instead). Provides clear context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a specific global rule file by name from ~/.claude/rules/{name}.md.
Args:
rule_name (string): Rule name without .md (e.g. "php", "laravel", "conventions", "testing") Valid: artisan-commands, banners, commands, conventions, echo-broadcasting, horizon, laravel, license, livewire, package-standards, pest, php, readme, socialite, tailwind, testing, vibe-flow
Returns: Full rule file content.
| Name | Required | Description | Default |
|---|---|---|---|
| rule_name | Yes | Rule name without .md extension |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds the file path and return content, but does not offer significant behavioral context beyond what annotations provide. It is consistent and adds marginal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with Args and Returns sections, making it easy to parse. It is concise but includes necessary details like the list of valid values. Could be slightly tighter but is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter with full schema coverage, rich annotations, and no output schema, the description covers what the tool does, input format, valid values, and return type. It is complete for the tool's simplicity, though error handling is not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description expands on it by listing valid values and clarifying the naming convention (e.g., '.md' suffix omitted). It adds meaning beyond the schema by giving explicit examples and the path format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Reads a specific global rule file by name from ~/.claude/rules/{name}.md', specifying the verb (reads), resource (global rule file), and location. It effectively distinguishes from sibling tools like rules_list_global_rules and rules_get_global.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a comprehensive list of valid rule names, guiding correct input. It implicitly defines when to use this tool (when needing content of a specific rule) but does not explicitly state when not to use it or suggest alternatives like listing rules first. However, the list and context are helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full skills-manifest.json — names and descriptions for all 484 skills plus 17 global rule names. Use this first to discover what is available before fetching individual skills or rules. Returns structured JSON: { total_skills, total_rules, skills[], rules[] }
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds output structure details (total_skills, total_rules, skills[], rules[]), providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences with no wasted words. First sentence immediately states the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although no output schema is provided, the description fully explains the return structure. Given zero parameters and simple purpose, the description is complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so description does not need to explain parameters. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns the full skills-manifest.json with counts and lists. It distinguishes from siblings by advising to use it first before fetching individual items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this tool first to discover available skills and rules before fetching individual ones, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads CLAUDE.md and all .claude/rules/*.md files for a specific project.
Args:
project_name (string): Project folder name under ~/sites (e.g. "laravel-auth-modernized", "greenboard")
Returns: Project CLAUDE.md and all project-level rule files concatenated.
| Name | Required | Description | Default |
|---|---|---|---|
| project_name | Yes | Project folder name under ~/sites |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description reveals concrete behavior: it reads specific file paths and returns concatenated content. This adds value by specifying the exact sources and output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences total, front-loaded with the core purpose followed by a structured Args/Returns section. Every sentence contributes essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with no output schema, the description fully explains what files are read and how the result is returned. No gaps remain for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description essentially repeats the schema's parameter description ('Project folder name under ~/sites'). No additional meaning or usage hints are provided beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Reads' and clearly states the resource: 'CLAUDE.md and all .claude/rules/*.md files for a specific project.' This distinguishes it from sibling tools like rules_get_global or rules_get_skill, which target different rule scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While the sibling names suggest different contexts (global, skill, project), no direct guidance is provided, leaving the inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the full SKILL.md for a specific skill by name.
Args:
skill_name (string): Exact skill name (e.g. "vue-expert", "php-pro", "laravel-auth")
Returns: Full SKILL.md content.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_name | Yes | Exact skill name from the manifest |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, so the description's disclosure of returning full content adds value. There is no contradiction, and the behavioral traits are well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only two sentences plus an Args/Returns structure. Every word is necessary, and it front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description adequately covers what to provide and what to expect. It lacks details on error cases or edge conditions, but that is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema already describes the parameter. The description adds concrete examples ('vue-expert', 'php-pro') that clarify the expected format, enhancing the semantic understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reads the full SKILL.md') and the resource ('for a specific skill by name'). It distinguishes from sibling tools like rules_get_skill_references by specifying 'full SKILL.md content', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as rules_get_skill_references or rules_get_global. The description only states what the tool does, not the context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists or reads reference files for a specific skill. Many skills have 5-7 deep-dive reference docs in their references/ subdirectory.
Args:
skill_name (string): Exact skill name
filename (string, optional): Specific reference filename to read. If omitted, lists all references.
Returns: List of reference filenames, or full content of a specific reference file.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_name | Yes | Exact skill name | |
| filename | No | Specific reference file to read (e.g. 'composition-api.md') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's behavioral disclosure is light but sufficient. Adds value by explaining the two modes (list vs read) and typical reference count, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences plus Args/Returns section. Front-loaded with purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description covers return values (list of filenames or full content). Also provides typical reference count. Complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds significant meaning beyond the schema: it explains the conditional behavior (listing all if filename omitted, reading content if provided). Schema coverage is 100%, but the description enriches the semantics with usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Lists or reads reference files for a specific skill.' Distinguishes from sibling tools like rules_get_skill (which gets the skill itself) by specifying reference files and mentioning the references/ subdirectory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that 'many skills have 5-7 deep-dive reference docs,' implying this is for supplementary documentation. No explicit when-not-to-use or alternative tools, but the context is clear enough for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all 17 global rule names available in ~/.claude/rules/. Rules: artisan-commands, banners, commands, conventions, echo-broadcasting, horizon, laravel, license, livewire, package-standards, pest, php, readme, socialite, tailwind, testing, vibe-flow. Use rules_get_global_rule to read a specific rule.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint false, and idempotentHint true. The description adds behavioral context beyond annotations: the exact location (~/.claude/rules/), the fixed number of 17 rules, and enumerates them by name. No contradictions. Slight deduction because the list format is implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a bullet-like list. The first sentence states the core function and location; the second provides usage guidance. Every element is essential; no redundancy. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers what the agent needs: it lists the exact rules, explains the path, and directs to the parent tool for reading. It is complete for this simple listing task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which yields a baseline of 4 per guidelines. The description does not need to add parameter meaning since there are none. No additional parameter information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Lists all 17 global rule names' with the specific path and provides the full list, leaving no ambiguity about the resource and scope. It is clearly distinguished from sibling tools like rules_get_global_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit guidance: 'Use rules_get_global_rule to read a specific rule.' This tells the agent when to use the sibling tool instead. While it could also state when not to use this tool, the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scans the projects directory and lists all projects that have a .claude/ directory.
Returns: List of project names with Claude rules configured.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it scans a directory and lists results, but does not disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the action, the second clarifies the return value. It is concise, front-loaded, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is complete. It specifies what the tool does (scan for .claude/ directories) and what it returns (list of project names), leaving no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the input schema provides full coverage. The description naturally covers the lack of parameters by stating the action without needing further explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'scans the projects directory and lists all projects that have a .claude/ directory'. The verb 'lists' and resource 'projects with Claude rules' are specific and distinct from sibling tools like rules_list_global_rules and rules_list_skills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any restrictions. However, the simple functionality implies its use case, so it meets the minimum viable level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all 484 skills with names and descriptions, read from the manifest (fast — no filesystem scan). Optionally filter by category or keyword.
Args:
filter (string, optional): Filter by name or description keyword (case-insensitive)
Returns: Formatted skill list with descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional keyword to filter skill names/descriptions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds valuable context: it reads from manifest (fast, no filesystem scan) and returns formatted output with descriptions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences plus Args/Returns. It front-loads the main purpose, avoids fluff, and is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a brief return format. Annotations are rich. For a simple list tool with one optional param, it is sufficiently complete, though details like field names are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description says 'filter by category or keyword' but the schema only mentions keyword, causing a slight mismatch. Otherwise, it adds minimal extra beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists all 484 skills with names and descriptions' specifying verb (lists), resource (skills), and scope (all). It distinguishes from siblings like 'rules_get_skill' by indicating the listing nature and mentions speed advantage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering by category or keyword, giving clear context for use. It does not explicitly state when to avoid this tool, but given the simple list operation and sibling tools, the usage is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across skill descriptions (from manifest) and global rule file contents.
Args:
query (string): Search keyword or phrase
scope ("skills" | "rules" | "all"): Where to search (default: "all")
Returns: Matching skill names/descriptions and rule excerpts with line numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keyword or phrase | |
| scope | No | Search scope | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the tool as read-only, non-destructive, and idempotent. The description adds context about the return format (matching names, descriptions, rule excerpts with line numbers), enhancing transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose statement followed by an args section. No extraneous words, well-structured, and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the search target, parameters, and return format. With annotations providing safety traits and no output schema needed, the description is complete for the tool's complexity. The sibling tools context confirms this search tool is distinct.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds return info but does not provide additional semantics for the parameters beyond what the schema offers, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name and title clearly state the tool's purpose. The description provides a specific verb ('Keyword search') and resource ('skill descriptions and global rule file contents'), distinguishing it from sibling tools like rules_get_skill and rules_get_global that retrieve specific items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when searching across skills and rules, but does not explicitly state when to use this tool over alternatives. However, given the sibling tools are all retrieval/get operations, the search purpose is distinct and clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a clearly distinct operation: reading summaries, getting global rules (single or all), listing rules, skills, projects, getting skill references, and searching. No two tools have overlapping purposes.
All tools follow a consistent verb_noun pattern in snake_case, with a uniform 'rules_' prefix for most tools. The exception 'read_monitor_summary' still uses verb_noun, maintaining overall consistency.
11 tools is well-scoped for the server's domain (reading rules, skills, projects, monitor). Each tool provides a necessary distinct operation without redundancy.
The tool surface covers all read operations for rules, skills, projects, and monitor summaries, plus search and listing. While write operations are absent, the server's apparent purpose is read-only access, making it complete for that use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search, browse & read 340+ Claude Code marketing & SEO skills from any MCP client.
Claude Code / MCP skills for the dev pipeline: discover, spec, design, build, ship, operate.
Path-scoped team memories, rules and skills for Claude Code, Cursor, Codex and other MCP clients.
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jeremykenedy/claude-rules-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
