Public assessment

microservices-sh/mcp (@microservices-sh/mcp)

microservices-sh-mcp · v0.1.3 · scanned Aug 2, 2026

What changed in the harness

Selection accuracy 100→100, token cost up 2%, unconfirmed writes 0%→0%.

Category breakdown

Where the score comes from.

Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.

01Safety

0.0 / 30

0.0 out of 30

02Legibility

24.6 / 30

24.6 out of 30

03Economics

18.9 / 20

18.9 out of 20

04Discoverability

11.1 / 20

11.1 out of 20

Highest-impact fix

Estimated gain +30 points

Add explicit identity and permission preflight tools

Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.

Description evidence

Defects and rewrites.

16 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.

Tool	Defect types	Suggested rewrite
`list_templates`	no_return_description	Returns the list of available microservices.sh app templates, including each template's id and summary. Use this before inspect_template, compose_app, generate_project, or run_checks when choosing a foundation for a new Cloudflare app.
`inspect_template`	no_return_description	Returns the contract for one app template, including its supported modules, default configuration, runtime metadata, and generation behavior. Use this before composing or generating a project from a specific template id.
`list_modules`	no_return_description	Returns the list of available verified microservices.sh modules, including each module's id, category, summary, version, and maturity status. Use this to discover production building blocks before inspect_module, compose_app, or plan_add_module.
`inspect_module`	no_return_description	Returns the detailed contract for one module, including its permissions, hooks, events, resources, storage needs, and customization points. Use this before editing or adding a module so the agent understands the module boundaries.
`list_module_docs`	no_return_description	Returns the list of LLM-readable documentation pages available for module implementation guidance, including each page's id and title. Use this to discover local docs before get_module_doc or before changing generated source.
`compose_app`	no_return_description	Returns a checked app contract and lockfile plan composed from a template and selected modules, without writing files. Use this to preview the exact app composition before generate_project or deployment planning.
`validate_config`	no_return_description	Returns validation results, including any errors and warnings, for a template, module list, and configuration object before generation or deployment. Use this to catch unsupported modules, missing settings, and invalid config before side effects.
`generate_project`	no_return_description	Returns the generated project source files, docs, migrations, and config in memory for agent inspection, without writing files to disk. Use this to review planned output before creating or editing a local project.
`run_checks`	no_return_description	Returns the results of local contract and readiness checks for a template/module composition, including module compatibility, generated-artifact, and operational-guardrail findings. Use this before deployment planning.
`plan_add_module`	no_return_description	Returns a plan for an approval-gated module addition against an optional existing microservices.lock.json, including intended lockfile changes and required review gates, without writing files.
`check_updates`	no_return_description	Returns available module updates by comparing locked module versions against the bundled registry snapshot. Use this to identify updates before plan_module_upgrade.
`plan_module_upgrade`	no_return_description	Returns a plan for a module version change, including approval gates, compatibility notes, and lockfile impact. Use this before applying a module upgrade.
`get_secrets_status`	no_return_description	Returns the required secret names and their configured/missing status for a template/module composition, without exposing secret values. Use this before deployment planning or remote preview deploys.
`create_preview_plan`	no_return_description	Returns a local preview-deployment readiness plan, including resources, checks, errors, warnings, and required approval steps, without mutating remote state. Use this before deploy_preview.
`deploy_preview`	no_return_description	Prepares a remote preview deployment through the microservices.sh control plane and returns the deployment record, including its id and status. This is a mutating tool and requires confirm: preview; call create_preview_plan first and only proceed after human review.
`get_deployment_status`	no_return_description	Returns the current status, metadata, and any errors for a remote preview deployment from the microservices.sh control plane. Use this after deploy_preview to poll status or retrieve deployment metadata.

Selection evidence

Confusable tool pairs.

8 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A	Tool B	Confidence	Why they collide
`list_modules`	`list_module_docs`	medium	A task like "show me what module info is available for auth" could plausibly be routed to either the module registry list or the docs list, since both enumerate module-related resources without specifying which kind of listing is needed.
`list_modules`	`inspect_module`	low	Both concern modules broadly, but one lists all and the other inspects a single one by id; a vague task like 'tell me about the payment module' could tempt an agent to call list_modules instead of inspect_module if it doesn't yet know the exact id, though the descriptions make the distinction fairly clear.
`list_module_docs`	`get_module_doc`	low	A request like "get me the documentation for the booking module" could be satisfied by either listing available docs or fetching a specific doc directly if the agent assumes the moduleId is valid without checking the list first, though get_module_doc's required moduleId parameter makes intent fairly distinguishable.
`plan_add_module`	`plan_module_upgrade`	medium	Both are approval-gated planning tools operating on module id/version and lockfile; a task like "plan adding payment@0.2.0" when payment is already installed could be ambiguous between adding it fresh or upgrading the existing version, especially if the agent isn't sure whether the module is already locked.
`get_secrets_status`	`get_deployment_status`	low	Both are 'get_*_status' read tools related to deployment readiness, but they operate on entirely different inputs (composition config vs deploymentId) and different purposes (secrets vs remote deployment state), making confusion unlikely for a clear task.
`create_preview_plan`	`deploy_preview`	medium	A task like "deploy a preview of this app" could cause an agent to call the mutating deploy_preview directly instead of first creating a local plan, since both tools accept the same templateId/modules/config composition parameters and the difference (planning vs mutating) is only clear from reading descriptions closely.
`inspect_template`	`inspect_module`	low	Both use an 'inspect_X' pattern with a single id parameter for detailed contract inspection, so a vague task like "inspect booking" could be ambiguous if the agent doesn't know whether 'booking' refers to a template id or module id, though the parameter descriptions give distinguishing examples.
`list_templates`	`list_modules`	low	Both are no-argument discovery/listing tools returning available building blocks (templates vs modules) for app composition; a generic task like "what's available to build with" could plausibly trigger either, though their descriptions clearly separate templates from modules.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard