Skip to content

Resources and prompts

In addition to tools, the SC4S MCP server exposes two other MCP primitives:

  • Resources: read-only documents that the assistant (or the user) can request by URI. Resources are static content baked into the MCP container image; they do not touch SC4S or the host.
  • Prompts: pre-built workflows that seed a conversation with all the context needed for a specific task. Prompts do not execute code on their own; they just structure the conversation.

Resources

All resources use the sc4s:// URI scheme. They are assembled from the project’s markdown documentation at the time they are fetched, so they always match the docs that ship with the image you are running.

URI Contents
sc4s://docs/creating_parsers The full parser-creation guide: the index.md, filter_message.md, parse_message.md, and unit_tests.md chapters, concatenated. Use this to give the assistant the conventions it needs to write a correct parser.
sc4s://docs/troubleshooting The troubleshooting guide: startup/validation checks, logging resources, PCAP replay, and Splunk health checks, concatenated. Use this when diagnosing a problem.
sc4s://docs/vendor/{vendor} All markdown documentation for a given vendor under docs/sources/vendor/{vendor}/. Replace {vendor} with a directory name; the list is available from the list_vendors tool.

Resources are read-only by construction: they return text, nothing else. The server cannot use them to modify state.

Prompts

Prompts are ready-made workflows that include the relevant knowledge base and a set of diagnostic steps. Invoke them from your client’s prompt picker, most mcp clients should expose such menu.

Create parser workflow

Command: create_parser

Guided workflow for authoring a new SC4S syslog-ng parser from sample logs. The prompt loads the project’s parser-creation knowledge base and asks the assistant to follow those conventions exactly.

Parameters:

Name Description
vendor Vendor name (free text, for example cisco).
product Product name (free text, for example asa).
sample_logs One or more raw log lines to base the parser on.

Typical flow after invocation:

  1. The assistant reads the knowledge base and the sample logs.
  2. It calls list_vendor_parsers / get_parser to learn existing conventions for the same vendor (if any).
  3. It drafts a new .conf parser and the corresponding unit tests.
  4. With your approval, it uploads the parser via add_parser.

Troubleshoot SC4S workflow

Command: troubleshoot_sc4s

Guided workflow for diagnosing a live SC4S issue. The prompt loads the troubleshooting docs and asks the assistant to run the standard diagnostic sequence before making any changes.

Parameters:

Name Description
symptom Free-text description of what you are seeing (for example: “no Cisco ASA events in Splunk”).

Diagnostic steps seeded by the prompt:

  1. Call sc4s_health to check the instance status.
  2. Call get_env to review the current configuration.
  3. Call list_custom_parsers to list deployed custom parsers.
  4. Propose specific fixes.
  5. Apply configuration changes via set_env only after explaining the reasoning.

Combining tools, resources, and prompts

A typical interaction uses all three primitives together. For example, adding support for a new vendor might look like this:

  1. Invoke the create_parser prompt with vendor, product, and sample logs.
  2. The assistant pulls context from sc4s://docs/creating_parsers and calls read-only tools (list_vendors, list_vendor_parsers, get_parser) to inspect existing work.
  3. After you review the draft, the assistant calls add_parser to deploy it.
  4. If the SC4S management API rejects the parser, the change is rolled back automatically and the assistant iterates.

Throughout this flow the MCP server itself only reads files from its own container and makes HTTP calls to SC4S_API_URL. See Security model for details.