Onboard Context Matic

Onboarding: ContextMatic MCP

This skill delivers a guided, interactive tour of the context-matic MCP server. Follow every phase in order. Stop after each interaction point and wait for the user's reply before continuing.

Agent conduct rules — follow throughout the entire skill: - Never narrate the skill structure. Do not say phase names, step numbers, or anything that sounds like you are reading instructions (e.g., "In Phase 1 I will…", "Step 1a:", "As per the skill…"). Deliver the tour as a natural conversation. - Announce every tool call before making it. One short sentence is enough — tell the user what you are about to look up and why, then call the tool. Example: "Let me pull up the list of available APIs for your project language." This keeps the user informed and prevents silent, unexplained pauses.

Phase 0 — Opening statement and tool walkthrough

Begin with a brief, plain-language explanation of what the server does. Say it in your own words based on the following facts:

The context-matic MCP server solves a fundamental problem with AI-assisted coding: general models are trained on public code that is often outdated, incorrect, or missing entirely for newer SDK versions. This server acts as a live, version-aware grounding layer. Instead of the agent guessing at SDK usage from training data, it queries the server for the exact SDK models, endpoints, auth patterns, and runnable code samples that match the current API version and the project's programming language.

After explaining the problem the server solves, walk through each of the four tools as if introducing them to someone using the server for the first time. For each tool, explain:

• What it is — give it a memorable one-line description
• When you would use it — a concrete, relatable scenario
• What it gives back — the kind of output the user will see

Use the following facts as your source, but say it conversationally — do not present a raw table:

| Tool | What it does | When to use it | What you get back | |---|---|---|---| | fetch_api | Returns an exact match for an API key/identifier and language, or lists all APIs for a given language. The key is the machine-readable identifier returned by fetch_api (for example, paypal), not the human-readable display name (for example, "PayPal Server SDK"). | "What APIs can I use?" / Starting a new project / "Do you have the PayPal SDK?" | A named list of available APIs with short descriptions (full catalog), or one exact API match when you provide its identifier/key and language | | ask | Answers integration questions with version-accurate guidance and code samples | "How do I authenticate?", "Show me the quickstart", "What's the right way to do X?" | Step-by-step guidance and runnable code samples grounded in the actual SDK version | | model_search | Looks up an SDK model/object definition and its typed properties | "What fields does an Order have?", "Is this property required?" | The model's name, description, and a full typed property list (required vs. optional, nested types) | | endpoint_search | Looks up an endpoint method, its parameters, response type, and a runnable code sample | "Show me how to call createOrder", "What does getTrack return?" | Method signature, parameter types, response type, and a copy-paste-ready code sample |

End this section by telling the user that you'll demonstrate the four core discovery and integration tools live during the tour, starting with fetch_api right now. Make it clear that this tour is focused on those core ContextMatic server tools rather than every possible helper the broader workflow might use.

Phase 1 — Show available APIs

1a. Detect the project language

Before calling fetch_api, determine the project's primary language by inspecting workspace files:

• Look for package.json + .ts/.tsx files → typescript
• Look for *.csproj or *.sln → csharp
• Look for requirements.txt, pyproject.toml, or *.py → python
• Look for pom.xml or build.gradle → java
• Look for go.mod → go
• Look for Gemfile or *.rb → ruby
• Look for composer.json or *.php → php
• If no project files are found, silently fall back to typescript.

Store the detected language — you will pass it to every subsequent tool call.

1b. Fetch available APIs

Tell the user which language you detected and that you are fetching the available APIs — for example: "I can see this is a TypeScript project. Let me fetch the APIs available for TypeScript."

Call `fetch_api` with language = the detected language and key = "" so the tool returns the full list of available APIs.

Display the results as a formatted list, showing each API's name and a one-sentence summary of its description. Do not truncate or skip any entry.

Example display format (adapt to actual results):

Here are the APIs currently available through this server:

1. PayPal Server SDK   — Payments, orders, subscriptions, and vault via PayPal REST APIs.
2. Spotify Web API     — Music/podcast discovery, playback control, and library management.
....

Phase 2 — API selection (interaction)

Ask the user:

"Which of these APIs would you like to explore? Just say the name or the number."

Wait for the user's reply before continuing.

Store the chosen API's key value from the fetch_api response — you will pass it to all subsequent tool calls. Also note the API's name for use in explanatory text.

Phase 3 — Explain the chosen API

Before calling, say something like: "Great choice — let me get an overview of [API name] for you."

Call `ask` with:

• key = chosen API's key
• language = detected language
• query = "Give me a high-level overview of this API: what it does, what the main controllers or modules are, how authentication works, and what the first step to start using it is."

Present the response conversationally. Highlight:

• What the API can do (use cases)
• How authentication works (credentials, OAuth flows, etc.)
• The main SDK controllers or namespaces
• The NPM/pip/NuGet/etc. package name to install

Phase 4 — Integration in the project language (interaction)

Ask the user:

"Is there a specific part of the [API name] you want to learn how to use — for example, creating an order, searching tracks, or managing subscriptions? Or should I show you the complete integration quickstart?"

Wait for the user's reply.

Before calling, say something like: "On it — let me look that up." or "Sure, let me pull up the quickstart."

Call `ask` with:

• key = chosen API's key
• language = detected language
• query = the user's stated goal, or "Show me a complete integration quickstart: install the SDK, configure credentials, and make the first API call." if they asked for the full guide.

Present the response, including any code samples exactly as returned.

Phase 5 — Demonstrate model_search

Tell the user:

"Now let me show you how model_search works. This tool lets you look up any SDK model or object definition — its typed properties, which are required vs. optional, and what types they use. It works with partial, case-sensitive names."

Before calling, say something like: "Let me search for the `[model name]` model so you can see what the result looks like."

Pick a representative model from the chosen API (examples below) and call `model_search` with:

• key = the previously chosen API key (for example, paypal or spotify)
• language = the detected project language
• query = the representative model name you picked

Display the result, pointing out:

• The exact model name and its description
• A few interesting typed properties (highlight optional vs. required)