zipnative-mcp

Overview Schema Source Related Servers Discussions Admin

Draft a governance-compliant GitHub issue (HITL)

draft_governance_issue

Idempotent

Draft a local GitHub issue and compliance report for human review without submitting it, validating reproduction details and zero-dependency policy.

Instructions

Produce a LOCAL GitHub issue draft + compliance report for zipnative / zipnative-mcp and NEVER submit it — the agent drafts, a human reviews and files it under their own identity (Human-In-The-Loop contract, .github/AGENT_RULES.md). No GitHub write path and no network path exist in this server. The draft is checked against the zero-dependency + reproduction policy; a policy violation (a new runtime dependency, duplicateSearchPerformed:false) is GOVERNANCE_VIOLATION; a missing field (reproduction included) is VALIDATION_ERROR. targetRepo 'zipnative' for engine behaviour (parsing, writing, limits, codecs), 'zipnative-mcp' for wrapper behaviour (schemas, sandbox, transport). Returns markdown inline (outputMode:'file' also writes a .md inside the sandbox). Use it only after reproducing a defect — for questions read describe_engine / docs/AGENT_CONTRACT.md instead. Present the draft AND the report to the user, then STOP.

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": {
      "title": "<title>",
      "summary": "<summary>",
      "issueType": "<issueType>",
      "reproduction": "<reproduction>",
      "expectedBehavior": "<expectedBehavior>",
      "duplicateSearchPerformed": "<duplicateSearchPerformed>"
    },
    "name": "draft_governance_issue"
  }
}

Input Schema

Name	Required	Description	Default
`title`	Yes	Concise issue title (imperative, no trailing period).
`summary`	Yes	One or two paragraphs describing the problem or proposal.
`issueType`	Yes	Issue category: 'bug' \| 'feature' \| 'security' \| 'docs' \| 'performance'.
`outputMode`	No	'inline' (default) returns the draft markdown in the response. 'file' additionally writes it to the sandbox (requires ZIPNATIVE_MCP_OUTPUT_DIR); outputPath must be a relative .md path.	inline
`outputPath`	No	Relative .md path inside the sandbox (only when outputMode='file').
`targetRepo`	No	Destination repository label for the draft (documentation only — the server never contacts it). 'zipnative-mcp' (wrapper: schemas, sandbox, transport) or 'zipnative' (engine: parser, writer, limits, codecs).	zipnative-mcp
`reproduction`	Yes	The minimal, locally-executed reproduction that justifies this issue.
`actualBehavior`	No	What actually happened (defaults to the reproduction result when omitted).
`affectedPackages`	No	Packages impacted by this issue (e.g. ["zipnative-mcp"], ["zipnative"]).
`expectedBehavior`	Yes	What you expected to happen instead.
`duplicateSearchPerformed`	Yes	MUST be true: confirms you searched open AND closed issues/PRs for duplicates before drafting.

Output Schema

Name	Required	Description
`title`	Yes
`filePath`	No	Sandboxed absolute path (when outputMode='file').
`warnings`	Yes
`issueType`	Yes
`sizeBytes`	Yes
`compliance`	Yes
`outputMode`	Yes
`targetRepo`	Yes
`draftMarkdown`	Yes	The full draft, ready for a human to review and submit.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.0.1Oct 27, 2026
- addedInput schema / properties / actualBehavior / maxLength
```
Added value: +16384
```
- addedInput schema / properties / expectedBehavior / maxLength
```
Added value: +16384
```
- addedInput schema / properties / reproduction / properties / command / maxLength
```
Added value: +16384
```
- addedInput schema / properties / reproduction / properties / result / maxLength
```
Added value: +16384
```
- addedInput schema / properties / summary / maxLength
```
Added value: +16384
```
First observedv1.0.0Sep 8, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds substantial context beyond the annotations: the HITL contract, the absence of any GitHub or network write path (consistent with openWorldHint=false), the sandbox write side effect when outputMode='file', and the error taxonomy (GOVERNANCE_VIOLATION vs VALIDATION_ERROR). It does not explain the idempotentHint=true semantics (overwriting an existing outputPath file), which is the one behavioral detail left implicit.

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 critical constraint (LOCAL draft, never submitted) is front-loaded in the first clause, and every subsequent sentence carries governance, routing, or output detail. It is dense and em-dash-heavy in the middle, but for a tool with this much contract surface almost nothing is filler.

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

Completeness5/5

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

For an 11-parameter tool with nested reproduction object, enums, and a governance gate, the description covers purpose, the human-in-the-loop contract, repo routing, output modes, error classes, and the stopping condition. An output schema exists, so return-value detail is correctly omitted.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description still adds real meaning by assigning semantics to targetRepo values ('zipnative' for engine behaviour, 'zipnative-mcp' for wrapper behaviour) and by tying duplicateSearchPerformed:false to a specific GOVERNANCE_VIOLATION outcome. It adds little on title/summary/reproduction beyond what the schema says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and concrete artifact set: 'Produce a LOCAL GitHub issue draft + compliance report', scoped to zipnative / zipnative-mcp. It immediately distinguishes itself from every sibling in the list (zip inspection/manipulation tools) by being the only issue/governance tool, and names describe_engine as the read-path alternative.

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

Usage Guidelines5/5

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

Explicit exclusions and alternatives are given: 'Use it only after reproducing a defect — for questions read describe_engine / docs/AGENT_CONTRACT.md instead.' The terminal instruction 'Present the draft AND the report to the user, then STOP' closes the workflow loop so the agent knows not to chain a submit step.

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

Deploy Server