Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ecoclaw-mcp tune listing-writer to always mention walkability"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Your AI setup, owned by you, forever. No subscriptions, no billing, no ongoing relationship required.
This is the core MCP server installed on every EcoFiClaw customer's machine during in-person setup. After that one day, EcoFiClaw is out of the picture. Your skills live on your machine, they get smarter over time, and you own everything.
EcoFiClaw sets you up with a bundle of AI skills tailored to your business — real estate listing writers, market analysis tools, executive productivity helpers, and more. Those skills are installed locally as simple markdown files in ~/.claude/skills/.
This MCP server is the brain that connects those skills to Claude Desktop. It gives you 6 things you can do with your skills — and crucially, it lets you teach your skills to work the way you work.
Your skills get smarter the more you use them — because whenever something isn't quite right, you can tell Claude to fix it, and it stays fixed permanently. That's the homomorphic part: your software reshapes itself based on your feedback.
Related MCP server: Skills Registry MCP Server
list_skillsShows everything installed, which version, where it came from, and whether you've customized it. A ✏️ means you have a local modification that overrides the original.
run_skill({ name: "listing-writer" })Loads the skill's full instructions into your Claude conversation so Claude knows exactly what to do. Always uses your customized version if you have one.
tune_skill({ name: "listing-writer", feedback: "always end with a P.S. that mentions the neighborhood's walkability" })This is the powerful one. You tell Claude what's not working, and it rewrites the skill's instructions to fix it — permanently, locally, on your machine. The original version is never touched. Next time you use the skill, your version is used automatically.
Examples of feedback that works:
"use a more casual, conversational tone"
"never mention specific competitor agencies"
"always include a social media caption at the end"
"add a section for first-time buyers explaining the process"
fork_skill({ name: "listing-writer", fork_name: "listing-writer-luxury" })Creates an independent copy under a new name. Good when you want listing-writer for standard properties AND listing-writer-luxury for high-end ones — completely separate, each improvable on its own.
contribute({ name: "listing-writer", description: "Added neighborhood walkability P.S. — useful for urban markets" })If you've improved a skill and think it'd help other agents, this submits a pull request to the upstream repository. Uses the gh CLI installed during setup. Completely optional — you choose what and when to share. The diff is shown before anything is submitted.
update_skillsPulls the latest versions of all installed skills from npm. Skills you've customized are automatically skipped — your tuning is never overwritten. You see exactly what updated and what was preserved.
Every skill is a markdown file (SKILL.md) that tells Claude how to behave — what tone to use, what steps to follow, what to include in outputs. When you tune_skill, Claude reads that file and rewrites it to incorporate your feedback.
The original file in ~/.claude/skills/ is never touched. Your modified version goes into ~/.ecoclaw/skills/. When you use a skill, your version takes priority.
This means:
Your customizations are durable — they survive npm updates
You can always see what changed (it's just a text file)
You can roll back by deleting your local version
You can contribute improvements back to the community
It's software that reshapes itself. Your stack, your way.
Everything lives in two places on your machine:
~/.claude/skills/ # npm-installed skills (managed by npx)
listing-writer/
SKILL.md
~/.ecoclaw/ # your stuff (managed by this MCP)
skills/
listing-writer/
SKILL.md # your customized version (overrides above)
listing-writer-luxury/
SKILL.md # your fork
config.json # install record: packages, profile, skill metadata
history.jsonl # log of every tune operationNothing is sent to EcoFiClaw servers. The only network activity is:
tune_skill calls the Anthropic API (same as Claude Desktop itself)
contribute submits a GitHub PR if you explicitly ask for it
update_skills fetches npm packages if you explicitly ask for it
You own these files. Back them up, put them in git, move them to a new machine — they're yours forever.
If you've improved a skill through tune_skill and think your change would help other agents in your area, run contribute. It:
Shows you the diff between your version and the original
Submits a pull request to the upstream skill repository
The EcoFiClaw community reviews and, if it's good, releases it to everyone
You're not required to contribute anything. But if you do, you make the whole system better for everyone who comes after you.
Email: root@ecoficlaw.com
The software is designed to handle most things itself. If something feels off — a skill not doing what you expect, a tune not sticking — try tune_skill again with more specific feedback. Claude is pretty good at understanding what you want.
If you're stuck, reach out. We set this up for you in person and we're happy to help.
Add this to your Claude Desktop settings (Settings → Developer → Edit Config):
{
"mcpServers": {
"ecoclaw": {
"command": "npx",
"args": ["-y", "@ecoclaw/mcp"],
"env": {}
}
}
}MIT. You own this software. Do what you want with it.
Build an instruction string for agent delegation from a list of skill names. Returns a string like "Make sure to use the following skills: 'arxiv', 'fred-economics'" that can be prepended to an agent task.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_names | Yes | List of skill names to include in the context string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the exact return format with a concrete example, which is the core behavior an agent needs to know. It does not cover error handling or validation of skill names, but for a simple string-building utility this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The action, purpose, and an illustrative output example are all included efficiently, and the example is positioned right after the action statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description fully covers what the tool does, what input it takes, what it returns, and how the return value should be used. Nothing essential is missing for a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter is already described as a list of skill names. The description adds value by showing exactly how the skill names are rendered (quoted, comma-separated, preceded by fixed instruction text), which helps the agent anticipate the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Build') and resource ('instruction string for agent delegation'), and specifies the input (list of skill names) and output (a string that can be prepended to an agent task). It is clearly distinguishable from sibling tools like run_skill or list_skills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear by explaining the result is for agent delegation and can be prepended to an agent task. It does not explicitly mention when not to use it or name alternatives, but the context is direct enough for an agent to recognize the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Share a skill improvement back to the community by submitting a GitHub PR to the upstream repo. Shows you the diff first. Uses the gh CLI (installed during EcoFiClaw setup). Completely optional — you choose when and what to share.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Skill to contribute | |
| description | Yes | Explain what you changed and why it helps others |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the behavioral burden. It discloses the key side effect (a GitHub PR is submitted), the preview behavior (shows the diff first), the gh CLI dependency, and optionality. It doesn't explicitly say whether user confirmation is required after the diff or what happens on failure, but the core behavior is not hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with the purpose first, workflow details second, and optionality last. Every sentence earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description covers what it does, how it behaves (diff preview), and the environment prerequisite. The only notable omission is the expected result or return flow after the PR is submitted, but that does not block correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are documented in the schema with 100% coverage, and the tool description largely reflects the same meaning. 'description' gains a little context from 'why it helps others,' but no additional format, lookup, or edge-case semantics are provided, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a concrete verb and resource: share a skill improvement by submitting a GitHub PR to the upstream repo. This is specific enough to distinguish 'contribute' from siblings like fork_skill or run_skill, even though it doesn't name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description sets clear context that the tool is for sharing improvements back to the community and stresses that it is completely optional, so the agent knows to invoke it only when the user chooses to contribute. It does not explicitly enumerate alternative tools or when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan the current project and installed npm packages for available skills. Returns structured manifests with id, name, description, triggers, dataSources, byokKeys, and author. Looks in /skills/, node_modules/@gonzih/skills-/skills/, and node_modules/@ecoclaw//skills/.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Directory to scan (default: current working directory) | |
| filter_by_keys | No | If true, only return skills whose required BYOK API keys are present in the environment. Skills with no byokKeys are always included. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses the directories scanned and the exact fields returned, which is useful behavioral context. It doesn't explicitly state it's read-only, but the 'scan' verb implies a non-destructive operation, and the level of detail is sufficient for a scan tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. The first sentence front-loads the core purpose, the second specifies the return type, and the third lists the search paths. Every sentence adds essential information, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple scan tool with two optional parameters and no output schema, the description is fairly complete. It covers the purpose, search locations, and return format. The only missing element is explicit guidance on when to use it over siblings, but that is addressed under usage guidelines, and the description provides enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions for dir and filter_by_keys. The description adds no additional parameter context, so the baseline of 3 applies. The schema already explains the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Scan') and resource ('current project and installed npm packages for available skills'), and details the output structure (manifests with id, name, etc.). It clearly distinguishes itself from a generic listing tool by specifying the scan targets and the structured return format, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus sibling tools like list_skills or list_byok_keys. It states what it does but doesn't mention alternatives or exclusion criteria, leaving the agent to infer when discovery is preferred over listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an independent copy of a skill under a new name. Use this when you want a specialized variant (e.g. listing-writer-luxury) while keeping the original unchanged. Both versions appear in list_skills.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Source skill to fork | |
| fork_name | No | Name for the fork (default: {name}-custom). Use something descriptive like listing-writer-luxury. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the fork is independent, that the original remains unchanged, and that both versions appear in list_skills. These are concrete behavioral details. It does not cover error conditions or permission requirements, but for a copy operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and purpose, followed by a relevant example and side effect. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple copy operation with two parameters and no output schema, the description covers the purpose, usage scenario, and a key side effect (appears in list_skills). It lacks error handling or return behavior, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds naming guidance ('Use something descriptive like listing-writer-luxury') and clarifies the default pattern, which is slight value beyond the schema but not substantial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create an independent copy of a skill under a new name') with a specific resource (skill) and purpose (specialized variant). It distinguishes itself from siblings by mentioning the original stays unchanged and that both appear in list_skills, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use it: 'Use this when you want a specialized variant (e.g. listing-writer-luxury) while keeping the original unchanged.' This provides clear context, though it does not mention alternatives or when not to use it, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan all discovered skills and report which BYOK API keys are present vs. missing in the current environment. Helps you know what to configure to unlock more skills.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It conveys a non-destructive reporting operation through 'scan' and 'report', and it explains that the report compares present vs. missing keys in the current environment. It does not detail whether key values are exposed, what environment access is required, or what the exact output shape is, so some behavioral ambiguity remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two front-loaded sentences with no filler. The first sentence states the operation and scope, and the second explains the practical value. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema reporting tool, the description is largely complete: it says what is scanned, what is reported (present vs. missing keys), and why it matters. It could have briefly mentioned output format or explicitly routed to list_skills for skill-level details, but those omissions are minor given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema already covers everything at 100%, so the baseline is 4. The description adds no parameter-specific detail, but none is needed since invocation requires no arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: scanning discovered skills and reporting which BYOK API keys are present vs. missing. It identifies the resource (BYOK API keys) and the purpose (knowing what to configure), and it is naturally distinguished from the siblings, which focus on skills rather than key availability. However, it does not explicitly name or contrast itself with a sibling such as list_skills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: use this tool when you need to know which BYOK API keys must be configured to unlock more skills. It does not explicitly discuss when not to use it or name alternatives, but the context is strong enough for an agent to recognize the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all installed skills — both npm-installed (/.claude/skills/) and your local customizations (/.ecoclaw/skills/). Shows name, version, source, and whether you've customized it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It states the action is a read-only list, shows the locations scanned, and enumerates the displayed fields (name, version, source, customization status). This provides a transparent picture of the operation without hiding side effects, which are minimal for a list command.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action ('List all installed skills') and then adds the two source locations and the output fields in a natural flow. Every clause adds information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description is complete. It covers what is listed, where skills are found, and what information is shown. An agent has everything needed to invoke and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. The baseline for zero-parameter tools is 4, and the description correctly focuses on behavior and output rather than adding unnecessary parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource: 'all installed skills'. It further distinguishes itself from siblings like discover_skills by specifying local installations (~/.claude/skills/ and ~/.ecoclaw/skills/) and what fields are shown, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this is for viewing already-installed skills, which is a clear context. It does not explicitly mention alternatives or when not to use it, but the scope ('installed' vs. discovered/updated) is implied well enough for an agent to pick this over siblings like discover_skills or update_skills.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full prompt/instructions for a skill so Claude can use it inline. Checks your user-local version first (~/.ecoclaw/skills/), then falls back to the npm-installed version.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Skill name (e.g. listing-writer) | |
| context | No | Optional context about what you want to do with this skill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds valuable detail about resolution order ('user-local first, then npm-installed') and the file paths involved, while also clarifying that 'run_skill' actually retrieves rather than executes. It doesn't describe failure behavior, but it gives materially useful context beyond the bare function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core purpose is front-loaded, and the fallback behavior is presented compactly in the second sentence. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the essential purpose, return content, and resolution behavior. It lacks explicit error-case guidance and doesn't elaborate on how 'context' affects the result, but the schema fills the parameter gap and the description conveys sufficient operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning for 'context' or 'name' beyond the inline schema example, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Get the full prompt/instructions for a skill'. It distinguishes itself from execution-focused tools by clarifying the purpose is to fetch instructions for inline use, though it doesn't explicitly contrast itself with siblings like build_skill_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this to retrieve a skill's prompt for inline use. However, it provides no explicit when-to-use or when-not-to-use guidance relative to sibling tools like list_skills, tune_skill, or build_skill_context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply plain-language feedback to a skill, permanently modifying how it works for you. This is the homomorphic heart — your feedback gets written into the skill's prompt and saved locally. The original npm version is never touched. Examples: 'always use a more casual tone', 'end every output with a P.S.', 'never mention competitors'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Skill name to tune | |
| feedback | Yes | Plain-language description of how you want the skill to change |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden of behavioral disclosure. It openly states that feedback is written into the skill's prompt, saved locally, and that the original npm version is untouched. This gives the agent a clear picture of side effects and persistence, beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. However, the phrase 'This is the homomorphic heart' is esoteric and adds no clarity, slightly detracting from the overall structure. It could be removed without loss of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 parameters, no output schema), the description covers the essential behavior and side effects. It explains persistence and non-modification of the original. It does not mention error conditions (e.g., skill not found) but that is likely implied. Overall, it is sufficient for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds examples of feedback but does not add meaning beyond the schema's parameter descriptions. The examples are helpful but not essential for understanding the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Apply'), resource ('skill'), and explicitly states the effect ('permanently modifying how it works for you'). It clearly distinguishes from siblings like run_skill and fork_skill by emphasizing the permanent, local modification. The examples further clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to apply feedback to a skill) but does not explicitly contrast with alternatives such as fork_skill or run_skill. It provides clear context ('permanently modifying') but lacks explicit exclusions or a mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull the latest npm versions of all installed skills. Skills with local customizations are skipped to protect your tuning — you'll see exactly what was updated and what was preserved.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | No | Update only this skill (optional). Omit to update all skills. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose a key behavior — that skills with local customizations are skipped to protect tuning — and that the tool reports what was updated and preserved. However, it does not mention any side effects beyond updating, such as whether the update is reversible, whether it requires authentication or permissions, or whether it might break existing setups. For a mutation tool, this is a moderate disclosure but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The core action is front-loaded ('Pull the latest npm versions of all installed skills.'), and the second sentence adds a critical behavioral caveat. Every word earns its place, making it highly readable and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity — one optional parameter, no output schema, no annotations — the description is fairly complete. It explains what the tool does, what happens to customized skills, and what the user will see as output. It doesn't mention prerequisites or error cases, but for a straightforward update tool this is sufficient. The only gap is the lack of a return specification, but the description already implies an output list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single optional parameter 'skill' is fully described in the schema ('Update only this skill (optional). Omit to update all skills.'). The description does not add any additional meaning to the parameter beyond what the schema already says. Baseline of 3 is warranted since the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Pull the latest npm versions of all installed skills') with a specific verb and resource. It also adds a distinguishing detail (skipping locally customized skills) that separates it from siblings like list_skills or run_skill. The purpose is unambiguous and easily understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool — when you want to update installed skills — but it does not explicitly state when not to use it or mention any alternatives (e.g., 'use list_skills to view skills'). There is no contrast with sibling tools, so an agent must infer usage from the tool's name and context. This is adequate but lacks explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0build_skill_contextcontributediscover_skillsfork_skilllist_byok_keyslist_skillsrun_skilltune_skillupdate_skillsScored across 9 tools
Most tools target distinct actions: listing, discovering, running, tuning, forking, updating, contributing, and building context. The main potential confusion is between list_skills and discover_skills, but their descriptions differentiate installed skills from scanned available skills well.
Tool names mostly follow a consistent snake_case verb_noun pattern such as list_skills, run_skill, tune_skill, fork_skill, and update_skills. The exception is 'contribute', which breaks the pattern by being a bare verb without a noun.
Nine tools is a well-scoped set for a skill-management server. Each tool has a clear role in the discover, configure, customize, update, and share workflow, with no obvious bloat or redundancy.
The toolkit covers listing, discovering, running, tuning, forking, updating, contributing, and context-building, but lacks obvious install and delete/uninstall operations. Agents cannot fully manage the skill lifecycle when a user asks to remove or newly install a skill, though most customization workflows are supported.
Agent-first skill marketplace with USK open standard for Claude, Cursor, Gemini, Codex CLI.
Search your team's shared AI-skill library, get install commands, and save skills from your agent.
Search, install and submit Markdown skills for AI agents; private Brain files when signed in.
Search verified Claude Code plugins and skills; fetch portable SKILL.md sources. Read-only.
