Everyday DevTools MCP

case_convert

Convert text between upper, lower, title, snake_case, kebab-case, and camelCase formats to quickly reformat strings for code, configs, or titles.

Instructions

Convert text case: upper, lower, title, snake_case, kebab-case or camelCase.

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": {
      "text": "<text>"
    },
    "name": "case_convert"
  }
}

Input Schema

Name	Required	Description	Default
`mode`	No		upper
`text`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full disclosure burden, yet it says nothing about edge-case behavior: whether whitespace is trimmed, how word boundaries are detected for camelCase or snake_case, how title case treats articles/acronyms, or whether non-ASCII input is supported. These ambiguities directly affect output correctness for a pure transformation tool.

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?

A single front-loaded sentence with no filler; the verb, the resource, and the option set are all presented immediately. Nothing could be removed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter text utility with no output schema, the description covers purpose and available modes, which is close to sufficient. It still omits the default mode and any statement about return shape or the slugify overlap, leaving an agent to infer those from the schema.

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 coverage is 0% and the 'mode' property has no enum or description, so the description's enumerated list of case options is the only signal about valid mode values, which is genuinely useful. However, it never names the parameters or states that 'mode' is optional and defaults to 'upper', so it only partially compensates for the coverage gap.

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 gives a specific verb ('Convert') and resource ('text case') and enumerates the six target formats, so an agent immediately knows what the tool produces. It does not distinguish itself from the sibling 'slugify', which overlaps on the snake_case/kebab-case territory, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no mention of when to prefer this over slugify or text_stats, and no note about prerequisites or limits. The list of modes implies usage but never explicitly routes the agent between this tool and its siblings.

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

Deploy Server