Skip to main content
Glama
Sign In
create-starter

create-starter

by starter-series
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

audit_cd

Check if your repo's version is live on npm, PyPI, Open VSX, VS Marketplace, AMO, or GitHub Releases; report drift per destination without changing files.

Instructions

Check whether the local repo's version has been published to its destination registries (npm, PyPI, Open VSX, VS Marketplace, AMO, GitHub Releases). Makes outbound HTTPS requests to public registry APIs; never mutates. Reports per-destination drift (in-sync / needs-publish / local-stale / not-found).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "audit_cd"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoPath to the repo to audit (default: the MCP server's cwd). Use the absolute path of the project the user is working in.

Output Schema

NameRequiredDescriptionDefault
overallYes
repoPathYes
destinationsYes
localVersionYes
versionSourceYes
matchedStarterYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.5.3
    • removedOutput schema / properties / destinations / items / properties / publishedAt / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedOutput schema / properties / destinations / items / properties / publishedAt / type
      Added value: +[
+  "string",
+  "null"
+]
    • removedOutput schema / properties / destinations / items / properties / publishedVersion / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedOutput schema / properties / destinations / items / properties / publishedVersion / type
      Added value: +[
+  "string",
+  "null"
+]
    • removedOutput schema / properties / localVersion / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedOutput schema / properties / localVersion / type
      Added value: +[
+  "string",
+  "null"
+]
    • removedOutput schema / properties / matchedStarter / properties / id / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedOutput schema / properties / matchedStarter / properties / id / type
      Added value: +[
+  "string",
+  "null"
+]
  2. First observedv0.4.0

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral burden and does well: it discloses that the tool makes outbound HTTPS requests to public registry APIs and never mutates, plus enumerates the four outcome states (in-sync / needs-publish / local-stale / not-found). It stops short of noting network-failure behavior or rate limiting, so it is strong 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with zero filler: purpose first, then network/read-only behavior, then the returned states. Front-loaded and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be re-explained, and the description already summarizes the read-only network profile and drift outcomes. The only material gap is the lack of differentiation from the audit_release sibling, which matters in this crowded audit_* family.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single 'path' parameter is already fully documented in the schema, including its default. The description adds no additional parameter syntax or semantics, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Check whether the local repo's version has been published to its destination registries', and enumerates the exact registries (npm, PyPI, Open VSX, VS Marketplace, AMO, GitHub Releases). However, it does not distinguish itself from the similarly-named sibling audit_release, leaving the agent to infer the boundary between the two.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied (verify publish state of a local release before/after publishing), but there is no explicit when-to-use, when-not-to-use, or routing to an alternative such as audit_release. Nothing tells the agent which of the several audit_* siblings is appropriate for a given situation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools