Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new ContextMatic plugin to Awesome Copilot, providing an MCP server configuration plus two skills (onboarding + integration) and registering the plugin/skills in the repository’s generated docs and marketplace metadata.
Changes:
- Introduces two new skills:
/integrate-context-maticand/onboard-context-matic. - Adds a new
plugins/context-matic/plugin with README, MCP server config, and plugin metadata. - Updates skills/plugins indices and marketplace listing to include the new additions.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| skills/onboard-context-matic/SKILL.md | New interactive onboarding/tour skill for the ContextMatic MCP server. |
| skills/integrate-context-matic/SKILL.md | New workflow skill intended to guide end-to-end third-party API integration via ContextMatic tools. |
| plugins/context-matic/README.md | Plugin documentation describing tools, supported APIs, and usage examples. |
| plugins/context-matic/.mcp.json | MCP server registration/config for the plugin. |
| plugins/context-matic/.github/plugin/plugin.json | Plugin metadata (name/description/version/keywords/skill references). |
| docs/README.skills.md | Adds the two new skills to the skills index table. |
| docs/README.plugins.md | Adds the new plugin to the plugins index table. |
| .github/plugin/marketplace.json | Registers the plugin in the marketplace list used by tooling/CI. |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…c/awesome-copilot into add-context-matic-plugin
🔍 Skill Validator Results3 resource(s) checked | ✅ All checks passed Full output |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
| "email": "developer@apimatic.io" | ||
| }, | ||
| "homepage": "https://www.apimatic.io", | ||
| "repository": "https://github.com/apimatic/context-matic", |
There was a problem hiding this comment.
For consistency with other local plugins (and the plugin.json example in CONTRIBUTING.md), the repository field should point to this repo (https://github.com/github/awesome-copilot). The upstream project link is already covered in the plugin README’s “Source” section, so keeping repository as Awesome Copilot avoids confusing “where this plugin lives” vs “upstream inspiration.”
| "repository": "https://github.com/apimatic/context-matic", | |
| "repository": "https://github.com/github/awesome-copilot", |
| # ContextMatic Plugin | ||
|
|
||
| Coding agents hallucinate APIs. APIMatic Context gives them curated, versioned API and SDK docs. | ||
|
|
||
| When a developer asks their agent to "integrate the payments API," it normally guesses, pulling from outdated training data or generic patterns that don't match the actual SDK. ContextMatic solves this by giving the agent authoritative, version-aware, SDK-native context at the exact moment it's needed. | ||
|
|
||
| ## What It Includes | ||
|
|
There was a problem hiding this comment.
All other plugin READMEs include a short “Installation” section with the copilot plugin install <name>@awesome-copilot command. Adding it here would make the plugin consistent with the repo’s plugin docs and reduce friction for first-time users.
| | 2 | `add_skills` (`language=typescript`) | Adds reusable language-specific skills such as conventions guidance so the project setup matches future integration work. | | ||
| | 3 | `fetch_api` (`language=typescript`) | Discovers Twilio is available; returns its `key` | | ||
| | 4 | `ask` (`key=twilio`, query=_"How do I initialize the Twilio TypeScript client?"_) | Returns exact SDK setup code with auth configuration | | ||
| | 5 | `update_activity` (`milestone=auth_configured`) | Records that credentials are wired into the app and the integration is ready for the first live call | |
There was a problem hiding this comment.
This walkthrough calls update_activity(milestone=auth_configured) immediately after an ask response, but auth_configured is supposed to be recorded only after credentials are actually written into the runtime environment and referenced in code. Adjust the example ordering (or clarify that steps 4–5 happen after the developer applies the returned code/config).
| | 5 | `update_activity` (`milestone=auth_configured`) | Records that credentials are wired into the app and the integration is ready for the first live call | | |
| | 5 | `update_activity` (`milestone=auth_configured`) | After the returned SDK/auth configuration has been added to the app, records that credentials are wired into the app and the integration is ready for the first live call | |
| 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` | Lists all APIs available on this server for a given language | "What APIs can I use?" / Starting a new project | A named list of available APIs with short descriptions | | ||
| > | `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 all four tools live during the tour, |
There was a problem hiding this comment.
This onboarding skill says it will demonstrate “the four tools,” but the plugin README/tooling describes additional tools (update_activity, add_guidelines, add_skills). Either expand Phase 0 to cover all available tools or clarify that you’re only covering the core discovery/integration tools in this tour.
|
|
||
| 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`**: |
There was a problem hiding this comment.
Phase 5 instructs to call model_search but doesn’t explicitly remind the agent to pass the required key (chosen API) and language parameters (detected language). Since earlier phases emphasize reusing these values, it would be clearer/less error-prone to specify the full parameter set here.
| Pick a **representative model** from the chosen API (examples below) and call **`model_search`**: | |
| 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 |
| Pick a **representative endpoint** for the chosen API and call **`endpoint_search`**: | ||
|
|
||
| | API key | Good demo query | | ||
| |---|---| | ||
| | `paypal` | `createOrder` | | ||
| | `spotify` | `getTrack` | | ||
|
|
There was a problem hiding this comment.
Similarly to Phase 5, Phase 6 tells the agent to call endpoint_search but doesn’t explicitly specify passing key and language along with the endpoint query. Adding the explicit parameter list here will prevent partial/invalid tool calls.
| Pick a **representative endpoint** for the chosen API and call **`endpoint_search`**: | |
| | API key | Good demo query | | |
| |---|---| | |
| | `paypal` | `createOrder` | | |
| | `spotify` | `getTrack` | | |
| Pick a **representative endpoint** for the chosen API and call **`endpoint_search`** with an explicit argument object: | |
| - `key`: the API key you are demonstrating (for example, `paypal` or `spotify`) | |
| - `query`: the endpoint / SDK method name you want to look up (for example, `createOrder` or `getTrack`) | |
| - `language`: the user's project language (for example, `"typescript"` or `"python"`) | |
| For example: | |
| | API key (`key`) | Endpoint name (`query`) | Example `language` | | |
| |---|---|---| | |
| | `paypal` | `createOrder` | user's project language | | |
| | `spotify` | `getTrack` | user's project language | |
Pull Request Checklist
npm startand verified thatREADME.mdis up to date.stagedbranch for this pull request.Description
This pull request adds a new
context-maticplugin to Awesome Copilot, along with two supporting skills and the related generated marketplace and README updates.The plugin integrates APIMatic's hosted ContextMatic MCP server so GitHub Copilot can retrieve version-aware API and SDK context at runtime instead of relying on generic or outdated examples from model training data. This is aimed at third-party API integration scenarios where correctness depends on the exact API surface, authentication flow, model definitions, and endpoint contracts.
What this PR adds
context-maticplugin definition and marketplace registration.mcp.jsonthat registers the hosted ContextMatic MCP serverintegrate-context-maticskill for end-to-end third-party API integration workflowsonboard-context-maticskill for first-time discovery and guided onboardingWhy this is being added
When developers ask Copilot to integrate an external API, models often have to guess based on outdated training data or public examples that may be stale, incomplete, or mismatched to the actual SDK version in use. ContextMatic addresses that gap by grounding the agent in authoritative, SDK-native API context exposed through MCP tools.
This makes the agent more useful for API integration scenarios.
Benefits
Type of Contribution
By submitting this pull request, I confirm that my contribution abides by the Code of Conduct and will be licensed under the MIT License.