Skip to main content
Glama
edenbuilds

maharashtra-courts-drafting

by edenbuilds

create_case_folder

Create organized case folders with inputs/ and artifacts/ subdirectories under Downloads/MH-Courts-Drafts (or a specified root), providing a structured workspace for drafting court pleadings.

Instructions

Create inputs/ and artifacts/ under Downloads/MH-Courts-Drafts (or root).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootNo
labelYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

C2.9/5.0
Behavior3/5

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

The description discloses that the tool creates directories and mentions a default location with an optional root override. However, it does not explain behavior when directories already exist, whether the operation is destructive, or what 'root' resolves to in practice. Annotations do not contradict the description.

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 a single, front-loaded sentence with no filler. It is concise, though slightly terse and arguably under-specified regarding label and root semantics.

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

Completeness2/5

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

For a tool with two parameters manageable by an agent, the description omits the meaning of the required label, the exact output structure, and behavior on existing directories. The absence of an output schema makes this omission more impactful because the agent cannot infer return values elsewhere.

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

Parameters2/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 carry the weight of explaining parameters. It vaguely references 'root' but does not explain the required 'label' parameter at all, leaving a critical gap in understanding what a case folder is named or structured.

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 a specific action, 'Create inputs/ and artifacts/', and a clear target location, which distinguishes it from siblings like save_artifact or read_case_folder. It is somewhat ambiguous about how the required label relates to the resulting folder structure, but the core purpose is identifiable.

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?

No guidance is provided about when to use this tool versus alternatives such as save_artifact or read_case_folder. There are no prerequisites, exclusions, or contextual cues beyond the bare statement of what the tool creates.

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