Skip to main content
Glama
Sign In
mcp-roadmapsh

mcp-roadmapsh

by aissablk1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

progress_mark

Track your learning progress on roadmap.sh by marking topics as learning, done, or skip, with status saved locally.

Instructions

Mark a roadmap topic as learning, done, or skip (stored locally).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "roadmap": "<roadmap>",
      "nodeId": "<nodeId>",
      "status": "<status>"
    },
    "name": "progress_mark"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNo
nodeIdYes
statusYes
roadmapYesroadmap.sh slug, e.g. 'frontend'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already indicate non-read-only, non-idempotent, and non-destructive behavior. The description adds the useful detail that progress is stored locally, which gives some context about persistence, but it does not disclose how repeated calls behave (e.g., overwrite vs. append) or whether any authentication or special states are required. This is acceptable given the tool's simplicity.

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?

The description is a single sentence that delivers the core action, targets, and storage location with no wasted words. It is front-loaded and immediately comprehensible.

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?

For a low-complexity tool (4 simple params, no output schema) with annotations already covering safety, the description provides the essential purpose and scope. It misses guidance on parameter details and when to use the tool, but given the simple nature and sibling context, it is largely sufficient.

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 only 25% (only 'roadmap' has a description). The description partially compensates by stating the status values (matching the enum) and implying 'roadmap topic' corresponds to nodeId. However, it does not clarify the 'label' parameter, and the schema itself leaves label and nodeId semantically underspecified. The description adds some meaning but not enough to fully cover the gaps.

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

Purpose5/5

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

The description specifies a clear verb ('mark') and resource ('roadmap topic'), and uniquely identifies the action by enumerating the valid statuses (learning, done, skip). It distinguishes this tool from sibling progress tools (progress_status, progress_next) by focusing on the mutation/update action rather than reading or suggesting.

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?

The description implies usage for updating progress on a roadmap topic, but does not explicitly state when to prefer this over alternatives like progress_status or progress_next. No exclusion criteria or sibling references are provided, though context suggests it is for recording progress rather than viewing it.

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