Skip to main content
Glama
geoffbelknap

LimaCharlie MCP

by geoffbelknap

lc_preview_set_cases_config

Preview a proposed Cases configuration replacement for an organization to verify correctness before applying.

Instructions

Preview replacing Cases configuration for an org.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
oidYes
configYes
token_ttl_secondsNo
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It implies a non-destructive preview, but it does not state whether it requires special permissions, if it modifies state, or what the output (e.g., success indicator or diffs) looks like. The minimal description leaves significant ambiguity.

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

Conciseness2/5

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

The description is a single sentence, which is concise, but it underspecifies the tool's behavior and parameters. It lacks front-loaded critical information and fails to earn its place by providing insufficient value.

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

Completeness1/5

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

Given 3 parameters (including a nested object), no output schema, and no annotations, the description is severely incomplete. It does not explain what the tool returns, how the preview works, or what the config object should contain. The tool requires substantial additional documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention any parameter names or roles. The 'config' object (which accepts any properties) remains entirely undefined, and 'oid' and 'token_ttl_seconds' are not described.

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 states 'Preview replacing Cases configuration for an org,' which clearly indicates the action (preview) and the resource (Cases configuration). It distinguishes itself from direct set tools (like lc_set_cases_config?) and retrieval tools (lc_get_cases_config) by emphasizing 'preview.' However, it does not explicitly differentiate from other preview tools.

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 guidance on when to use this tool versus alternatives. No prerequisites, when-not-to-use, or comparison with sibling tools is provided. The description is too brief to inform decision-making.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/geoffbelknap/limacharlie-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server