Rewrite static MCP resources to be actionable guides for LLM consumers

[data-douser]

Problem

The static MCP resources exposed by the server are currently only placeholder-quality content, providing little value to LLM clients consuming them. Now that PR #111 ensures the resources are actually available in VSIX deployments, the content needs to be rewritten for such MCP resources so that they are actually useful to the calling LLM.

Current resources

Resource	URI	Problem
Getting Started	codeql://learning/getting-started	Generic "what is CodeQL" blurb. Says nothing about the MCP server, its tools, its prompts, or how an LLM should interact with it. This should be the primary onboarding resource for any LLM client connecting to the server. This resource should also be renamed to server/overview instead of learning/getting-started.
Query Basics	codeql://learning/query-basics	A 15-line QL syntax snippet. Too thin to be useful — doesn't mention from/where/select semantics, @kind metadata, common QL patterns, or how to use the server's compilation and LSP tools together. This resource should also be renamed to server/queries instead of learning/query-basics.
Security Templates	codeql://templates/security	Contains exactly 2 examples (Go SQL injection, JS XSS). No guidance on how to adapt them, no coverage of other languages or vulnerability classes, and no reference to the TDD workflow the server supports.
Performance Patterns	codeql://patterns/performance	Two tiny examples ("efficient joins" and "early filtering") with no explanation. Missing: recursive predicate optimization, pragma[only_bind_into], pragma[noopt], cartesian product avoidance, monotonic aggregates, performance profiling via the server's profile_codeql_query tool, etc.

Additionally consider

• Registering ql-test-driven-development.md as a resource — This file already exists at server/src/resources/ql-test-driven-development.md and contains the most complete TDD workflow documentation, but it is not registered as an MCP resource. It should be exposed (e.g. as codeql://learning/test-driven-development). This resource should be be more an overview of the theory of why test-driven-development makes LLMs more effective at developing ql code that is both syntactically and semantically correct, where existing MCP-provided prompts (e.g. ql_tdd_basic, ql_tdd_advanced) are intended to be used by the calling LLM to prompt itself to actually implement the steps of a "basic" or "advanced" test-driven-development workflow for a given CodeQL query to be created or improved. The ql-test-driven-development.md resource should not replace such prompts but rather provide an overview of QL TDD theory, including the value of using printed AST data for test code, as a means of giving improved context and grounding validations to the calling LLM ... with cross-links to the ql_tdd_* prompts and related tools.
• Cross-linking resources with tool names and prompt names — Resources should mention specific tool names (e.g. codeql_query_compile, codeql_test_run) and prompt names (e.g. ql_tdd_basic, tools_query_workflow) so LLMs can discover and invoke them.
• Language-specific resources — The per-language AST and security resources (loaded from ql/ directory) are separate from this issue but may benefit from a similar quality review.

New resources

• server/prompts --> Resource to be kept up-to-date as an overview of "prompts" provided by the codeql-development-mcp-server. Similar to existing docs/ql-mcp/prompts.md repo doc.
• server/tools --> Resource to be kept up-to-date as an overview of the "tools" provided by the codeql-development-mcp-server. Similar to existing docs/ql-mcp/tools.md repo doc, though the codeql://server/tools resource must not mention "opt-in" / "monitoring" tools as these are disabled by default and won't be available to the calling LLM.

What "useful" looks like

These resources are consumed by LLMs via the MCP resources/read protocol. They should be written for that audience:

1. **getting-started / server/overview ** — An MCP server usage guide: what tools are available, what prompts exist, what workflows are supported, and how to orchestrate them. Think of it as the resource an LLM reads on first connection to orient itself. Should cross-reference the server's 38 default tools, 11 prompts, and the TDD workflow.

2. **query-basics / server/queries ** — A practical reference for writing CodeQL queries using the server's tools: metadata annotations (@kind, @id, @severity), the from/where/select structure, common QL idioms, how to compile and validate via the available tools, and how .qlref/.expected test files work.

3. security-templates — Actionable templates covering multiple languages and vulnerability classes. Each template should explain how to adapt it, reference the TDD workflow, and note which MCP tools to use for testing and validation. Cover at least: taint tracking, dataflow configurations, source/sink/sanitizer patterns.

4. performance-patterns — Don't make stuff up here. Don't assume you know CodeQL query performance. Keep this resource minimal while pointing to the existing explain-codeql-query prompt (e.g. server/src/prompts/explain-codeql-query.prompt.md) and, especially, the profile_codeql_query_from_logs tool -- which is the primary means of evaluating the actual performance of a syntactically valid CodeQL query for the purpose of debugging and/or improving the "performance" of the evaluated CodeQL query or queries, where improving "performance" may mean "improving the runtime evaluation efficiency of query so that it runs faster" and/or "improving the results (output) of the query so that it finds exactly, and only, the expected results". The performance-patterns resource should, however, copy/embed some of the pre-validated concepts / content from the codeql_action_log_performance_review prompt from advanced-security/codeql-development-template.

Context

• PR Embed MCP resource content at build time for VSIX compatibility #111 fixes the build-time embedding so resources are available in VSIX bundles.
• The server exposes 38 default tools, where opt-in / monitoring tools should not be mentioned in server resources.
• Resources are statically imported via esbuild text loader in server/src/lib/resources.ts.
• Language-specific resources are loaded at runtime from ql/ via server/src/resources/language-resources.ts.

Acceptance criteria

• Each of the static resources is rewritten with actionable, LLM-oriented content.
• Existing static resources are renamed as needed, with references to old names updated throughout the codebase.
• New static resources are created, as needed.
• New static resources are cross-referenced from existing resources, where appropriate.
• getting-started.md serves as the primary MCP server orientation guide.
• Resources cross-reference specific tool names and prompt names.
• ql-test-driven-development.md is registered as a browsable MCP resource.
• All existing tests pass (npm run build-and-test).
• Resource content is reviewed for accuracy against the current tool/prompt inventory.