MCPB Desktop Extension for Indian contracts drafting with multi-agent orchestration pipeline for contract generation, verification, and refinement.
Server has 9 tools with clear naming (verb_noun pattern) and detailed descriptions (100-300 chars each). All tools have input schemas with type definitions. However, output schemas are not formally documented in the code, descriptions mention return types but JSON Schema output definitions are absent. Parameter descriptions are present and specific. Tool annotations are correctly applied. Main gaps: no pagination support for list tools, no error handling guidance, and some descriptions are overly verbose with implementation details rather than LLM-optimized intent statements.
Create a case folder for a given case type under the default drafts root. Returns the absolute path to the created folder.
Get the instructions for the drafting pipeline. Default mode (no agent_name, or agent_name=""): returns the FULL orchestration script enumerating every step and tool call from case-folder creation through final-draft.docx. THIS IS THE MANDATORY FIRST CALL when the user asks you to draft anything. Single-agent mode (agent_name ∈ {reader, format, drafter, verifier, refiner, overseer}): returns that agent's persona instructions only.
Get the drafting format SKILL.md for a given case type. Returns the full SKILL.md content for the case type, including statutory anchors, format placeholders, and the drafting checklist. Also appends format-from-user.md if present in the same skill folder.
Get the shared contracts drafting base structure.
List all artifacts in a case folder.
List all case types this connector can draft. Returns a dict with the list of case types, a short description of each, AND an acronym disambiguation map (Indian advocacy acronyms / Form references / statutory section references -> case_type). CRITICAL: the user's acronym IS the source of truth for case_type classification. Do not infer case_type from input-document content.
Output schemas not formally documented. Tool descriptions mention return types (e.g., 'Returns a dict', 'Returns the full SKILL.md content') but no JSON Schema definitions are visible in the code. LLMs cannot reliably parse unstructured responses or plan downstream tool calls without explicit output schemas.
No pagination support on list tools. list_case_types and list_case_artifacts return unbounded results. If case artifacts grow large, responses will bloat context and degrade LLM reasoning. No limit, offset, or cursor parameters present.
No error handling guidance. Tools lack descriptions of failure modes, recovery steps, or actionable error messages. E.g., create_case_folder does not document what happens if the case_type is invalid or the folder already exists. Agents cannot self-correct on failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Read a text artifact from disk within a case folder.
Save a text artifact to disk within a case folder. Creates parent directories as needed.
Convert a markdown draft to a .docx file using pandoc and the reference.docx template. Applies post-pandoc table-width fixes.
Descriptions contain implementation details and verbose orchestration logic. get_agent_instructions description is 400+ chars and reads like a manual rather than a concise LLM-optimized intent statement. Baseline for A+ tools is 50-200 chars. Verbose descriptions waste tokens and bury key intent.
Parameter 'case_type' in get_case_type_format lacks enum constraint. Description says 'One of the slugs returned by list_case_types()' but no formal enum is declared. LLMs may hallucinate invalid case_type values. Should declare enum: ['commercial-service-agreement', 'nda', 'employment-agreement', ...].