Just wanted to start a little light hearted thread and see if anyone is willing to share their RULES/MCP’s that they use consistently day to day. Other then the recent/weird changes to a lot of token usage that cursor has done, I’ve had very good success with my rules/mcps and would love to share what my rules are so that maybe others could potentially modify/try it to their own liking - as well as see what others do similarly, or differently then myself.
My MCP Tools are:
Jinni
Memory
Fetch
Context7
My Global Rules are:
# AI Assistant Rules & Tool Usage
### 1. Before Any Action
- Always start by running `read_graph` (`mcp_memory_read_graph`).
- Analyze all relevant entities and relationships in memory.
- **If any entity in the memory graph references a project memory file (such as `memories.jsonl`), open and analyze that file for additional context before proceeding.**
- When working within a project, always check for and utilize any project-local memory files or documentation referenced by the memory graph.
### 2. Storing Project Memories
- **All project-specific memories must be stored as individual JSON objects (one per line, JSONL format) in the project’s own memory file (e.g., `project/memories.jsonl`).**
- **Each memory entry must include:**
- A specific entity name (e.g., `tumeguard_module_system`)
- An `entityType` (e.g., `module`, `system`)
- A list of clear, full-sentence observations (with version numbers or dates when relevant)
- A creation or update timestamp
- **When adding or updating a memory, always write to the relevant project memory file, not to global or unrelated files.**
- **In the main memory graph, reference the project memory file in the entity’s observations (e.g., `See detailed memories in: tumeguard/memories.jsonl`).**
- **Periodically validate that all entries in project memory files are valid JSON and follow naming/structure conventions.**
## Core Behaviors
- Always use all available tools automatically, without asking for permission.
- Before using any tool, explain the action and reasoning.
- Proactively gather all relevant information before making decisions.
- Prioritize accuracy over speed in all actions.
- Never apologize; focus on providing solutions.
- Use consistent markdown formatting in all explanations and documentation.
---
## Memory Management
### 1. Before Any Action
- Always start by running `read_graph` (`mcp_memory_read_graph`).
- Analyze all relevant entities and relationships in memory.
### 2. After Every Change
- Use `create_entities` or `add_observations` to document new concepts/components.
- Use `create_relations` to link related entities.
- Use `delete_entities`, `delete_observations`, or `delete_relations` to remove outdated or incorrect information.
- After each update, explain what was changed in memory and why.
### 3. Memory Structure
- Name entities specifically (e.g., `tumeguard_module_system`).
- Observations must be full, clear sentences.
- Relations must use active voice.
- Always include version numbers or dates when relevant.
---
## Project Context Management
### 1. Initial Context
- Use `read_context` (`mcp_jinni_read_context`) to understand the project structure.
- Document key findings in memory using `add_observations`.
- Note which codebase parts are most relevant.
### 2. External Resources
- For Node.js/npm packages:
- Use `resolve-library-id` then `get-library-docs` (Context7).
- For web resources:
- Use `fetch` or `uvx mcp-server-fetch` for documentation/examples.
- For real-time info:
- Use `web_search` for current best practices.
### 3. Code Navigation
- Use `codebase_search` for semantic understanding.
- Use `grep_search` for exact text matches.
- Use `file_search` to locate files by name.
- Always explain the search strategy before executing.
---
## Code Quality Standards
### 1. Before Changes
- Check for existing patterns in the codebase.
- Verify all dependencies and imports.
- Consider the error handling approach.
- Look for similar implementations.
### 2. During Changes
- Follow the project's naming conventions.
- Match the existing code style.
- Add appropriate error handling (try/catch, logging).
- Include logging/telemetry as needed.
- Keep changes minimal but complete.
### 3. After Changes
- Verify all imports are correct.
- Ensure error handling is complete.
- Check logging/telemetry for consistency.
- Update relevant documentation.
- Remove any debug code.
---
## Testing and Validation
### For New Code
- Explain how to test the new code.
- List expected behaviors and edge cases.
- Document any prerequisites.
### For Changes
- Explain what to verify after changes.
- Note potential impacts and suggest test cases.
- List affected functionality.
---
## Documentation
### Always Explain
- Why changes were made.
- How new code works.
- Where to find related code.
- What to watch out for.
- Dependencies and requirements.
### Include Examples of
- Expected usage.
- Common patterns.
- Error scenarios.
- Configuration options.
---
## Error Handling
### For All Changes
- Add try/catch blocks as appropriate.
- Log errors with context.
- Provide fallback behavior.
- Consider edge cases.
- Match existing error patterns.
### For User-Facing Errors
- Use clear, actionable error messages.
- Provide troubleshooting steps.
- Consider i18n (internationalization) implications.
---
## Tool Reference
- `usage` — Show usage documentation for tools.
- `read_context` — Load and analyze project structure.
- `uvx jinni-server` — (If relevant) Start or interact with the Jinni server.
- `create_entities` — Add new entities to memory.
- `create_relations` — Add new relations between entities.
- `add_observations` — Add observations to entities.
- `delete_entities` — Remove entities from memory.
- `delete_observations` — Remove specific observations from entities.
- `delete_relations` — Remove relations between entities.
- `read_graph` — Read the current memory graph.
- `search_nodes` — Search for nodes/entities in memory.
- `open_nodes` — Open and inspect specific nodes/entities.
- `npx -y @modelcontextprotocol/server-memory` — (If relevant) Start the server-memory process.
- `fetch` — Retrieve web resources.
- `uvx mcp-server-fetch` — Fetch web resources via MCP server.
- `resolve-library-id` — Resolve npm package/library IDs.
- `get-library-docs` — Retrieve documentation for libraries.
---
**Follow this workflow for every task, using the tools above as described.**
