PageVerified

dev_utils

Read-only

Developer utilities: cron, regex, UUID, slug and JSON. Use when a task needs one of the small developer answers that would otherwise cost a round trip to a web tool: the next times a cron expression fires (in a named time zone and in UTC, with a plain-English reading and a note on which non-standard extensions it uses), what a regular expression matches in a piece of text (run on RE2, so no pattern can backtrack its way into exponential time, and a pattern whose compiled program is too large for the input it was given is refused rather than run), fresh UUIDs (version 4, or time-ordered version 7), a URL slug for a title, or JSON pretty-printed, minified or key-sorted with the line and column of a syntax error. Free, and no data is kept. Free to call.

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": {
      "operation": "<operation>"
    },
    "name": "dev_utils"
  }
}

Input Schema

Name	Required	Description
`text`	No	The title to slugify, or the JSON document to format.
`count`	No	How many cron runs, or how many UUIDs, to return.
`flags`	No	Distinct letters from i, m, s and u, for regex_test.
`input`	No	The text to run the pattern over, for regex_test.
`limit`	No	Maximum matches to return, for regex_test.
`start`	No	ISO instant to start the cron walk from, for cron_next_runs.
`indent`	No	Spaces per level for json_format; 0 minifies.
`pattern`	No	The regular expression, for regex_test. Run on RE2.
`version`	No	4 (random) or 7 (time-ordered), for uuid. Defaults to 4.
`timezone`	No	IANA time zone name for cron_next_runs, such as Europe/London. Defaults to UTC.
`operation`	Yes	One of cron_next_runs, regex_test, uuid, slugify, json_format. Each one reads its own further fields.
`separator`	No	The slug separator. Defaults to a hyphen.
`sort_keys`	No	Sort object keys, for json_format.
`expression`	No	The cron expression, for cron_next_runs.
`max_length`	No	Cap on the slug length, for slugify.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Beyond readOnlyHint=true, the description discloses important behavior: regex runs on RE2 so patterns cannot backtrack exponentially, oversized compiled programs are refused, cron results include named time zone and UTC plus plain-English readings, UUID versions 4 and 7 are supported, JSON formatting reports syntax error line and column, and no data is kept.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is front-loaded with the available utilities and then explains when to use them. It is dense and mostly one long sentence, but the parenthetical details about cron, regex, UUID, slug, and JSON each add useful information rather than padding.

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 five-operation multiplexer with 15 parameters and no output schema, the description does a good job explaining what each operation returns and key constraints like RE2 refusal and JSON error positions. Exact response shapes and all per-operation parameter mappings are left to the schema, which is a minor gap rather than a blocking one.

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%, so the input schema already carries the parameter documentation. The description adds operation-level context such as RE2 behavior and default UUID version/timezone, but it does not materially explain most individual parameters beyond what the schema already provides.

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?

The description names the specific utilities it bundles: cron, regex, UUID, slug, and JSON, and later maps them to operation names such as cron_next_runs and regex_test. It is clear what the tool does, though 'developer utilities' is an umbrella phrase rather than a single verb+resource.

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?

It says to use this when a task needs a small developer answer instead of a round trip to a web tool, which gives implied context. However, it does not explicitly say when not to use it or point to closer siblings like json_schema_validate, text_diff, or hash_encode.

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

All PageVerified tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?