itz4blitz · February 14, 2025 00:10
diff --git a/.continuerules b/.continuerules
 # .continuerules

 # MCP-Specific Usage
 # This file defines project-specific rules for working with the Model Context Protocol (MCP)
 # in a TypeScript environment. These guidelines apply to both server and client implementations
 # using the @modelcontextprotocol/sdk library.

 # 1. Server Setup
 # - Always instantiate a McpServer or the low-level Server class from "@modelcontextprotocol/sdk".
 # - Provide descriptive name and version fields for the server.
 # - Use the StdioServerTransport or SSEServerTransport (or a custom transport) to handle message I/O.
 # - Register resources, tools, and prompts that match your application's use cases.
 # - Ensure you maintain MCP’s lifecycle requirements: respond to "initialize" before sending content.

 # 2. Resources
 # - Expose data through resources (think read-only operations).
 # - Use ResourceTemplate if you have dynamic parameters in your resource URIs.
 # - Return data in the correct MCP format (contents array with text or structured data).
 # - Avoid heavy computations or side effects in resources (use tools for that).

 # 3. Tools
 # - Use server.tool(...) to define an action that can have side effects or perform computation.
 # - Validate tool input arguments using zod schemas for safety.
 # - Return tool results in the "content" array with a "type" of "text", "json", or other supported content types.
 # - Mark responses as "isError" if an error occurs, so clients can handle them gracefully.

 # 4. Prompts
 # - Use server.prompt(...) to define a structured conversation template for LLM interactions.
 # - Keep prompts simple and reusable; pass any needed parameters via the prompt’s zod schema.

 # 5. Client Setup
 # - Use the Client class from "@modelcontextprotocol/sdk" to connect to an MCP server.
 # - Provide appropriate client capabilities (prompts, resources, tools, etc.) in the "capabilities" field.
 # - Respect the server’s capabilities; do not attempt features not supported by the server.
 # - Use StdioClientTransport or SSEClientTransport (or a custom transport) to communicate with the server.

 # 6. Lifecycle & Protocol
 # - Always handle the "initialize" request before sending or processing other requests (except ping/log).
 # - After receiving the server’s "initialize" response, send "notifications/initialized" to confirm readiness.
 # - On shutdown, close transports gracefully.

 # 7. Error Handling & Logging
 # - Handle JSON-RPC errors by returning an "error" field with appropriate codes and messages.
 # - Use logging capabilities (if supported) to report significant events or debug information.
 # - Validate input parameters with zod or similar libraries to return meaningful error messages.

 # 8. Security & Consent
 # - Only expose data and tools the user explicitly consents to share.
 # - Handle user input securely (e.g., sanitize SQL inputs if used).
 # - Keep user data private unless authorized.

 # 9. Code Quality
 # - Structure servers and clients with clear separation of concerns.
 # - Avoid leaking internal implementation details through the MCP interface.
 # - Write comprehensive tests (unit, integration) to verify server or client behavior.

 # 10. Updates & Compatibility
 # - Keep the @modelcontextprotocol/sdk library up to date.
 # - Follow the MCP spec for version negotiations and feature changes.
 # - Ensure you watch for new releases of the MCP specification and update accordingly.
	# .continuerules

	# MCP-Specific Usage
	# This file defines project-specific rules for working with the Model Context Protocol (MCP)
	# in a TypeScript environment. These guidelines apply to both server and client implementations
	# using the @modelcontextprotocol/sdk library.

	# 1. Server Setup
	# - Always instantiate a McpServer or the low-level Server class from "@modelcontextprotocol/sdk".
	# - Provide descriptive name and version fields for the server.
	# - Use the StdioServerTransport or SSEServerTransport (or a custom transport) to handle message I/O.
	# - Register resources, tools, and prompts that match your application's use cases.
	# - Ensure you maintain MCP’s lifecycle requirements: respond to "initialize" before sending content.

	# 2. Resources
	# - Expose data through resources (think read-only operations).
	# - Use ResourceTemplate if you have dynamic parameters in your resource URIs.
	# - Return data in the correct MCP format (contents array with text or structured data).
	# - Avoid heavy computations or side effects in resources (use tools for that).

	# 3. Tools
	# - Use server.tool(...) to define an action that can have side effects or perform computation.
	# - Validate tool input arguments using zod schemas for safety.
	# - Return tool results in the "content" array with a "type" of "text", "json", or other supported content types.
	# - Mark responses as "isError" if an error occurs, so clients can handle them gracefully.

	# 4. Prompts
	# - Use server.prompt(...) to define a structured conversation template for LLM interactions.
	# - Keep prompts simple and reusable; pass any needed parameters via the prompt’s zod schema.

	# 5. Client Setup
	# - Use the Client class from "@modelcontextprotocol/sdk" to connect to an MCP server.
	# - Provide appropriate client capabilities (prompts, resources, tools, etc.) in the "capabilities" field.
	# - Respect the server’s capabilities; do not attempt features not supported by the server.
	# - Use StdioClientTransport or SSEClientTransport (or a custom transport) to communicate with the server.

	# 6. Lifecycle & Protocol
	# - Always handle the "initialize" request before sending or processing other requests (except ping/log).
	# - After receiving the server’s "initialize" response, send "notifications/initialized" to confirm readiness.
	# - On shutdown, close transports gracefully.

	# 7. Error Handling & Logging
	# - Handle JSON-RPC errors by returning an "error" field with appropriate codes and messages.
	# - Use logging capabilities (if supported) to report significant events or debug information.
	# - Validate input parameters with zod or similar libraries to return meaningful error messages.

	# 8. Security & Consent
	# - Only expose data and tools the user explicitly consents to share.
	# - Handle user input securely (e.g., sanitize SQL inputs if used).
	# - Keep user data private unless authorized.

	# 9. Code Quality
	# - Structure servers and clients with clear separation of concerns.
	# - Avoid leaking internal implementation details through the MCP interface.
	# - Write comprehensive tests (unit, integration) to verify server or client behavior.

	# 10. Updates & Compatibility
	# - Keep the @modelcontextprotocol/sdk library up to date.
	# - Follow the MCP spec for version negotiations and feature changes.
	# - Ensure you watch for new releases of the MCP specification and update accordingly.
No results found