Provides tools for managing Puppet Master framework operations, including initialization, development, database management, deployment, builds, linting, testing, configuration, knowledge retrieval, contribution workflows, and code reviews.
Click on "Install 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., "@Puppet Master MCP Server init a new Puppet Master project"
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.
MCP (Model Context Protocol) server providing 26 tools for Puppet Master framework operations — initialization, development, database, deployment, builds, linting, testing, configuration, knowledge retrieval, contribution workflows, and code reviews.
git clone <repo-url> pm-mcp-server
cd pm-mcp-server
npm installAdd to ~/.config/kilo/kilo.json:
{
"mcp": {
"puppetmaster": {
"type": "local",
"command": ["node", "/path/to/pm-mcp-server/dist/index.js"],
"enabled": true
}
}
}Or use tsx to run from source (enables dynamic TS config imports):
"command": ["npx", "tsx", "/path/to/pm-mcp-server/src/index.ts"]Add to .kilo/kilo.json in a project:
{
"mcp": {
"puppetmaster": {
"type": "local",
"command": ["node", "../pm-mcp-server/dist/index.js"],
"enabled": true
}
}
}Related MCP server: Magento 2 Development MCP Server
Category | Tools |
Config |
|
Dev |
|
Database |
|
Deploy |
|
Build/Quality |
|
Knowledge |
|
Contributing |
|
Review |
|
The server uses process.cwd() to detect the current PM project root (set automatically by the host agent). Each tool operates on the project in the current working directory. From a non-PM directory, tools report "no config found" gracefully.
npm run build # TypeScript → dist/Pre-built dist/ is committed for users who want to run with node directly without tsx.
MIT
Run a production build of the Puppet Master project. Creates optimized output in .output/ directory. Only use when explicitly requested for deployment or testing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states that it creates output in .output/ but does not mention if the build is destructive, requires authentication, or has any side effects. Given the lack of annotations, this is insufficient.
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 that front-load the primary action and output location. No unnecessary words, every sentence serves a purpose.
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 no parameters and no output schema, the description covers the key points: what it does, where output goes, and when to use. However, it lacks behavioral transparency details (e.g., whether it overwrites the output directory, if it's safe to run repeatedly). This leaves gaps that annotations might have filled.
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 has zero parameters, and schema description coverage is 100%. The description adds no parameter information because there are none. Per guidelines, baseline for 0 params is 4, which 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 the verb 'run' and resource 'production build of the Puppet Master project', and mentions the output directory. It distinguishes from siblings like pm_deploy or pm_dev by specifying 'production build', but could be more explicit about the difference.
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?
Explicitly states 'Only use when explicitly requested for deployment or testing', providing clear context for when to use. However, it does not mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Puppet Master configuration values. Returns pmMode, entities, features, modules, sections, locales, colors, admin settings.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Dot-notation key to read (e.g. "pmMode", "modules.blog", "colors.brand"). Omit for full config. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It correctly indicates read-only behavior. However, it does not explicitly state that no side effects occur or mention authentication requirements. It is adequate for a simple read operation.
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?
Single sentence that starts with the primary action ('Read Puppet Master configuration values'), then lists key returned fields. No wasted words; front-loaded and efficient.
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?
No output schema, but description lists several returned fields, giving agent a sense of what to expect. It could be more complete by stating the return format (e.g., JSON object) but is adequate for a simple read tool with one optional parameter.
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 description adds marginal value beyond the schema. It lists some returned values but does not explain the 'key' parameter further. Baseline 3 is appropriate as schema already documents the parameter fully.
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?
Description uses specific verb 'Read' and resource 'Puppet Master configuration values', and lists the returned fields (pmMode, entities, etc.). It clearly distinguishes from sibling pm_config_set which is the write counterpart.
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?
States that tool reads configuration and lists returned values. While it doesn't explicitly say 'use this when you need to read config, not write', the sibling pm_config_set makes that clear. Slight room for more explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify a Puppet Master configuration value directly in project/puppet-master.config.ts. Supports dot-notation keys. WARNING: rewrites the config file as JavaScript.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Dot-notation key to set (e.g. "pmMode", "modules.blog.enabled") | |
| value | No | New value to set (string, boolean, number, or JSON) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It warns that the file is rewritten as JavaScript, which is a key behavioral trait. However, it does not mention permissions, reversibility, or effects on formatting.
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 extremely concise with two sentences and a warning, no unnecessary words, and all information is front-loaded.
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 has only two parameters and no output schema, the description covers the purpose and a critical warning. It could mention the return value, but it's largely complete for a mutation tool.
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%, but the description adds value by mentioning dot-notation support and clarifying the value types (string, boolean, number, or JSON), which enhances understanding beyond the schema.
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 it modifies a Puppet Master configuration value in a specific file, distinguishing it from sibling tools like pm_config_get (read) and others.
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?
While it does not explicitly state when to use versus alternatives, the description implies it's for writing config values, and the sibling pm_config_get is for reading. The warning about rewriting the file provides context for careful use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a .pm-contribution.md file and display its contents for manual application. Lists changed files, affected domains, dependencies, and testing instructions. Does NOT auto-apply — the AI agent reviews and applies.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | Path to the contribution file (defaults to .pm-contribution.md in project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states it reads, displays, and does NOT auto-apply, fully disclosing its non-destructive, read-only nature. Lacks details on error handling or missing file behavior, but acceptable for a simple read 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?
Two short sentences that front-load the purpose and key details. Every sentence is informative with no filler.
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 read-and-display tool with no output schema and few parameters, the description sufficiently covers what the tool does and what it shows. Could mention return format or behavior if file is missing, but not critical.
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?
Only one parameter with 100% schema coverage. Description adds minimal extra meaning beyond the schema's description of path and default value.
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?
Clearly states it reads and displays a .pm-contribution.md file, listing changed files, affected domains, etc. Distinguishes from siblings by emphasizing it does NOT auto-apply.
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?
States it is for manual application and that the AI agent reviews and applies, indicating when to use. Provides clear context but does not explicitly name alternative tools for auto-apply scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export current git changes as a PM contribution document. Generates a .pm-contribution.md file with diffs, descriptions, and testing instructions. Use this when you fix a bug or add a feature in a client project that should be contributed back to the PM framework.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | No | One-line summary of the contribution | |
| type | No | Type of contribution | |
| problem | No | What was broken or why was this needed | |
| solution | No | How the problem was solved | |
| testing | No | Step-by-step testing instructions | |
| files | No | Comma-separated list of files to include (defaults to git diff --name-only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states it generates a .pm-contribution.md file with diffs, descriptions, and testing instructions, but does not clarify what happens if the file already exists, whether it overwrites, or if there are side effects on the git state. It neither confirms nor denies destructive behavior.
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 extremely concise, consisting of two sentences. The first sentence clearly states the primary action and output, and the second sentence provides usage context. There is no superfluous 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?
While the description mentions that the output contains diffs, descriptions, and testing instructions, it does not explain how the parameters map to sections of the output document. Given six optional parameters and no output schema, a more detailed explanation of the generation logic or output structure is needed for completeness.
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 parameters are well-documented in the schema. The description adds no additional meaning beyond the schema; it does not explain how the parameters (summary, type, problem, solution, testing, files) are used in the generation process. Therefore, 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 the tool exports current git changes as a PM contribution document. It uses a specific verb-resource pair ('Export current git changes') and distinguishes itself from sibling tools like pm_contribute_apply, pm_contribute_list, and pm_contribute_read by focusing on creation/export rather than application or listing.
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 explicitly says 'Use this when you fix a bug or add a feature in a client project that should be contributed back to the PM framework.' This provides a clear context for use. However, it does not mention when not to use this tool or explicitly list alternatives, though siblings imply the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all existing contribution documents in docs/contributing/. These are fixes/features exported from client projects that can be applied to the PM framework.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status keyword found in the doc (e.g. ENGRAVED, PROPOSED) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the basic function; it does not disclose whether the operation is read-only, whether it has side effects, what happens if the directory is missing, or any permissions requirements.
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 sentence plus a clarifying parenthetical, no unnecessary words, and easily digestible.
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?
The tool is simple (list with optional filter), but no output schema is provided and the description does not specify the return format (e.g., list of file names, documents with metadata). The description adequately covers the input but not the output.
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 has one parameter 'status' with a description and example values. Schema description coverage is 100%. The tool description does not add additional meaning beyond the schema, so baseline 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 the verb 'list' and the resource 'contribution documents in docs/contributing/', and explains what these documents are (fixes/features exported from client projects). This distinguishes it from sibling tools like pm_contribute_apply and pm_contribute_read.
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?
No explicit guidance on when to use this tool versus alternatives. The context of listing vs applying/reading is implied, but the description doesn't provide direct 'when-to-use' or 'when-not-to-use' instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a specific contribution document. Returns the full content for review or application.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Filename of the contribution doc (from pm_contribute_list) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states returns full content but does not mention auth requirements, rate limits, or whether the operation is read-only. While read operations are generally safe, the description does not explicitly confirm non-destructiveness or other traits.
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, concise sentence that immediately conveys the tool's purpose and output. It is front-loaded and contains no unnecessary 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 tool with one required parameter and no output schema, the description adequately covers the action and result. It could mention error handling or content format, but given the tool's minimal complexity, it is sufficiently complete.
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 has 100% coverage, with the description for the 'file' parameter already provided. The tool description does not add semantic meaning beyond that; it merely restates the schema context. Baseline score of 3 is appropriate since the schema already documents the parameter well.
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 (Read) and the resource (a specific contribution document), and it returns full content. This distinguishes it from sibling tools like pm_contribute_list (lists docs) and pm_contribute_apply (applies a contribution).
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 usage by stating 'Read a specific contribution document,' but it does not explicitly guide when to use this tool versus alternatives or provide exclusions. The parameter hint 'from pm_contribute_list' suggests a workflow, but the description itself lacks explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Drizzle migrations against the database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'run migrations' but does not explain what that entails (e.g., applying pending migrations, modifying the database schema, requiring a connection, or outputting a log).
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, front-loaded sentence with no wasted words. It is concise and immediately conveys the tool's purpose.
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 absence of parameters and an output schema, the description is mostly complete for a migration tool. However, it could mention that it applies pending migrations or provide minimal context about expected outcomes.
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?
There are no parameters, so the description cannot add parameter-level meaning. According to scoring guidelines, zero parameters yield a baseline of 4, which is appropriate here.
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 it runs Drizzle migrations against the database, using a specific verb and resource. It is distinct from sibling tools like pm_db_push, pm_db_reset, or pm_db_seed, though it does not explicitly differentiate itself.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, such as needing a migration directory or that it should be run after generating migrations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push Drizzle ORM schema to SQLite database. Creates the database file and applies schema changes.
| 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 full burden for behavioral transparency. It states it 'creates the database file and applies schema changes' but does not disclose potential destructive actions, required permissions, reversibility, or side effects.
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?
Extremely concise at 14 words over two sentences. Every sentence is meaningful and the purpose is front-loaded. No wasted text.
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 database-modifying tool with no annotations or output schema, the description lacks context on prerequisites (e.g., a schema file or config), safety for existing databases, and exact behavior. It feels incomplete for the complexity implied.
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?
There are zero parameters, so the baseline is 4. The description does not need to add parameter info; it is adequate for a no-parameter tool.
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 verb 'Push' and the resource 'Drizzle ORM schema to SQLite database', specifying it creates the database file and applies schema changes. It distinguishes itself well from sibling database tools like pm_db_migrate or pm_db_reset.
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 usage for initial schema setup or updates but does not explicitly state when to use versus alternatives like pm_db_migrate. No usage context or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset the database: delete the SQLite file, re-run migrations, and seed with initial data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly discloses destructive behavior (delete SQLite file) and outlines the reset steps, providing sufficient transparency for an agent to understand its side effects.
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 extremely concise: one sentence that efficiently conveys the tool's purpose and internal steps. 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?
Given the tool has no parameters and no output schema, the description is complete. It specifies all actions taken during the reset (delete, migrate, seed), which is sufficient for agent decision-making.
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?
There are zero parameters, and schema coverage is 100%. The description implicitly confirms the tool requires no input, which is fully adequate.
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 verb 'Reset' and resource 'database', detailing three specific actions: delete SQLite file, re-run migrations, seed with initial data. This distinguishes it from siblings like pm_db_migrate or pm_db_seed.
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 a full reset but does not explicitly state when to use this tool versus alternatives like pm_db_migrate or pm_db_seed. No guidance on prerequisites or consequences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Seed the database with initial data (users, roles, sample content). Requires an existing database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavior disclosure. It only states it seeds with initial data but does not specify idempotency, overwrite behavior, side effects, or whether it can be run multiple times. This is insufficient for a potentially destructive operation.
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 efficient sentence but lacks structured information about behavior or post-conditions. It is concise but could be more informative without adding length.
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 no output schema, no annotations, and no parameters, the description should cover prerequisites, behavior, and outcomes. It mentions a prerequisite but omits whether seeding is safe to repeat, what happens on subsequent runs, and any confirmation or error messages. This leaves the agent under-informed.
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 has no parameters (0 params), so the description does not need to explain parameter meaning. Baseline of 4 is appropriate since no parameter details are missing.
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 seeds the database with initial data (users, roles, sample content) and includes a prerequisite ('Requires an existing database'). This is specific and helps distinguish from other database tools like pm_db_reset or pm_db_migrate.
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?
Only one usage condition is given (requires existing database). No guidance on when not to use it or alternatives among sibling tools (e.g., pm_db_reset for resetting, pm_db_migrate for schema changes). The agent lacks direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open Drizzle Studio (web UI for browsing the database).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states it opens a web UI for browsing, but does not disclose behavioral details such as whether it is read-only, requires a running server, or has any side effects. With no annotations, it carries the full burden, which is insufficient.
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 sentence of 8 words, conveying the essential information without any fluff. 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 simple tool with no parameters and no output schema, the description is mostly complete. It identifies the tool's purpose and resource, though it could mention that it is non-destructive or requires no prior setup.
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?
There are no parameters, and the schema coverage is 100% (vacuously). The description adds no parameter information, but baseline is 3 due to high schema coverage.
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 'Open' and the resource 'Drizzle Studio' and specifies it's a web UI for browsing the database. It is distinct from sibling tools like pm_db_migrate, pm_db_push, etc., which perform database schema operations.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios or prerequisites, leaving the agent to infer usage from the tool's name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy the Puppet Master project to its configured VPS. Builds Docker image, pushes via SSH, runs Ansible deploy playbook, regenerates Traefik config, and health checks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It lists steps (build, push, Ansible playbook, Traefik config, health checks) but omits details like whether the tool is destructive, requires specific permissions, or handles rollbacks. The description gives a high-level view but lacks depth.
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 sentence that covers all key actions. While somewhat lengthy, it is efficient and contains no redundant information. It is front-loaded with the main verb and resource.
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 no parameters and no output schema, the description covers the major steps of deployment. It provides a clear overview but lacks details on error scenarios or outputs. For a deploy tool, it is adequately complete.
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?
There are no parameters, and schema coverage is 100% (baseline 4). The description does not need to add param info; it focuses on the tool's actions, which 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 the tool's purpose: to deploy the Puppet Master project to a VPS. It lists specific steps (build, push, Ansible, Traefik, health checks), making it distinct from sibling tools like pm_build (only builds) or pm_rollback (rollback).
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 usage when a deployment is needed, but it does not explicitly state when to use this tool vs alternatives (e.g., pm_build as a prerequisite) or provide any constraints. No guidance on exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View deployment logs from the VPS.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and only a 6-word description, the behavioral traits are not disclosed. It does not explain whether logs are recent, filtered, paginated, or if the operation is read-only or requires authentication.
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 extremely concise at 6 words, front-loaded with the key verb and resource, and contains no extraneous 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 tool has no parameters, no output schema, and no annotations, the minimal description is adequate for a very simple tool but lacks details on output format or limitations, which could help in complex scenarios.
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?
There are no parameters, and schema description coverage is 100%. The description does not need to add parameter semantics, aligning with the baseline score of 4 for zero-parameter tools.
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 explicitly states 'View deployment logs from the VPS,' clearly identifying the action (view) and resource (deployment logs), and distinguishes from sibling tools like pm_deploy and pm_rollback.
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?
No guidance is provided on when to use this tool versus alternatives, such as pm_deploy or pm_status. There is no mention of prerequisites or context for viewing logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage the PM development server. Start, stop, restart, or check status. The dev server runs on port 3000 by default.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Action to perform on the dev server | |
| port | No | Port to check (default: 3000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the default port and allowed actions, but lacks details on synchronous/asynchronous behavior, prerequisites, or what the status response includes. With no annotations, the description provides basic transparency but not comprehensive behavioral context.
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 wasted words. It front-loads the core purpose and provides essential default information efficiently.
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 no output schema and only two parameters, the description adequately covers the tool's purpose and default port. It could mention if operations are synchronous, but remains complete for a simple dev server management tool.
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 schema already documents both parameters. The description adds context about the default port but does not elaborate on action values beyond the enum. At baseline 3, it offers slight added value.
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 manages the PM development server with specific verbs (start, stop, restart, check status) and identifies the resource. It distinguishes from sibling tools focused on building, deployment, or configuration.
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 does not specify when to use this tool versus alternatives. For instance, pm_status might be used for overall project status, and no guidance is given on when pm_dev is the correct choice or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize a Puppet Master project. Checks dependencies, reads pmMode from config, and guides through setup (develop or build mode). Optionally starts the dev server.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Set pmMode: develop (framework dev, seeded DB), build (client project, empty DB), or auto (read existing config) | |
| startDev | No | Start dev server after initialization |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses key behaviors: dependency checking, config reading, setup guidance, and optional dev server start. However, it omits details about side effects (e.g., file creation, config changes) or required permissions.
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 redundancy. First sentence front-loads the core purpose; second adds detail on optional server start. Every word serves a purpose.
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 no output schema and only two parameters with full schema coverage, the description covers the main workflow adequately. It could mention expected return values or post-initialization state, but overall it is sufficient for a straightforward initialization tool.
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 explains both parameters well. The description adds no new meaning beyond reiterating the 'optionally starts the dev server' for startDev, which is minimal enhancement. Baseline 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 the verb 'Initialize' and the resource 'Puppet Master project', and specifies the actions of checking dependencies, reading config, and guiding through setup modes. It effectively distinguishes this tool from siblings like pm_dev and pm_build by highlighting its initialization role.
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 usage for initializing a project and optionally starting the dev server, but it does not explicitly state when not to use or how it differs from similar siblings like pm_setup. The context is clear but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load the Puppet Master framework knowledge base. Returns CSS system, component architecture, composables, database schema, API patterns, config system, and RTL reference.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic to load: css, components, composables, database, api, config, rtl, rules, or all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions the return content but omits side effects, restrictions, or performance characteristics. The tool is likely read-only, but this is not explicitly stated.
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 concise sentence that front-loads the verb and resource. It efficiently lists the topics without verbosity.
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?
The description is adequate for a simple tool with one parameter and no output schema. It explains the basic behavior and available topics, but lacks details about the return format or structure of the knowledge base content.
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% with the topic parameter fully documented. The tool description adds a redundant list of topics but provides minimal extra meaning beyond the enum values. Baseline 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 'Load the Puppet Master knowledge base' and lists the specific topics returned. However, it does not explicitly differentiate from sibling tools like pm_knowledge_contributing or pm_knowledge_entrypoint, which may have overlapping functionality.
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?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, when-not to use, or describe context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or read PM contribution documents. Contributions are fixes/features exported from client projects for application back into the PM framework. Stored in docs/contributing/.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | list all contribution docs, or read a specific one | |
| file | No | Filename to read (only when action=read) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states that the tool lists or reads documents without mentioning permissions, side effects, or whether operations are read-only. The storage location is mentioned, but behavioral traits are minimal.
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 and concise, but it lacks structure such as separating purpose from details. It is efficient but could be more informative without being verbose.
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 simple two-parameter schema and no output schema, the description provides basic context. However, it does not address the existence of sibling tools or describe what the list action returns, leaving some gaps for an agent.
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 baseline is 3. The description does not add significant meaning beyond the schema; it restates the action enum and does not clarify the file parameter beyond 'read a specific one'.
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 specific verb-resource combinations (list or read PM contribution documents) and explains what contributions are. However, it does not differentiate from sibling tools like pm_contribute_list and pm_contribute_read, which appear to serve the same 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 provides no guidance on when to use this tool versus the sibling contribute tools, such as pm_contribute_list or pm_contribute_read. An agent would not know which to choose based on the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load greenfield or brownfield entrypoint documentation. Greenfield = new project from PM baseline. Brownfield = migrating existing codebase into PM.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Entrypoint to load: greenfield (new project), brownfield (migration), or overview (decision tree) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'load documentation' without disclosing behavioral traits such as whether it is read-only, idempotent, or makes network requests. For a simple load operation, more transparency is expected.
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 concise sentences that front-load the purpose. Every word is necessary, and there is no filler. The structure efficiently communicates the core functionality and the two main modes.
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?
The description is minimally complete for a simple tool with one parameter. It lacks details about the return format, error handling, or examples. Given no output schema, the description could have provided more context about what the agent can expect after calling the tool.
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 already has a clear description in the schema. The tool description repeats some of that context but adds value by explaining 'Greenfield = new project from PM baseline' and 'Brownfield = migrating existing codebase', which helps the agent understand the enum values.
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 loads entrypoint documentation for greenfield and brownfield projects, distinguishing between the two modes and an overview. It uses specific verbs and resources, differentiating it from sibling tools like pm_knowledge and pm_knowledge_contributing.
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 explains when to use each mode (greenfield for new projects, brownfield for migration, overview for decision tree), providing clear context. However, it does not explicitly compare to alternatives or state when not to use this tool, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run linting on the project. Supports ESLint and formatting checks. Can auto-fix issues with the fix option.
| Name | Required | Description | Default |
|---|---|---|---|
| fix | No | Auto-fix lint issues | |
| format | No | Run Prettier format check (or fix if combined with fix: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that auto-fix is possible and support for multiple checks, but does not explicitly state if the tool modifies files (destructive) or whether it runs both checks by default. No annotations to clarify.
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 efficiently convey the tool's purpose and key capability. No redundancy or unnecessary detail.
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?
Description covers basic functionality but lacks default behavior (no parameters), output expectations, and prerequisites. With no output schema, return value is unclear.
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 covers 100% of parameters; description repeats schema info without adding new semantics beyond confirming 'fix' enables auto-fix and 'format' combines with fix. No additional constraints or examples.
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 runs linting on the project and supports ESLint and formatting checks. It distinguishes from sibling tools like pm_build and pm_test by specifying a different action (linting).
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?
No guidance on when to use this tool over alternatives (e.g., pm_review_run, pm_test). Does not mention prerequisites or context where linting is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the review checklist for a given PM specialty. Returns a structured checklist of items reviewers should verify.
| Name | Required | Description | Default |
|---|---|---|---|
| specialty | No | Specialty to get checklist for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return type (structured checklist) but not authentication, side effects, or rate limits. Adequate for a simple read operation.
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?
One sentence of 13 words, concise and front-loaded. No redundant 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?
Adequate for a simple getter with one parameter and no output schema. Slightly ambiguous about 'PM' context (project management vs. code review), but functional.
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 already describes parameter 'specialty' with enum values and description. Tool description adds no new semantic info beyond 'for a given PM specialty'. Baseline 3 for 100% coverage.
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?
Clearly states verb 'Get' and resource 'review checklist' with context of 'PM specialty'. Distinguishes from sibling tool 'pm_review_run' which likely runs reviews.
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?
No explicit usage guidance, when-not to use, or alternatives provided. Implied usage is to retrieve checklists, but lacks constraints or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run automated checks relevant to a given specialty domain. Executes lint, typecheck, or test commands to validate code quality.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain to check: all (lint+typecheck), frontend (lint frontend), backend (lint server), types (tsc --noEmit) | |
| fix | No | Auto-fix lint issues when possible |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the full burden. It mentions executing commands but does not disclose that the 'fix' parameter auto-fixes lint issues, nor does it describe side effects, resource usage, or output behavior.
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 concise sentences that directly state the purpose and actions. No redundant information, and the structure is efficient.
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?
Adequate for a tool with fully described parameters, but missing context about output format, blocking behavior, or integration with other tools. Does not leverage sibling tools for differentiation.
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%, with both parameters having clear descriptions in the schema. The description adds minimal extra meaning beyond paraphrasing the domain concept. Baseline 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?
Description clearly states it runs automated checks for a specialty domain, mentioning lint, typecheck, and test commands. However, it does not explicitly differentiate from sibling tools like pm_lint or pm_test, which could create confusion.
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?
No guidance on when to use this tool vs. alternatives such as pm_lint or pm_test. The description lacks context about prerequisites or conditions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Roll back the deployment to the previous Docker image.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a destructive mutation (rolling back a deployment) but does not detail side effects, error states, or the availability of a previous image. With no annotations, the description carries the full burden and is minimally 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?
The description is a single concise sentence with no extraneous words. It efficiently communicates the tool's purpose.
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 of the tool (no parameters, no output schema), the description is minimally complete. However, it could benefit from specifying prerequisites (e.g., a previous deployment must exist) or behavior when no previous image is available.
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?
There are zero parameters, so the baseline is 4. The description adds no parameter details, which is acceptable since the schema already covers all (nonexistent) 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 clearly states the action ('roll back') and the resource ('deployment to the previous Docker image'), providing a specific verb-noun combination. However, it does not differentiate from sibling tools like pm_deploy, which performs forward deployment.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., pm_deploy), nor are there any prerequisites or conditions mentioned. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provision the VPS with Docker, Dockge, Traefik, and SSH setup.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing behavioral traits like idempotency, destructiveness, or prerequisites. For a provisioning tool, this is a major 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?
Single sentence, zero waste. Perfectly concise and front-loaded with essential 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?
No output schema, and the description does not explain what happens after provisioning (e.g., expected state, side effects). For a tool with a fixed sequence, more detail is warranted.
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?
There are no parameters, and schema coverage is 100%. Baseline is 3 since the description cannot add meaning beyond the schema. No additional parameter info is needed.
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 verb 'Provision' and the resource 'VPS' with specific components (Docker, Dockge, Traefik, SSH). It distinguishes the tool from siblings like pm_build or pm_dev by focusing on initial infrastructure setup.
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?
No guidance on when to use this tool versus alternatives like pm_init or pm_deploy. The description lacks context for decision-making among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Display full Puppet Master project status: config mode, database state, dev server, enabled modules, features, and sections.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Level of detail to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. The word 'Display' indicates a read-only operation without side effects. However, it does not mention authentication requirements, access levels, or potential limitations. For a status tool, this is adequate but could be more explicit.
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 efficiently conveys the tool's purpose and scope. No redundant or extraneous information is present.
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 simplicity (one optional parameter, no output schema), the description adequately covers the main functionality by listing what status includes. It could mention that the 'detail' parameter controls the output, but the schema already provides that. The description is complete enough for an agent to understand the tool's behavior.
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 the parameter 'detail' with its enum values. The description adds no additional meaning beyond listing the status components, which indirectly relates to the parameter. Thus, the description adds minimal value over the schema.
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 verb 'Display' and the resource 'full Puppet Master project status', and lists specific components like config mode, database state, dev server, enabled modules, features, and sections. It distinguishes itself from sibling tools (e.g., pm_config_get, pm_dev) which are more focused.
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 does not provide explicit guidance on when to use this tool versus alternatives, such as pm_config_get for configuration details or pm_dev for server status. The purpose is implied but not elaborated with exclusions or specific contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run tests for the Puppet Master project. Supports unit tests, API tests, E2E tests (Playwright), and the full staged suite.
| Name | Required | Description | Default |
|---|---|---|---|
| suite | No | Test suite to run: unit, api, e2e, e2e:playwright, staged (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'run tests', omitting side effects, prerequisites, output format, or whether it modifies state (likely not). This is insufficient for an AI agent.
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, no fluff, front-loaded with the main purpose. 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?
Given 1 optional parameter and no output schema or annotations, the description covers the basic suite options but lacks explanation of 'staged', prerequisites, or example usage. It is adequate but not complete.
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 has 100% description coverage, so baseline is 3. The description adds value by enumerating the suite options (unit, api, e2e, e2e:playwright, staged), providing context beyond the schema.
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 verb 'Run tests' and the resource 'Puppet Master project', listing specific test types. It distinguishes from siblings like pm_build and pm_lint by focusing on test execution.
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 lists supported test suites (unit, API, E2E, staged), implying when to choose which. However, it does not explicitly state when not to use this tool or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have clearly distinct purposes, such as separate tools for config get/set, each database operation, and contribution actions. However, there is potential overlap between pm_contribute_list and pm_knowledge_contributing, and between pm_knowledge variations, which causes slight ambiguity.
Tools consistently use the 'pm_' prefix, but naming patterns vary: some are single-word verbs (pm_build, pm_init) while others follow a noun_verb pattern (pm_config_get, pm_db_migrate). This inconsistency, though not chaotic, reduces predictability.
With 26 tools, the set is on the higher side but remains well-scoped to the Puppet Master ecosystem, covering development, database, deployment, contributions, and knowledge. A few tools could be consolidated (e.g., knowledge and contribute overlap), but overall the count is appropriate.
The tool surface covers the main lifecycle: init, dev, build, test, lint, config, db operations, deploy, rollback, and contributions. Some areas like monitoring or version management are absent but are not core to the stated purpose. Minor gaps exist, such as no direct tool for managing environment variables.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
327 dev tools via REST API and MCP. Generate Dockerfiles, schemas, K8s, APIs, and more.
Manage repositories, users, releases, and automate GitHub workflows
Plain-English git via MCP: 22 tools to branch, commit, push, and tag. No git jargon.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ldco/pm-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
