DEV Community: ChangeCrab

StatusCake's entry for the new Hermes challenge, we're having a think about an entry for this one ourselves!

ChangeCrab — Tue, 19 May 2026 12:07:08 +0000

Hermes Agent Challenge Submission

StatusCake

May 19

Turn StatusCake into a verified alerting flow with Hermes

#hermesagentchallenge #devchallenge #agents #monitoring

Comments

6 min read

Why Support Teams Need a Changelog and Roadmap

ChangeCrab — Tue, 19 May 2026 11:15:27 +0000

Why Support Teams Need a Changelog and Roadmap

Most teams do not realise they need a changelog when everything is going well.

They realise it when support keeps getting the same question:

Where can I see what changed?

Or:

Do you have a roadmap?

That is the painful version of the problem. Not "we should publish release notes because it would look nice." Not "we need a changelog because other SaaS companies have one." The real pain shows up when customers, prospects, and internal teams need proof that the product is moving, and support has nowhere good to send them.

When that happens, every product update becomes a private conversation. Support replies manually. Sales gives a rough answer. Customer success checks Slack. Founders rewrite the same explanation in different threads. Meanwhile, customers are left wondering whether the product is improving at all.

A good changelog and product roadmap solve that problem by giving everyone one reliable place to see what changed, what is coming, and why it matters.

Support Teams Feel Product Communication Problems First

Support is often the first team to notice when product communication is broken.

Customers do not usually frame the problem as "your release communication process needs work." They ask practical questions:

"Did you fix that bug yet?"
"Where can I see recent updates?"
"Is this feature planned?"
"Has anything changed since I last tried this?"
"Can you send me your roadmap?"

Without a public changelog or roadmap, every answer depends on whoever is replying. One support agent may know the feature shipped last week. Another may not. A customer success manager may remember a Slack update. A new teammate may have to ask engineering.

That creates inconsistent answers, slower replies, and unnecessary internal noise.

It also makes the product look quieter than it really is. Your team may be shipping constantly, but if customers cannot see those improvements, the product can feel stagnant from the outside.

The Hidden Cost of Not Having a Changelog

Not having a changelog rarely feels urgent at first. Early teams often move fast, talk directly to customers, and keep product context in their heads.

That works until the customer base grows.

Then the same missing changelog creates several quiet costs.

Support answers the same question repeatedly

If users keep asking what changed, support has to reconstruct the answer from memory, tickets, pull requests, or internal chat. That is slow, repetitive work.

A changelog turns those replies into a simple link:

"Here are the latest updates."

That link saves time, but it also gives the answer more authority. The customer is not just hearing a one-off support reply. They are seeing an official product update.

Customers miss improvements they asked for

One of the most frustrating support moments is when a customer asks for a feature that already exists.

Sometimes they requested it months ago. Sometimes it shipped quietly. Sometimes nobody closed the loop.

That is a missed trust-building opportunity.

Every shipped improvement is a chance to tell users:

"We listened. This got better."

If the update is never published, customers may assume nothing happened.

Prospects cannot see product momentum

A changelog is not only for existing users. It also helps prospects evaluate whether a product is alive, improving, and worth betting on.

For many SaaS buyers, especially in competitive categories, product momentum matters. They want to know:

Is this team actively shipping?
Are bugs being fixed?
Are customer requests turning into improvements?
Does the product have a clear direction?

A public changelog and roadmap give prospects visible evidence without requiring a sales call.

Internal teams lose a shared source of truth

When product updates live in scattered places, internal teams drift out of sync.

Engineering knows what shipped. Product knows what changed. Support knows what customers are asking. Sales knows what prospects care about. But without a shared customer-facing record, everyone builds their own version of the story.

A changelog gives the team a simple reference point:

What shipped
When it shipped
Who it affects
Why users should care

A roadmap adds the forward-looking version:

What is planned
What is being considered
What customers can expect next

Together, they reduce ambiguity.

A Changelog Is Not Just Release Notes

Many teams think a changelog means a technical list of commits, bug fixes, and version numbers.

That is one type of changelog, but it is not the most useful one for most SaaS customers.

Customers usually do not care that you "refactored the export service" or "updated the billing dependency." They care about what changed for them:

Can I do something faster?
Is something more reliable?
Did a workflow become easier?
Is a bug that affected me fixed?
Is a feature I requested now available?

The job of a customer-facing changelog is to translate shipped work into customer outcomes.

Internal change:

Added CSV export filters.

Customer-facing update:

You can now export only the data you need by filtering CSV exports before download.

That small translation is the difference between a changelog that merely records work and a changelog that helps customers notice value.

Why a Roadmap Belongs Next to Your Changelog

A changelog answers:

What changed?

A roadmap answers:

What is coming next?

Support teams usually need both.

When a customer asks whether a feature is planned, support needs a better answer than "we will pass that along." A public roadmap gives the team a structured place to point customers, collect interest, and set expectations.

That does not mean every company needs to publish a detailed, date-based roadmap. In many cases, that creates more pressure than clarity.

A useful SaaS roadmap can be simple:

Planned
In progress
Under consideration
Recently shipped

The point is not to promise everything. The point is to make product direction visible enough that customers feel included instead of left guessing.

What a Good Changelog and Roadmap Should Do

A good changelog and roadmap should make life easier for support, not create another publishing burden.

At minimum, they should help your team:

Give support one link for "what's new?"
Give customers one place to check product progress
Turn shipped work into clear user benefits
Show prospects that the product is actively maintained
Close the loop when requested features ship
Keep internal teams aligned on product communication

The best version is lightweight. Capture changes as they happen, clean them up into customer-friendly language, and publish the updates that actually matter.

You do not need to announce every tiny internal change. You do need a consistent place for meaningful product progress.

When Should a SaaS Team Create a Changelog?

The right time to create a changelog is earlier than most teams think.

You probably need one if:

Customers ask what has changed recently
Support gets repeated questions about shipped fixes
Prospects ask how active the product is
Users request features that already exist
Your team ships often but rarely announces updates
Product context is scattered across Slack, tickets, docs, and memory
Support has no reliable place to send people for product progress

If any of those are true, the problem is already showing up. A changelog is not just a nice public page. It is a support tool, sales asset, retention signal, and product communication habit.

How ChangeCrab Helps

ChangeCrab is built around this exact problem: teams ship real improvements, but customers and internal teams do not always have one clean place to see them.

With ChangeCrab, you can create a public changelog and roadmap for your product, publish customer-friendly updates, and give support a reliable link whenever someone asks what changed or what is coming next.

Instead of rebuilding the story from Slack threads, tickets, and memory, your team can keep product updates in one place.

That helps support answer faster. It helps customers see progress. It helps prospects understand momentum. And it helps your product feel as alive from the outside as it is on the inside.

FAQ

Do SaaS companies need a changelog?

Most SaaS companies benefit from a changelog once customers start asking about product updates, bug fixes, feature requests, or roadmap progress. A changelog gives users and internal teams one place to see what changed.

What is the difference between a changelog and release notes?

Release notes often describe a specific release. A changelog is an ongoing record of product changes over time. For SaaS teams, the most useful changelog explains product updates in customer-friendly language.

Should a product roadmap be public?

A public roadmap can help customers and prospects understand product direction, but it does not need to include exact dates or every internal plan. Many teams use simple statuses like planned, in progress, and recently shipped.

How does a changelog help customer support?

A changelog helps support teams avoid repeated manual explanations. When users ask what changed, whether a bug was fixed, or whether the product is still improving, support can send one reliable link.

What should a changelog include?

A customer-facing changelog should include meaningful product updates, feature releases, bug fixes that affect users, workflow improvements, and clear explanations of why each change matters.

One Reliable Place for Product Progress

The strongest reason to create a changelog is not marketing polish. It is operational clarity.

When users ask where your changelog or roadmap is, they are really asking:

Is this product improving, and can I trust the team behind it?

If support has no good answer, the product feels less mature than it may actually be.

Give support, sales, customers, and prospects one reliable place to see product progress. That simple shift turns product updates from scattered internal knowledge into visible customer trust.

Gemma 4 Challenge: Gemma Sonar Scout

ChangeCrab — Fri, 08 May 2026 15:38:47 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

I built Gemma Sonar Scout, a local monitoring tool that watches supplier and dependency changelogs, release feeds, and status pages, then turns the new evidence into a daily operator brief.

The problem is simple: modern products depend on a stack of external services. Cloud hosts, DNS providers, payment processors, API platforms, AI tools, CI systems, and support platforms all publish important changes in different places. Some updates are harmless. Some are breaking changes. Some are outages that matter immediately.

Gemma Sonar Scout has two layers:

A deterministic scanner fetches configured sources, parses RSS, Atom, Statuspage-style incident JSON, plain JSON, and basic public HTML, detects severity/categories, hashes events, and tracks local state so the digest can focus on what is new.
A Gemma 4 summarization layer receives the structured evidence and produces a concise daily brief: headline, alert level, summary, recommended actions, and event-level reasoning.

That split is intentional. The model does not decide whether an outage happened or invent sources. The scanner builds the evidence packet; Gemma 4 makes the evidence readable and actionable.

The tool can run as a local cron job and outputs both markdown and a browser-friendly HTML report.

Example:

sonar-scout scan \
  --config examples/hosting-dependencies.json \
  --include-seen \
  --output daily-digest.md \
  --html-output daily-report.html

The bundled demo config watches providers like DigitalOcean, Cloudflare, GitHub, Vercel, Render, and Fly.io.

Demo

Demo video: Here

Local demo with Ollama running locally:

python3 -m pip install --upgrade pip setuptools wheel
python3 -m pip install -e .
PYTHONPATH=. python3 -m sonar_scout demo \
  --gemma-base-url http://localhost:11434/v1 \
  --gemma-model gemma4:e4b \
  --output demo-digest.md \
  --html-output demo-report.html

For a report like the recorded hosting demo:

PYTHONPATH=. python3 -m sonar_scout scan \
  --config examples/hosting-dependencies.json \
  --include-seen \
  --gemma-base-url http://localhost:11434/v1 \
  --gemma-model gemma4:e4b \
  --output demo-digest.md \
  --html-output demo-report.html
python3 -m http.server 8877 --bind 127.0.0.1

Then open:

http://127.0.0.1:8877/demo-report.html

For the recorded demo I used the bundled hosting config and public status-page examples from DigitalOcean, Cloudflare, GitHub, Vercel, Render, and Fly.io.

Code

Repository: https://github.com/changecrab/gemma-sonar-scout

Key files:

sonar_scout/fetchers.py parses RSS, Atom, Statuspage incident JSON, basic HTML, and local fixture files.
sonar_scout/detectors.py handles deterministic severity, category, and stable event-hash detection.
sonar_scout/gemma.py sends the structured evidence packet to a local OpenAI-compatible Gemma endpoint.
sonar_scout/render.py renders markdown and HTML reports.
examples/hosting-dependencies.json is a practical demo config for public hosting/status providers.

How I Used Gemma 4

I used Gemma 4 E4B-it as the target model.

I chose E4B-it because the project is designed to run locally and repeatedly. A supplier-monitoring digest is exactly the kind of workflow where local AI makes sense: the raw operational context can stay on the user's machine, and the model only receives a compact evidence packet assembled by deterministic code.

E4B-it is a good fit because it offers a practical balance:

Small enough to fit the local-first story better than a large hosted-only model.
Capable enough to summarize messy multi-provider evidence better than a tiny edge model.
Useful for long daily context windows when a team monitors many vendors.

Gemma 4 receives JSON shaped like this:

{
  "events": [
    {
      "id": "stable-event-id",
      "monitor": "Cloudflare",
      "source_type": "status",
      "title": "Network connectivity issue",
      "published_at": "2026-05-08T10:00:00Z",
      "severity": "warning",
      "categories": ["reliability"],
      "url": "https://status.example/incidents/example",
      "content": "Evidence text from the public incident update"
    }
  ]
}

It returns structured JSON:

{
  "headline": "short headline",
  "alert_level": "quiet|normal|watch|urgent",
  "executive_summary": "4-6 sentence summary",
  "recommended_actions": ["action 1", "action 2"],
  "notable_events": [
    {
      "event_id": "stable-event-id",
      "why_it_matters": "short explanation"
    }
  ]
}

This keeps the application testable and trustworthy. The scanner is responsible for evidence. Gemma 4 is responsible for synthesis.

The tool also works without Gemma via --no-gemma, which makes it easy to review, test, and demo before a local model server is running. When Gemma 4 is available, the same scan becomes a much better daily brief.

Why This Matters

Supplier change monitoring is often either too manual or too noisy. Teams do not need another raw feed; they need a quick answer to:

What changed since yesterday?
Which changes could affect us?
What should someone check next?

Gemma Sonar Scout is a local, transparent version of that workflow.

Note: Gemma Sonar Scout is a free and simplified, local-AI adaptation of the monitoring engine we use at ChangeCrab. If you don't want to host this yourself, need something a little more robust - and just want the alerts in your Slack/email, check out ChangeCrab Sonar.

Beyond Competitors: How to Use ChangeCrab Sonar to Monitor Your Dependencies

ChangeCrab — Fri, 08 May 2026 10:45:15 +0000

Introduction

Modern products and modern teams are built on and reliant upon a number of dependencies, from hosting providers, payment gateways, email APIs, to third party widgets and feeds. When these providers go down, it can cause internal havoc and confusion, it only takes one small breaking change in a dependency to impact users of your service in unexpected ways. Teams often find themselves drudging through status pages and looking for third party reports to get an idea of what’s going on, and that’s if there’s even enough information to suspect a third party in the first place.

Sonar, although it’s mainly geared towards competitor updates, is: by it’s nature a perfect tool for keeping a close eye on all of this. The underlying engine is keeping watch on Status Pages and changelogs, so you can be in the know when any reputable public company breaks or changes - automatically.

In this post we’ll take you through how to set Sonar up and use it effectively for this case.

Cutting Through the Noise

It’s easy to miss an important API deprecation notice or a minor feature release from your hosting provider because it got buried in an overflowing inbox. Providers change things constantly, and relying on email alerts or fragmented Twitter updates just doesn’t scale for a serious engineering team.

The real pain comes during an outage. Your app breaks, your team wastes a crucial hour debugging your own code, only to finally realize it’s an unannounced third-party API outage causing the bottleneck.

By feeding your dependencies into Sonar instead of your competitors, you create a single source of truth for your entire stack’s health and evolution.

Setting Up Your Dependency Radar

Flipping Sonar from a competitor intelligence tool to an infrastructure monitor is straightforward. Here is how to get your workspace set up:

Re-think the Setup Wizard: Instead of pasting in the URLs of rival companies, paste the primary URLs of your critical infrastructure. Think Vercel, Stripe, SendGrid, AWS, or your database host.
Let Discovery Do the Heavy Lifting: Sonar’s engine automatically hunts down their public changelogs, RSS feeds, and most importantly, their public status pages. If Sonar happens to miss a niche provider’s specific status page, you can easily add the direct link manually to ensure you have total coverage.
Customize Your Views: Filter your new workspace to focus on specific layers of your stack. You can group things logically, separating "Hosting & Infrastructure" from "Billing & Payments" so the right team members can see what matters to them.

What You Actually Get

Once your providers are plugged in, Sonar transforms into a dedicated command center for your stack. Here is where the real value comes in:

Unified Status Monitoring: Instead of bookmarking and checking ten different status pages when something feels broken, you just check your Sonar workspace. It tracks active outages alongside scheduled maintenance events, so you're never caught off guard.
Catching API Updates & Deprecations: You can use the "Shipping Heartbeat" chart to see exactly how often your dependencies are changing. A sudden spike in updates from an API provider is a strong signal that they might be rolling out a major - and potentially breaking - new version.
Automated Stack Briefs: Instead of generating a competitive readout, you can use our AI to generate a weekly brief on your dependencies. It’s perfect for engineering Monday meetings: simply pull a summary of exactly what your core infrastructure providers shipped last week.

Hooking It Into Your Workflow

To get the most out of this setup, you don't even need to keep the ChangeCrab dashboard open.

You can push Sonar activity directly into your team's Slack, Discord, or project management tools via webhooks. When a dependency’s status page updates to reflect an outage, your dev team gets alerted instantly where they already work. You can also utilize Sonar's "Signals" to spot theme matches, tracking specifically when a dependency announces security patches or compliance updates that require your immediate attention.

Wrapping Up

You can't control what your third-party providers do, but you can entirely control how quickly your team reacts to them. Sonar gives you that speed and visibility.

Log into your ChangeCrab account, navigate to Sonar, and start adding your top 5 dependencies today to see it in action.

Note: Sonar is included in our Premium plan ($19.95/mo) and is available to preview for free accounts.

How to automate newsletters without sacrificing quality

ChangeCrab — Thu, 07 May 2026 08:25:51 +0000

Most newsletter automation fails for one of two reasons.

The first is that it barely automates anything meaningful. It schedules an email, maybe pulls in a couple of links, and still leaves a human doing all the real work: deciding what matters, tightening the copy, checking the sources, and making sure the finished piece is actually worth sending.

The second is worse. It automates too much, too blindly, and produces low quality content which erodes trust every time it lands in someone’s inbox.

The useful middle ground is much more practical.

You do not automate the judgement. You automate the workflow around the judgement.

That is the version that gets interesting, and it is exactly where a combination like ChangeCrab + OpenClaw starts to become genuinely powerful.

Why most AI newsletter automation feels dead on arrival

A lot of teams approach newsletter automation with the wrong goal.

They ask, “How do we get AI to write the newsletter for us?”

That sounds efficient, but it usually produces one of two bad outcomes:

something generic and forgettable
something fast, wrong, and slightly embarrassing

The real bottleneck in a good newsletter is rarely typing speed. It is curation.

A newsletter becomes worth reading when someone has done the hard part well:

choosing what deserves attention
rejecting what looks noisy or thin
finding a useful angle
getting the tone right
publishing it in a form that still feels like it came from people who care

That is why the best automation model is not a one-shot prompt. It is a system that helps you move from research to draft to review to publication without losing the human layer that makes the whole thing credible.

What should actually be automated

When people talk about AI newsletter workflows, they often jump straight to the final draft.

That is usually a mistake.

The most useful things to automate are the boring, repeatable, operational parts that sit around the editorial judgement:

monitoring source lists
recurring discovery
collecting candidate links and updates
validating dates, titles, and basic facts
assembling drafts from approved material
scheduling review checkpoints
staging publication once approval is explicit

In other words, automation should carry the weight of the process.

Humans should still hold the part that affects trust.

That means being careful about:

claims you have not checked
images you do not clearly have the right to reuse
analysis presented as certainty
sending something customer-facing before a real person has signed it off

If you get that balance right, automation stops feeling gimmicky and starts feeling like leverage.

A better way to automate a newsletter workflow

The cleanest pattern is a staged editorial system.

For example, instead of treating the newsletter as one big writing task, you can break it into a week of smaller, smarter steps.

A typical flow might look like this:

Early-week discovery: collect candidate items, competitor signals, product updates, community chatter, or event links.
Validation pass: confirm which items are real, current, and actually worth including.
Draft assembly: turn the shortlist into readable copy with links and supporting notes.
Review stage: send the draft to a human editor or owner for approval.
Final refresh and publish: check anything time-sensitive, then publish once approval is explicit.

That structure is powerful because it reflects how strong newsletters are already made. It does not force AI to replace the editorial process. It simply gives the editorial process a dependable machine around it.

Where ChangeCrab fits

Once you have a workflow like that, you need a proper customer-facing place to publish.

That is where ChangeCrab becomes more than “the email tool.”

ChangeCrab already gives product teams a clean public surface for updates through:

hosted changelog pages
email delivery
RSS
widgets
subscriber flows
feedback and suggestions

That matters because a newsletter should not always be treated like a disposable email blast. When each edition also lives on a hosted page, it becomes easier to share, easier to revisit, and easier to turn into a long-term content asset.

For teams already using ChangeCrab for customer-facing product communication, that is especially valuable. You are not introducing an unrelated publishing system. You are extending an existing communication surface with stronger automation behind it.

Where OpenClaw fits

OpenClaw is what makes the workflow operationally realistic.

Instead of relying on memory, manual reminders, or a single frantic writing window, you can use scheduled workers to keep the process moving.

That might mean:

checking source feeds on a schedule
collecting and ranking leads
merging in public signals from communities or search
generating internal drafts in markdown or HTML
waiting for explicit approval before publish
sending through a repeatable cadence without the whole thing falling apart when the week gets busy

That is a much more useful form of AI automation than the “type one prompt and hope” model.

It gives you consistency without forcing you to hand over taste.

The real advantage: speed without rot

This is the part people underestimate.

A good automated workflow does not just make a newsletter faster. It makes it easier to keep the quality from decaying as the schedule repeats.

That matters because newsletter projects often die in one of two ways:

they become too manual to sustain
they stay alive, but turn into stale, low-trust filler

A staged system helps you avoid both.

You can keep the cadence consistent without pretending every issue should be written from scratch in one sitting, and you can keep quality higher because the workflow itself forces discovery, checking, drafting, and review into separate steps.

That is a much healthier model than “the AI wrote it, let’s send it.”

What to avoid

If you want newsletter automation to remain useful rather than becoming a content mill, there are a few traps worth avoiding.

Do not automate publication before you have automated discernment.
If the upstream sourcing is noisy, scaling the output just scales the damage.

Do not let the system sound like the system.
Readers should never feel like they are consuming a process artifact. They should feel like they are reading something written for them.

Do not confuse analysis with prophecy.
AI can help identify patterns, surface candidates, and frame interpretations. It should not be used to perform certainty it has not earned.

Do not treat the email as the whole product.
The archive, the hosted page, the discoverability, and the long-term trust value matter too.

The version that is actually worth building

The best AI newsletter systems are not the ones that try to replace editorial judgement.

They are the ones that make editorial judgement easier to apply consistently.

That is the real promise here.

Use OpenClaw to keep the machine moving.
Use ChangeCrab to publish the result in a customer-facing way.
Keep humans in charge of what is worth saying.

If you do that well, you do not end up with an “AI newsletter.”

You end up with something much more valuable: a newsletter that is easier to produce, easier to trust, and much more likely to keep being worth reading.

OpenClaw + Changelog: A Technical Integration Guide for Developer Teams with ChangeCrab

ChangeCrab — Wed, 06 May 2026 12:10:11 +0000

Most changelog workflows fail for one reason: context switching.

Engineers ship in terminals and IDEs, then switch to a web UI to publish release notes. Product and DevRel teams draft updates in docs, then manually re-enter them in changelog tools. The friction is small each time, but high across a quarter.

If your team already runs OpenClaw, the ChangeCrab MCP server gives you a clean bridge:

OpenClaw orchestrates agent behavior and tool calls
MCP provides the protocol boundary
ChangeCrab MCP tools expose changelog operations over stdio
ChangeCrab API remains the source of truth for write operations

TL;DR: What You'll Need

OpenClaw CLI: Installed and configured (Node 22.14+ required, Node 24 recommended).

ChangeCrab Account: An active paid plan or trial.

API Key: Generated from ChangeCrab Settings -> API Keys.

Architecture: how requests actually flow

At runtime, the integration is a straightforward process chain:

OpenClaw loads an MCP server definition from its registry.
That definition launches changecrab-mcp-server as a stdio process.
OpenClaw sees ChangeCrab tools in its callable tool set.
When a user prompt implies changelog work, OpenClaw invokes a tool.
ChangeCrab MCP server translates that tool call into ChangeCrab HTTP API calls.
API responses are returned to OpenClaw as MCP tool output.

The key point: OpenClaw is orchestrator, ChangeCrab MCP server is translator, and ChangeCrab API is the system of record.

Prerequisites and version baseline

OpenClaw runtime and bootstrap

OpenClaw's recommended install path:

npm install -g openclaw@latest
openclaw onboard --install-daemon

OpenClaw currently documents Node 24 as recommended, with Node 22.14+ supported.

ChangeCrab account requirements

ChangeCrab API access is paid/trial only. You need:

an active paid plan or trial
an API key from Settings -> API Keys

ChangeCrab MCP server runtime

ChangeCrab MCP server package currently declares:

Node >=18
stdio MCP transport
required env var: CHANGECRAB_API_KEY

OpenClaw MCP registry: precise behavior and commands

OpenClaw's mcp set/list/show/unset commands manage stored MCP server definitions in OpenClaw config.

Important detail from OpenClaw docs: these commands manage config state; they do not guarantee the target server is reachable at command time.

Register ChangeCrab (npx path)

openclaw mcp set changecrab '{"command":"npx","args":["-y","changecrab-mcp-server"],"env":{"CHANGECRAB_API_KEY":"cc_your_api_key_here"}}'

Register ChangeCrab (local build path)

openclaw mcp set changecrab '{"command":"node","args":["/absolute/path/to/changecrab/mcp-server/dist/index.js"],"env":{"CHANGECRAB_API_KEY":"cc_your_api_key_here"}}'

Inspect and validate registration

openclaw mcp list
openclaw mcp show changecrab --json

Remove configuration

openclaw mcp unset changecrab

Tool profile implications in OpenClaw

OpenClaw documents that configured bundle MCP tools are available in normal coding and messaging profiles, but not in minimal.

So if the server is configured correctly but tools never appear in agent runs, check profile first.

Operationally:

minimal -> expect no bundled MCP tools
coding / messaging -> bundled MCP tools can be exposed
explicit deny policies can still block tool access

ChangeCrab MCP server internals (verified from source)

The server registers tool families in src/index.ts:

changelogs (registerChangelogTools)
posts (registerPostTools)
categories (registerCategoryTools)
static info tools (registerInfoTools)

It exits immediately when CHANGECRAB_API_KEY is missing.

Transport and process model

MCP server over stdio (StdioServerTransport)
process is intended to be spawned/owned by client runtime

API base and auth

From src/api.ts:

default base URL: https://changecrab.com/api
override via CHANGECRAB_API_BASE_URL (useful for testing)
auth header: X-API-Key

Retry behavior

Network requests use bounded retry logic:

max retries: 3
delay: incremental (500ms * attempt)
retryable classes include transient network errors (ECONNRESET, ETIMEDOUT, etc.)

Error mapping

Mapped status behaviors include:

401 -> invalid/missing API key guidance
403 -> subscription required guidance
404 -> resource not found/access denied guidance
>=500 -> service unavailable guidance

Exact tool surface (10 tools)

The current server test suite verifies a 10-tool surface:

list_changelogs
get_changelog
list_categories
list_posts
create_post
update_post
delete_post
get_changecrab_overview
get_changecrab_api_info
get_changecrab_limits_summary

This is useful for CI assertions when upgrading OpenClaw, MCP SDK, or the server package.

Tool-to-endpoint mapping (API contract view)

ChangeCrab API routes expose these core endpoints under authenticated middleware:

GET /changelogs
GET /changelogs/{id}
GET /changelogs/{id}/categories
GET /changelogs/{id}/posts
POST /changelogs/{id}/posts
PUT /changelogs/{id}/posts/{postId}
DELETE /changelogs/{id}/posts/{postId}

Docs endpoint:

[https://changecrab.com/api/documentation](https://changecrab.com/api/documentation)

A subtle but important write-path detail

In create_post and update_post, the server first fetches changelog details (GET /changelogs/{id}) and derives team from that response before writing.

This means post writes are effectively a two-step sequence:

resolve team context from changelog
execute post create/update with required fields (summary, markdown, team, plus visibility flags/categories)

For developers debugging write failures, this extra dependency is critical.

Production-grade setup patterns

Pattern A: managed package install (fastest path)

Good for most teams:

openclaw mcp set changecrab '{"command":"npx","args":["-y","changecrab-mcp-server"],"env":{"CHANGECRAB_API_KEY":"cc_live_key"}}'

Pros:

no local build step
easy to roll forward

Tradeoff:

runtime depends on package resolution/network behavior in your environment

Pattern B: pinned local artifact (more control)

Build once in your infra pipeline:

cd mcp-server
npm install
npm run build

Then register exact artifact path:

openclaw mcp set changecrab '{"command":"node","args":["/opt/integrations/changecrab-mcp/dist/index.js"],"env":{"CHANGECRAB_API_KEY":"cc_live_key"}}'

Pros:

deterministic binary path
simpler rollback/change management

Security and secret handling

API key placement

Prefer environment injection in MCP config (env) over inline prompt usage.

Principle of least privilege

Use a dedicated ChangeCrab API key for automation workflows; rotate if exposed.

Avoid accidental leakage

Do not echo full openclaw mcp show ... --json outputs in shared logs if they include inline secrets.

OpenClaw trust boundary

OpenClaw docs emphasize that MCP registry config and MCP runtime behavior are distinct concerns. Validate both:

definition exists (mcp show)
runtime/profile actually enables tool invocation

End-to-end validation checklist

After setup, validate in order:

Config saved:
- openclaw mcp list includes changecrab
Definition shape:
- openclaw mcp show changecrab --json
Profile supports MCP:
- not minimal
Read path works:
- ask OpenClaw to run list_changelogs
Write path works:
- create a draft post in a known changelog
Update/delete lifecycle:
- update then delete a test post

For local server testing, ChangeCrab also includes npm test in mcp-server/, which validates MCP handshake and tool registration behavior.

Prompting patterns that work well for teams

Use explicit IDs and intent to reduce back-and-forth:

"List changelogs and include IDs."
"For changelog <id>, list categories and recent posts."
"Create draft post in changelog <id> with summary X and markdown Y."
"Update post <post_id> in changelog <id> with this body, keep it draft."
"Publish by setting draft=0 and public=1."

When you need partial updates, remember current update_post behavior expects full required post fields, so pull current values first.

Failure modes and fast remediation

Startup fail: missing key

Symptom:

MCP process exits with required env var error

Fix:

ensure CHANGECRAB_API_KEY is present in registered server env

401 on API tools

Symptom:

read/write tools fail immediately

Fix:

check key validity and whitespace issues

403 on API tools

Symptom:

auth succeeds but access denied

Fix:

confirm account is on paid/trial plan with API access

Tools appear missing

Symptom:

OpenClaw cannot call ChangeCrab tools

Fix:

verify registry definition
verify profile is not minimal
verify no deny policy suppresses bundled MCP tools

Post write errors despite valid key

Symptom:

create/update fails after apparent auth success

Fix:

verify changelog ID exists and is accessible
verify team resolution from changelog works
verify payload includes required fields

Operational recommendations for larger teams

If multiple people share the same OpenClaw deployment:

use environment-specific keys (dev/staging/prod)
pin local artifact paths in production
add a canary run that calls list_changelogs after upgrades
keep a non-production changelog for integration tests

If you automate release publishing:

keep generation and publication steps separate
default to draft=1 for generated content
require explicit approval prompt to publish

Reference command block

# Register
openclaw mcp set changecrab '{"command":"npx","args":["-y","changecrab-mcp-server"],"env":{"CHANGECRAB_API_KEY":"cc_your_api_key_here"}}'

# Inspect
openclaw mcp list
openclaw mcp show changecrab --json

# Remove
openclaw mcp unset changecrab

Closing

OpenClaw + ChangeCrab MCP is a practical, low-friction integration for teams that already ship from chat/CLI workflows.

From an engineering perspective, it is cleanly layered:

OpenClaw manages orchestration and policy
MCP provides a transport and schema boundary
ChangeCrab MCP server encapsulates API calls and error normalization
ChangeCrab API remains canonical data/write authority

If your release communication process is currently "ship now, write notes later," this setup removes most of the friction that causes that gap.