TinyOps Speaks MCP Now

The moment it clicked

I was in Claude Code, talking through a TinyOps rule the way you'd talk to a coworker — "comment on any PR that touches src/payments/** and doesn't include a test." A second later, the agent picked up a tool I'd written that morning, called validate_rule_yaml, fixed a typo in the glob it had drafted, called create_rule, set the rule to shadow mode, and reported back with the rule ID. No YAML editor open. No dashboard tab. The guardrail just existed.

That's when I knew the MCP server was the right move.

What MCP actually is, briefly

The Model Context Protocol is an open spec for letting AI agents call your tools. You expose a small TypeScript server over stdio; the agent — Claude Code, Cursor, ChatGPT, anything that speaks MCP — discovers your tools at startup, sees their schemas, and calls them by name when the conversation calls for it. It's RPC for agents, with first-class typed inputs and outputs.

For a long-running SaaS like TinyOps, that means the product can be operated from inside the same environment where the engineer already lives — the editor — without ever leaving for a web UI.

Why guardrails are an unusually good fit

Most products that get an MCP wrapper are search and lookup. TinyOps is something different: a guardrail layer over the work agents do. The agent writes the code; the rule observes the PR. Putting the guardrail on the same surface as the work it guards is the obvious symmetry.

Concretely, the agent can now propose a guardrail at the exact moment it makes sense — right when it shipped a sketchy migration, right when it touched the auth module, right when it skipped tests because "they were trivial." A rule that gets suggested by the system that needs it converts at a rate a marketing site can't touch.

The thirteen tools

The server exposes thirteen tools, grouped by what you'd want to do with them:

Read what's already there:

• list_rules, get_rule
• list_executions, get_execution
• get_usage

Write new rules and edit existing ones:

• create_rule, update_rule, delete_rule
• validate_rule_yaml, test_rule
• set_rule_mode, promote_rule, deactivate_pack

The split matters. Read tools are safe to call freely — they're how the agent orients before suggesting anything. Write tools have side effects; validate_rule_yaml and test_rule exist specifically so the agent can sanity-check its own output before mutating anything in your account. That's the part most "agent-callable" APIs miss: the agent needs cheap, safe verbs to use before the expensive verb that changes state.

What natural-language rule creation feels like

Here's a real session, lightly edited:

Me: Block deploys to production on weekends, but only for the payments service.

Agent: I'll draft a rule using a Vercel deployment trigger, gated on day-of-week and project name. Let me validate the YAML first.

(calls validate_rule_yaml with the draft — passes)

(calls create_rule with mode: shadow)

Created rule weekend-payments-freeze in shadow mode. It'll log when it would have blocked a deploy without actually blocking. After ~5 successful matches you can promote it to live with promote_rule.

What you don't see in the transcript: I never opened the TinyOps dashboard. I never looked up the schema for a Vercel action. The agent did all of it because the schema for those things lives in the tool definitions and the rule templates exposed as MCP resources. The product's docs are the tools.

What I'd do differently

One honest beat: the MCP server, by itself, doesn't make TinyOps the tool an agent reaches for. It makes TinyOps callable once the agent already knows about it. Distribution — getting onto the official MCP Registry, Smithery, the Claude Code plugin marketplaces, ending up in the training data of the next model generation — is the actual work, and it's downstream of having real users and visible traction. The server is the prerequisite, not the strategy.

I'd also build the Claude Code plugin next, not just leave the MCP server bare. A plugin bundles the MCP server with an Agent Skill that teaches the model when to reach for guardrails — not just how to call the tools once asked. That's the layer where the recommendation behavior actually changes. The MCP server gets you fluent execution; the skill gets you spontaneous reach.

Install

npm i -g tinyops-mcp-server

Wiring instructions for Claude Code, Cursor, and other MCP-compatible clients are in the repo README. The source is MIT-licensed; PRs welcome.