mcp-authoring

Name: mcp-authoring
Author: omnigentx

31stars13forks

How to install mcp-authoring?

omnigentx/jarvis/mcp-authoring

$npx -y skills add omnigentx/jarvis --skill mcp-authoring

Installs into the current project.

Summary

Discover, install, scaffold, attach and debug MCP (Model Context Protocol) servers via the mcp_admin tools — your self-extension surface. Use when the user asks to add a new capability, wire up an off-the-shelf MCP package, inspect what's available, debug a flaky tool, or remove

Files · 1

View on GitHub

SKILL.md

1	# MCP AUTHORING & USAGE
2
3	You can extend yourself with new MCP servers via the `mcp_admin` tools, AND
4	you can inspect/attach/detach existing ones. Read the matching section below
5	for the situation in front of you.
6
7	## Decision tree — pick the section
8
9	\| Situation \| Section \|
10	\|---\|---\|
11	\| "What MCPs do I have? / Show me the catalog" \| Discovery \|
12	\| "Install jq / add the github MCP / register this URL" — server already exists \| Path A \|
13	\| "I need a custom tool that doesn't exist anywhere" \| Path B \|
14	\| "Tool X is broken / silently failing" \| Hot-fix then re-verify \|
15	\| "Detach this server from agent Y" \| `mcp_detach_from_agent` (one call) \|
16
17	## Discovery — inspect before mutating
18
19	Before adding/changing anything, find out what's already there. The right
20	tool depends on what you actually need to know:
21
22	\| You need… \| Call \| Cost \|
23	\|---\|---\|---\|
24	\| List of catalog server names + transport + who's attached \| `mcp_list_servers()` \| compact (~80 chars/server) \|
25	\| Full config of ONE server (command, args, env, cwd) \| `mcp_get_server(name="…")` \| small \|
26	\| Full config of EVERY server (rare — usually wrong) \| `mcp_list_servers(verbose=True)` \| heavy (~500 chars/server × N) \|
27	\| Live tool list + descriptions for one server \| `mcp_test_server(name="…")` \| spawn subprocess, descriptions auto-trimmed to 240 chars \|
28	\| Generated (Path-B) workspace inventory \| `mcp_list_generated()` \| compact (just tool names) \|
29	\| Full manifest + history of one generated server \| `mcp_get_generated(name="…")` \| larger \|
30
31	Default to compact lists. The catalog has ~28 servers; calling the
32	verbose version pulls ~13 KB into context. Get the names compactly, then
33	`mcp_get_server(name)` only the ones you'll actually act on.
34
35	## Path A vs Path B — never mix
36
37	\| Situation \| Flow \|
38	\|---\|---\|
39	\| Server already exists as an npm/pypi package or a hosted URL \| Path A (config-only) \|
40	\| You'd need to write the tool code yourself \| Path B (scaffold-then-test) \|
41
42	If you start Path B and then realize an existing package solves the
43	problem, drop the scaffold (`mcp_clean_workspace(scope="<name>")`) and
44	restart in Path A.
45
46	## Path A — install an existing MCP server
47
48	Five steps. Each calls one tool.
49
50	1. `mcp_check_environment()` — confirm `npx`/`uv`/`python` is available
51	for the package's runtime.
52	2. (Optional) `mcp_check_package_safety(package_name="...", ecosystem="python\|node")`
53	if the package isn't on the recommended allowlist. Read the warnings
54	block — short age, missing homepage, or typo-squat resemblance is
55	reason to ask the user before proceeding.
56	3. `mcp_create_server(name=..., transport="stdio"\|"http"\|"sse",
57	command=..., args=[...], env={...}, url=...)` — this also smoke-tests
58	the config and returns `smoke_failed: True` if the server can't start.
59	4. If create succeeded but smoke failed: read the error, fix the
60	command/args/env, then `mcp_update_server(name, patch=...)`.
61	5. `mcp_attach_to_agent(server="...", agent="Jarvis")` (or another agent).
62	The `tools_added` array tells you what new capabilities you just gained.
63
64	Done. You can call the new tools immediately on the next turn.
65
66	## Path B — scaffold + code + test + promote
67
68	Twelve steps. The pipeline is staged: each tool's output tells you
69	whether to proceed or fix something first.
70
71	### Step 1: Probe environment
72
73	Call `mcp_check_environment()` and pick the language. Prefer Python
74	(your venv is set up); fall back to Node if the user explicitly wants TS
75	and `node` is present.
76
77	### Step 2: Read recommended packages
78
79	Call `mcp_recommended_packages()` and prefer the listed packages — they
80	have a known security track record. For anything else, call
81	`mcp_check_package_safety(package_name=..., ecosystem=...)` and read the
82	`warnings` array. If you see "very new", "no homepage", or "possible
83	typosquat", ask the user before adding it to `requirements.txt`.
84
85	### Step 3: Plan the tool surface
86
87	Decide every tool the server will expose BEFORE scaffolding. For each:
88
89	- name: snake_case, lowercase, ≤ 30 chars. Use a consistent prefix
90	per server (e.g. `github_create_issue`, `github_list_repos`) — keeps
91	tool discovery clean once attached.
92	- description: ≥ 10 chars; describe what the LLM should know
93	(purpose + when to use + what comes back). This text goes into other
94	agents' system prompts — be precise. Vague descriptions are the #1
95	reason a tool never gets called.
96	- args: list of `{"name", "type"}` pairs.
97
98	Don't over-design — start with the minimum tools that solve the user's
99	ask. You can always `mcp_patch_tool(...)` or scaffold a v

People who liked this also viewed

6 picks

Type

mcp-authoring

31stars13forks

View on GitHub

How to install mcp-authoring?

omnigentx/jarvis/mcp-authoring

$npx -y skills add omnigentx/jarvis --skill mcp-authoring

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# MCP AUTHORING & USAGE
2
3	You can extend yourself with new MCP servers via the `mcp_admin` tools, AND
4	you can inspect/attach/detach existing ones. Read the matching section below
5	for the situation in front of you.
6
7	## Decision tree — pick the section
8
9	\| Situation \| Section \|
10	\|---\|---\|
11	\| "What MCPs do I have? / Show me the catalog" \| Discovery \|
12	\| "Install jq / add the github MCP / register this URL" — server already exists \| Path A \|
13	\| "I need a custom tool that doesn't exist anywhere" \| Path B \|
14	\| "Tool X is broken / silently failing" \| Hot-fix then re-verify \|
15	\| "Detach this server from agent Y" \| `mcp_detach_from_agent` (one call) \|
16
17	## Discovery — inspect before mutating
18
19	Before adding/changing anything, find out what's already there. The right
20	tool depends on what you actually need to know:
21
22	\| You need… \| Call \| Cost \|
23	\|---\|---\|---\|
24	\| List of catalog server names + transport + who's attached \| `mcp_list_servers()` \| compact (~80 chars/server) \|
25	\| Full config of ONE server (command, args, env, cwd) \| `mcp_get_server(name="…")` \| small \|
26	\| Full config of EVERY server (rare — usually wrong) \| `mcp_list_servers(verbose=True)` \| heavy (~500 chars/server × N) \|
27	\| Live tool list + descriptions for one server \| `mcp_test_server(name="…")` \| spawn subprocess, descriptions auto-trimmed to 240 chars \|
28	\| Generated (Path-B) workspace inventory \| `mcp_list_generated()` \| compact (just tool names) \|
29	\| Full manifest + history of one generated server \| `mcp_get_generated(name="…")` \| larger \|
30
31	Default to compact lists. The catalog has ~28 servers; calling the
32	verbose version pulls ~13 KB into context. Get the names compactly, then
33	`mcp_get_server(name)` only the ones you'll actually act on.
34
35	## Path A vs Path B — never mix
36
37	\| Situation \| Flow \|
38	\|---\|---\|
39	\| Server already exists as an npm/pypi package or a hosted URL \| Path A (config-only) \|
40	\| You'd need to write the tool code yourself \| Path B (scaffold-then-test) \|
41
42	If you start Path B and then realize an existing package solves the
43	problem, drop the scaffold (`mcp_clean_workspace(scope="<name>")`) and
44	restart in Path A.
45
46	## Path A — install an existing MCP server
47
48	Five steps. Each calls one tool.
49
50	1. `mcp_check_environment()` — confirm `npx`/`uv`/`python` is available
51	for the package's runtime.
52	2. (Optional) `mcp_check_package_safety(package_name="...", ecosystem="python\|node")`
53	if the package isn't on the recommended allowlist. Read the warnings
54	block — short age, missing homepage, or typo-squat resemblance is
55	reason to ask the user before proceeding.
56	3. `mcp_create_server(name=..., transport="stdio"\|"http"\|"sse",
57	command=..., args=[...], env={...}, url=...)` — this also smoke-tests
58	the config and returns `smoke_failed: True` if the server can't start.
59	4. If create succeeded but smoke failed: read the error, fix the
60	command/args/env, then `mcp_update_server(name, patch=...)`.
61	5. `mcp_attach_to_agent(server="...", agent="Jarvis")` (or another agent).
62	The `tools_added` array tells you what new capabilities you just gained.
63
64	Done. You can call the new tools immediately on the next turn.
65
66	## Path B — scaffold + code + test + promote
67
68	Twelve steps. The pipeline is staged: each tool's output tells you
69	whether to proceed or fix something first.
70
71	### Step 1: Probe environment
72
73	Call `mcp_check_environment()` and pick the language. Prefer Python
74	(your venv is set up); fall back to Node if the user explicitly wants TS
75	and `node` is present.
76
77	### Step 2: Read recommended packages
78
79	Call `mcp_recommended_packages()` and prefer the listed packages — they
80	have a known security track record. For anything else, call
81	`mcp_check_package_safety(package_name=..., ecosystem=...)` and read the
82	`warnings` array. If you see "very new", "no homepage", or "possible
83	typosquat", ask the user before adding it to `requirements.txt`.
84
85	### Step 3: Plan the tool surface
86
87	Decide every tool the server will expose BEFORE scaffolding. For each:
88
89	- name: snake_case, lowercase, ≤ 30 chars. Use a consistent prefix
90	per server (e.g. `github_create_issue`, `github_list_repos`) — keeps
91	tool discovery clean once attached.
92	- description: ≥ 10 chars; describe what the LLM should know
93	(purpose + when to use + what comes back). This text goes into other
94	agents' system prompts — be precise. Vague descriptions are the #1
95	reason a tool never gets called.
96	- args: list of `{"name", "type"}` pairs.
97
98	Don't over-design — start with the minimum tools that solve the user's
99	ask. You can always `mcp_patch_tool(...)` or scaffold a v

People who liked this also viewed

6 picks

Type