The Rules MCP Server provides coding agents with on-demand access to context-specific rules and best practices, primarily for tasks like writing tests.
Fetch Task-Specific Rules: Access guidelines for writing tests, authoring UI, or reviewing PRs.
Language-Specific Support: Currently supports Python and TypeScript with dedicated rules for each.
Contextual Delivery: Rules are dynamically fetched based on relevance to the current task, reducing distractions.
Tool Integration: Works seamlessly with Claude Code, Cursor, and Claude Desktop.
Centralized Best Practices: Eliminates the need for manually managing coding guidelines across different projects or IDEs.
Supports deployment of the MCP server on Netlify's platform, enabling hosting of rules and guidelines.
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., "@Rules MCP Server get rules for writing tests in python"
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.
An MCP server for all my rules, prompts, etc etc. Allows agents to call rules on demand.
There's no point filling 4 paragraphs of instructions for how to write tests if your current session isn't going to write a test.
Spiritually similar to Cursor's rules.
claude mcp add --transport http rules https://mcp.cianfrani.dev/mcp
{
"rules": {
"command": "npx",
"args": [
"mcp-remote",
"https://mcp.cianfrani.dev/mcp"
]
}
}Related MCP server: ContextualAgentRulesHub
Allows coding agents to lookup rules on demand within the context of their current task.
> write a test for @calc.py
⎿ Read calc.py (26 lines)
⏺ rules:get_rules_for_writing_tests (MCP)(language: "python")
⎿ - Before testing a protected method, ask "Can this logic be adequately tested through the public interface?". If yes, don't test the protected method directly.
If no, continue testing the protected method.
- Remember to write tests using the Arrange, Act, Assert pattern.
… +12 lines (ctrl+r to expand)
⏺ Write(test_calc.py)It's really annoying trying to carry all these little notes between projects/IDEs.
I don't want to have to manually invoke rules.
Clearly-defined tool descriptions allow the agent to fetch rules on demand, only if they appear to be relevant.
Patterns must be associated with a specific action. For example, "writing tests", "authoring UI", "reviewing a PR".
The agent ultimately decides if it's going to call the tool. Sometimes it does. Sometimes it doesn't.
get_rules_for_writing_tests
Use when: writing any type of test,
Inputs:
language (string)
get_rules_for_composing_ui
Use when: creating new frontend components
In Claude Code, invoke prompts as slash commands.
pr-review
Use when: you want feedback on a unit of work
/pr-review
See resources/pr-review.md for the full template.
Start the server
npm run devOpen MCP inspector
npm run inspect Use when: creating new frontend components, designing component APIs, structuring component hierarchies, implementing component interactions, or making styling decisions.
What it provides: Comprehensive guidelines for creating new UI components.
How to use: Invoke this tool at the START of any UI component work to retrieve user-specific UI patterns and preferences, then follow these guidelines throughout the component lifecycle.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions retrieving 'user-specific UI patterns and preferences' and following guidelines 'throughout the component lifecycle,' it doesn't describe what the guidelines contain, their format, whether they're prescriptive or advisory, or what happens if guidelines conflict. This leaves significant behavioral uncertainty.
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 well-structured with clear sections ('Use when:', 'What it provides:', 'How to use:'), uses bullet-like formatting, and every sentence adds value. It's appropriately sized for a zero-parameter tool that provides guidelines.
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 zero-parameter tool with no output schema and no annotations, the description provides good usage context but lacks details about what the guidelines contain, their format, or how they're applied. The description is complete enough for basic usage but leaves questions about the actual content and application of the guidelines.
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, and schema description coverage is 100%. The description appropriately doesn't discuss parameters since none exist. A baseline of 4 is appropriate for a zero-parameter tool where the schema fully documents this fact.
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 tool provides 'Comprehensive guidelines for creating new UI components' which specifies the resource (guidelines) and purpose (for UI component creation). However, it doesn't explicitly distinguish this from its sibling 'get_rules_for_writing_tests' beyond the 'UI components' vs 'writing tests' domain difference.
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 explicit usage guidance with 'Use when: creating new frontend components, designing component APIs, structuring component hierarchies, implementing component interactions, or making styling decisions' and 'How to use: Invoke this tool at the START of any UI component work...' This clearly indicates when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when: writing any type of test, modifying existing tests, reviewing test structure, or making decisions about test implementation.
What it provides: User-specific rules, patterns, and preferences for test composition including naming conventions, structure, assertions, mocking approaches, and coverage requirements.
How to use: ALWAYS invoke this tool BEFORE writing or modifying any test code to retrieve the current testing guidelines, then apply these rules throughout your implementation.
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | The programming language the test is written in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's behavior as retrieving user-specific rules and guidelines, which implies a read-only operation without side effects. However, it lacks details on potential limitations like rate limits, authentication needs, or error handling, leaving some behavioral aspects unclear.
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 well-structured and concise, using bullet-like sections ('Use when:', 'What it provides:', 'How to use:') to organize information efficiently. Each sentence adds value without redundancy, making it easy to scan and understand quickly.
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 tool's moderate complexity (1 parameter, no output schema, no annotations), the description is fairly complete. It explains the purpose, usage context, and behavioral intent. However, it could benefit from mentioning the output format or example return values, as there's no output schema to provide that information.
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 schema description coverage is 100%, with the parameter 'language' fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as explaining why the language parameter is needed or how it affects the output. Baseline score of 3 is appropriate since the schema handles the parameter documentation.
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 tool's purpose: retrieving user-specific rules, patterns, and preferences for test composition. It specifies the verb 'retrieve' and resource 'testing guidelines', making it understandable. However, it doesn't explicitly distinguish from its sibling 'get_rules_for_composing_ui', which appears to be for UI composition rules rather than test writing.
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 explicit usage guidelines: 'Use when: writing any type of test, modifying existing tests, reviewing test structure, or making decisions about test implementation' and 'ALWAYS invoke this tool BEFORE writing or modifying any test code'. It clearly defines when to use the tool and includes a strong directive on timing, though it doesn't mention alternatives or exclusions beyond the implied scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_rules_for_composing_uiget_rules_for_writing_testsThe two tools have clearly distinct purposes: one is for UI component composition and the other is for test writing. Their descriptions specify non-overlapping domains (frontend UI vs. testing), making misselection unlikely.
Both tools follow a consistent 'get_rules_for_verbing_noun' pattern with snake_case. This predictable naming scheme makes it easy to understand their function at a glance.
With only 2 tools, this server feels thin for a 'Rules MCP Server' that presumably handles various development guidelines. The scope implied by the server name suggests more rule categories (e.g., backend, documentation, deployment) would be expected.
The server covers only UI and testing rules, leaving significant gaps for other development domains like API design, database interactions, security practices, or deployment. This incomplete surface will likely cause agent failures when broader rule guidance is needed.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for AI agent profiles and smart notes. 60+ coding prompt packs with expert personas.
An MCP memory server. One memory your agents share — across models, devices and apps.
Remote MCP learning coach for coding agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/markacianfrani/mcp-pattern-language'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
