This server automates the creation, validation, versioning, and analysis of academic thesis proposals and pre-proposal documents through MCP tools.
Generates complete thesis proposal .docx files from a topic, CSV literature, or retrieved papers (generate_proposal_from_topic, generate_academic_proposal).
Generates official pre-proposal .odt forms (SA2-01A) from a topic or structured sections (generate_praproposal_from_topic, generate_academic_praproposal).
Validates research design rigor against Canvas rules, including single measurable problem, explicit X/Y variables, objective alignment, and word-count budgets (validate_canvas_compliance, validate_praproposal_compliance).
Produces detailed Markdown rubric/checklist audit reports for proposals and pre-proposals.
Parses CSV literature matrices into comparison tables and Harvard/IEEE-style reference lists (parse_literature_csv_data).
Plans research by deriving variables, research questions, and optimized search queries for external paper-search MCP tools (plan_proposal_research).
Synthesizes structured research topics from real-world artifacts like news or case documents (generate_topic_from_artefact).
Generates academic diagrams (flowcharts, conceptual frameworks, architectures) and inserts them into documents with official captions.
Renders LaTeX math formulas as native Word equations or PNG images and inserts them into DOCX files.
Inspects proposal/pre-proposal structure, word counts, and heading trees (inspect_proposal_document).
Exports DOCX proposals to clean Markdown for LLM analysis (export_proposal_as_markdown).
Tracks document versions and changelogs for both proposal and pre-proposal files (increment_proposal_version, increment_praproposal_version).
Allows the server to use arXiv paper search results through the paper-search MCP for literature review, research planning, and proposal generation.
Allows the server to use Google Scholar search results through the paper-search MCP for literature review, research planning, and proposal generation.
Allows the server to use Semantic Scholar search results through the paper-search MCP for literature review, research planning, and proposal generation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Academic Proposal MCP Server Help me generate a thesis proposal on how AI affects student learning outcomes."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Academic Proposal MCP Server is a self-contained, independent server built on the Model Context Protocol (MCP). It is designed for students, researchers, and academic institutions to automate the creation, structuring, iterative versioning, and methodology validation of formal academic thesis and research proposals.
Dual Document Support (Proposal .docx & Pra-Proposal .odt):
Thesis Proposal (3 Chapters DOCX): Full academic proposal adhering to official institutional formatting (generate_proposal_from_topic, generate_academic_proposal).
Pre-Proposal Form (SA2-01A ODT): Standard institutional pre-proposal document (generate_praproposal_from_topic, generate_academic_praproposal).
Strict Research Design Canvas Alignment:
Strictly enforces 1 Single Measurable Problem Question (CLB04-01 & CLB04-02), eliminating open-ended or descriptive phrasing.
Automatically defines explicit Independent ($X$) and Dependent ($Y$) variables, aligns linear objectives, and verifies actionable stakeholder benefits.
Mandatory Personal Data Re-Confirmation Workflow:
Ensures student and supervisor details (Nama Mahasiswa, NIM, Departemen/Jurusan, Program Studi, Keminatan, Bidang Skripsi, Dosen Pembimbing, NIP, Lokasi) are explicitly verified and confirmed before and after document generation.
CSV Literature Matrix Ingestion:
Ingests literature review matrices or benchmark datasets directly from CSV files (parse_literature_csv_data).
Automatically builds comparison matrices and Harvard/IEEE bibliographies.
Multi-MCP Research Coordination:
Seamlessly interoperates with external research MCPs such as paper-search (search_arxiv, search_semantic, search_google_scholar) and go-docs.
Derives targeted academic queries via plan_proposal_research and includes registered prompt workflows (auto_praproposal_workflow, auto_proposal_workflow).
Iterative Version Tracking & Markdown Exporting:
Facilitates document versioning (v1.0 $\rightarrow$ v1.1 $\rightarrow$ v2.0) with automated changelog recording in version_history.json.
Extracts DOCX proposals into clean Markdown for LLM analysis.
Related MCP server: Q1 Crafter MCP
Tool | Description | Key Parameters |
| Synthesizes a structured academic research proposal topic (Title, 3-dimensional Urgency, Single Measurable Problem, Variables X & Y, Objectives, Benefits, and Canvas Audit) from any real-world artifact (news, case stories, problem documents, OCR/image descriptions) and reports it to a Markdown ( |
|
| Generates high-resolution academic diagrams (Flowchart, Conceptual Framework, Layered Architecture), ensures |
|
| Inserts an existing diagram image from |
|
| One-shot generator for academic pre-proposal form ( |
|
| Assembles and generates a complete academic pre-proposal document ( |
|
| Validates pre-proposal form (SA2-01A) rigor against standard research canvas and word count budget limits (Latar Belakang <= 500w, Landasan Kepustakaan <= 250w, Metode <= 250w). |
|
| Generates a comprehensive pre-proposal audit checklist report in Markdown format based on institutional SA2-01A rules and Canvas rubrics. |
|
| Validates research proposal rigor against standard academic research design principles. |
|
| Generates a comprehensive academic audit checklist report in Markdown format based on standard evaluation rubrics. |
|
| Retrieves the complete rubric and checklist for academic research design criteria (Chapter 1-3 & SA2-01A). | (none) |
| Assembles and generates a complete, publication-grade academic proposal DOCX file. |
|
| One-shot proposal generator combining research topic, CSV literature data, and paper-search results with automatic research flowchart rendering. |
|
| Analyzes a topic to derive variables (X & Y), single research question, and search queries for |
|
| Parses a literature review or benchmark CSV file from workspace into DOCX comparison table and references. |
|
| Analyzes the structural health and word count budget of proposal documents ( |
|
| Duplicates active thesis proposal (.docx) to an updated version and records changelog entries in |
|
| Duplicates active pre-proposal (.odt) to an updated version and records changelog entries in |
|
| Converts any DOCX proposal in the workspace into clean, structured Markdown. |
|
git clone https://github.com/ranoes/academic-mcp-proposal.git
cd academic-mcp-proposal
docker build -t academic-proposal-mcp:latest .Add the following entry to your MCP configuration file (e.g., mcp_config.json in Antigravity, or claude_desktop_config.json in Claude Desktop):
{
"mcpServers": {
"academic-proposal-mcp": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-v",
".:/workspace",
"academic-proposal-mcp:latest"
]
}
}
}Note:
.:/workspaceotomatis memetakan direktori proyek yang sedang aktif dibuka di IDE ke dalam/workspacecontainer Docker tanpa perlu menuliskan path absolut secara manual.
If you prefer running directly in a local Python environment:
# Clone the repository
git clone https://github.com/ranoes/academic-mcp-proposal.git
cd academic-mcp-proposal
# Install dependencies and package
pip install -e .
python server.pyConfiguration in mcp_config.json for Python:
{
"mcpServers": {
"academic-proposal-mcp": {
"command": "python",
"args": ["${workspaceFolder}/server.py"],
"env": {
"WORKSPACE_DIR": "${workspaceFolder}"
}
}
}
}Below is a detailed guide for all 16 MCP Tools provided by the server, organized by function:
generate_proposal_from_topicOne-shot generator that produces a complete 3-Chapter Thesis Proposal in .docx format directly from a topic, variable specifications, CSV literature, and/or retrieved papers.
Parameters: topic (str), variabel_x (str, opt), variabel_y (str, opt), student_metadata (dict, opt), csv_filename (str, opt), csv_content (str, opt), retrieved_papers (list, opt), output_filename (str, default: "Proposal Skripsi v1.0.docx")
Example Payload:
{
"topic": "Optimizing Distributed Sensor Network Lifetime using Reinforcement Learning Routing Algorithms",
"variabel_x": "Adaptive Reinforcement Learning Q-Routing Mechanism",
"variabel_y": "Network Operational Longevity and Packet Delivery Ratio",
"csv_filename": "literature.csv",
"output_filename": "Proposal Skripsi v1.0.docx"
}generate_academic_proposalAssembles a publication-grade academic proposal .docx file from explicit chapter structures (metadata, bab1_data, bab2_subbab, bab3_subbab, daftar_referensi).
Parameters: metadata (dict), bab1_data (dict), bab2_subbab (list), bab3_subbab (list), daftar_referensi (list), output_filename (str)
generate_praproposal_from_topicOne-shot generator that creates an official Pre-Proposal Form (.odt, format SA2-01A) directly from research topic inputs and applies automatic Canvas compliance auditing.
Parameters: topic (str), variabel_x (str, opt), variabel_y (str, opt), student_metadata (dict, opt), csv_filename (str, opt), retrieved_papers (list, opt), output_filename (str, default: "Praproposal Skripsi v1.0.odt")
Example Payload:
{
"topic": "Optimasi Deteksi Anomali Jaringan IoT Menggunakan Federated Learning",
"variabel_x": "Algoritma Federated Learning Terdistribusi",
"variabel_y": "Akurasi Deteksi dan Efisiensi Komunikasi Jaringan IoT",
"student_metadata": {
"nama_mahasiswa": "Alex Mercer",
"nim": "225150200111000",
"jurusan": "Teknik Informatika",
"program_studi": "Teknik Informatika",
"keminatan": "Komputasi Cerdas",
"bidang_skripsi": "Artificial Intelligence & Data Science",
"nama_pembimbing": "Dr. Mahrus Ali, S.Kom., M.Kom."
},
"output_filename": "Praproposal_SA2-01A_Alex_Mercer.odt"
}generate_academic_praproposalDirectly populates and compiles the official SA2-01A .odt form from structured metadata and sections dictionaries with automated canvas verification.
Parameters: metadata (dict), sections (dict), output_filename (str)
validate_canvas_compliance (Proposal 3-Bab Validation)Audits the methodological rigor of a proposal against standard Research Design Canvas rules.
Parameters: rumusan_masalah (str), variabel_independen (str), variabel_dependen (str), tujuan_penelitian (str), manfaat_penelitian (str), judul (str, opt), single_problem_only (bool, default: true)
Validation Checks:
[CLB01-RB01]: Anti-Rancang Bangun / Output Ilmiah Empiris. Detects and strictly forbids software development project / product-building paradigms ("rancang bangun aplikasi", "pembuatan sistem", "pengembangan website/game"). Research must yield new empirical scientific knowledge, quantitative algorithm benchmarking, or empirical proof of $X \rightarrow Y$.
[CLB04-01]: Ensures strictly 1 measurable problem question.
[CLB04-02]: Enforces non-descriptive, parameter-driven question formulation.
[CLB04-02 / M01-01]: Verifies explicit Variable $X$ definition.
[CLB04-03 / M01-02]: Verifies explicit Variable $Y$ definition.
[CLB05-01]: Ensures objectives test variable outcomes (rejects project-task phrasing like "membuat aplikasi").
[CLB06-02]: Eliminates administrative clichés ("syarat kelulusan", "menambah wawasan").
Example Payload:
{
"judul": "ANALISIS KINERJA ADAPTIVE Q-ROUTING TERHADAP OPERATIONAL LIFETIME PADA JARINGAN SENSOR NIRKABEL",
"rumusan_masalah": "Sejauh manakah implementasi Adaptive Q-Routing mampu memperpanjang network lifetime dibandingkan protokol routing statis pada jaringan sensor nirkabel?",
"variabel_independen": "Adaptive Q-Routing Mechanism",
"variabel_dependen": "Network Operational Lifetime dan Packet Delivery Ratio",
"tujuan_penelitian": "Menguji dan mengukur peningkatan lifetime jaringan sensor melalui algoritma Q-Routing",
"manfaat_penelitian": "Memberikan panduan operasional bagi praktisi jaringan sensor dalam mengurangi kegagalan transmisi data"
}validate_praproposal_compliance (Pre-Proposal SA2-01A Validation)Validates pre-proposals against Research Canvas rules and strict SA2-01A word-count budgets (can evaluate in-memory payloads OR directly inspect an existing .odt file in the workspace).
Parameters: metadata (dict, opt), sections (dict, opt), odt_filename (str, opt), variabel_independen (str, opt), variabel_dependen (str, opt), single_problem_only (bool, default: true)
Word Limits Enforced:
[PRA-LB01] Latar Belakang / Deskripsi Masalah: $\le 500$ words.
[PRA-LR01] Landasan Kepustakaan: $\le 250$ words.
[PRA-MET01] Rencana Metode Penelitian: $\le 250$ words.
Example Payload (Validating from existing file):
{
"odt_filename": "Praproposal Skripsi v1.0.odt",
"variabel_independen": "Algoritma Federated Learning",
"variabel_dependen": "Akurasi Deteksi dan Komunikasi"
}generate_rubric_checklist_report (Proposal 3-Bab Audit Report)Generates a comprehensive Markdown audit report for the 3-Chapter Proposal across 17 rubric criteria (Chapter 1 LB01-LB06, Chapter 2 LR01-LR06, Chapter 3 M01-M05).
Parameters: proposal_title, student_name, student_id, rumusan_masalah, variabel_independen, variabel_dependen, tujuan_penelitian, manfaat_penelitian, output_markdown_filename (default: "proposal_rubric_checklist_report.md")
generate_praproposal_rubric_report (Pre-Proposal SA2-01A Audit Report)Generates an audit checklist Markdown report specifically for Form SA2-01A, featuring a dedicated Word Count Budget Analysis table and itemized criteria verification.
Parameters: proposal_title (opt), student_name (opt), student_id (opt), metadata (dict, opt), sections (dict, opt), odt_filename (opt), variabel_independen (opt), variabel_dependen (opt), output_markdown_filename (default: "praproposal_rubric_checklist_report.md")
get_canvas_guidelinesRetrieves the complete standard rubric guidelines, evaluation criteria, and violation codes across Chapter 1, Chapter 2, Chapter 3, and Form SA2-01A.
Parameters: (none)
inspect_proposal_documentPerforms deep structural health checks on either .docx proposals or .odt pre-proposals.
For .docx: Returns total paragraphs, tables, approximate words, heading tree (BAB 1, 1.1, etc.), and table geometry.
For .odt: Returns word counts for each section (Latar Belakang, Landasan Kepustakaan, Metode) and validates word budget compliance against SA2-01A limits.
Parameters: filename (str, default: "Proposal Skripsi v1.0.docx")
export_proposal_as_markdownExtracts formatted text, headings, captions, and reference lists from any .docx proposal into structured Markdown for fast LLM inspection.
Parameters: filename (str, default: "Proposal Skripsi v1.0.docx")
increment_proposal_versionDuplicates an active proposal (.docx) to an incremented version and records change notes in version_history.json.
Parameters: current_version (e.g., "v1.0"), new_version (e.g., "v1.1"), changelog (str)
increment_praproposal_versionDuplicates an active pre-proposal (.odt) to an incremented version and records change notes in version_history.json.
Parameters: current_version (e.g., "v1.0"), new_version (e.g., "v1.1"), changelog (str), filename_prefix (str, default: "Praproposal Skripsi")
generate_topic_from_artefactSynthesizes a structured academic research proposal topic (Title, 3-dimensional Urgency, Single Measurable Problem, Variables X & Y, Objectives, Benefits, and Canvas Audit) from any real-world artifact (news articles, case stories, problem documents, OCR/image descriptions) and exports a complete formatted Markdown (.md) report to the workspace.
Parameters: artefact_content (str), artefact_type (str, default: "general_text"), artefact_title (str, opt), bidang_kajian (str, opt), proposed_method_or_x (str, opt), target_metric_or_y (str, opt), institutional_focus (str, opt), output_markdown_filename (str, default: "usulan_topik_riset.md"), save_to_workspace (bool, default: true)
Example Payload:
{
"artefact_type": "news",
"artefact_title": "Lonjakan Serangan Botnet IoT 2025",
"artefact_content": "Laporan Keamanan Siber menunjukkan lonjakan 300% serangan botnet DDoS pada gateway IoT karena tingginya false alarm dan latensi metode deteksi konvensional.",
"proposed_method_or_x": "Algoritma Federated Learning Terdistribusi",
"bidang_kajian": "Keamanan Siber & Jaringan Komputer",
"output_markdown_filename": "usulan_topik_riset.md"
}plan_proposal_researchAnalyzes a topic to derive variables $X$ & $Y$, a single measurable research question, and targeted academic search queries for paper-search MCP.
Parameters: topic (str), bidang_kajian (str, opt), variabel_x (str, opt), variabel_y (str, opt)
parse_literature_csv_dataParses a CSV literature matrix into a formatted comparison table (tabel_tinjauan_pustaka), narrative summaries for Chapter 2, and standard Harvard/IEEE citations.
Parameters: csv_filename (str, opt), csv_content (str, opt)
generate_diagram_imageGenerates high-resolution academic vector/raster diagrams (300 DPI), automatically ensures the /asset workspace directory exists, saves the PNG file, and can optionally insert it directly into a target .docx proposal.
Supported Diagram Types:
"flowchart": Multi-stage vertical research workflow diagram (Tahap 1, Tahap 2, ...).
"conceptual_framework": Causal variable relationship diagram ($X \rightarrow \text{Treatment} \rightarrow Y$).
"architecture": Layered system/software architecture block diagram.
Parameters: diagram_type (str), title (str), steps_or_nodes (list, opt), variabel_x (str, opt), variabel_y (str, opt), layers (list, opt), asset_folder (str, default: "asset"), output_filename (str, opt), target_document_docx (str, opt), chapter_num (int, default: 3), figure_num (int, default: 1)
Example Payload:
{
"diagram_type": "flowchart",
"title": "Diagram Alur Pelaksanaan Penelitian",
"steps_or_nodes": [
"Tahap 1: Identifikasi Masalah Konsumsi Energi WSN",
"Tahap 2: Studi Literatur Protokol Routing",
"Tahap 3: Perancangan Model Q-Routing",
"Tahap 4: Implementasi & Pengujian Simulasi NS-3",
"Tahap 5: Evaluasi Metrik & Kesimpulan"
],
"asset_folder": "asset",
"output_filename": "diagram_alur_penelitian.png",
"target_document_docx": "Proposal Skripsi v1.0.docx"
}insert_diagram_to_documentEmbeds an image from /asset (or a given path) into an existing .docx proposal document with standardized, centered figure formatting and official captioning (Gambar X.Y <Judul>).
Parameters: document_filename (str), image_filename_or_path (str), caption_title (str), chapter_num (int, default: 3), figure_num (int, default: 1), width_inches (float, default: 5.5)
Example Payload:
{
"document_filename": "Proposal Skripsi v1.0.docx",
"image_filename_or_path": "asset/diagram_alur_penelitian.png",
"caption_title": "Diagram Alur Pelaksanaan Penelitian",
"chapter_num": 3,
"figure_num": 1
}generate_math_formula_imageRenders LaTeX mathematical formulas natively into Microsoft Word equations (Office Open XML Math / OMML <m:oMath>) as fully editable, crisp vector math objects directly in the .docx document, and/or exports 300 DPI transparent PNG images to /asset. Supports automatic equation numbering (Chapter.Formula) and variable definitions.
Parameters: latex_code (str), formula_title (str, opt), chapter_num (int, default: 3), formula_num (int, default: 1), variable_definitions (dict, opt), asset_folder (str, default: "asset"), output_filename (str, opt), target_document_docx (str, opt), intro_text (str, opt), use_native_equation (bool, default: true)
Supported Math Syntax: Greek letters ($\alpha, \beta, \gamma, \sigma, \theta$), fractions (\frac{a}{b}), summations (\sum_{i=1}^n), integrals (\int), square roots (\sqrt), accents (\hat{y}, \bar{x}), paired pipes (|y_i - \hat{y}_i|), sub/superscripts (x_i^2), matrix/vector terms.
Example Payload:
{
"latex_code": "F_1 = 2 \\cdot \\frac{\\text{Precision} \\cdot \\text{Recall}}{\\text{Precision} + \\text{Recall}}",
"formula_title": "F1-Score",
"chapter_num": 3,
"formula_num": 1,
"variable_definitions": {
"Precision": "Tingkat ketepatan klasifikasi kelas positif",
"Recall": "Tingkat sensitivitas model terhadap kelas positif"
},
"use_native_equation": true,
"target_document_docx": "Proposal Skripsi v1.0.docx"
}insert_math_formula_to_documentInserts a formula into an existing .docx document using the standard academic layout: a borderless 1-row $\times$ 2-column table with the native Word Equation (<m:oMath>) centered in the left column (5.2 in), right-aligned equation numbering (X.Y) in the right column (0.8 in), and indented "di mana: ..." variable definitions.
Parameters: document_filename (str), latex_code (str, opt), image_filename_or_path (str, opt), chapter_num (int, default: 3), formula_num (int, default: 1), intro_text (str, opt), variable_definitions (dict, opt), use_native_equation (bool, default: true), image_width_inches (float, default: 4.0)
Example Payload:
{
"document_filename": "Proposal Skripsi v1.0.docx",
"latex_code": "\\text{MAE} = \\frac{1}{n} \\sum_{i=1}^{n} |y_i - \\hat{y}_i|",
"chapter_num": 3,
"formula_num": 1,
"intro_text": "Perhitungan nilai Mean Absolute Error (MAE) dirumuskan pada Persamaan (3.1) sebagai berikut:",
"variable_definitions": {
"y_i": "Nilai aktual data observasi ke-i",
"\\hat{y}_i": "Nilai estimasi prediksi model ke-i",
"n": "Jumlah total sampel pengujian"
},
"use_native_equation": true
}You can place a literature.csv in your workspace containing prior literature or benchmark studies. The columns are automatically detected:
Author,Year,Title,Method,Dataset,Findings,Gap
Zhang et al.,2023,Q-Learning for WSN Clustering,Q-Learning,WSN-Sim-100,Increased lifetime by 18%,High computational overhead on edge nodes
Al-Kandari et al.,2022,Energy-aware Routing Protocols,Heuristic Path Selection,Real-world Sensor Grid,Reliable packet delivery,Static pathing causes early node deathColumns detected:
Author / Penulis: Citation author name(s).
Year / Tahun: Publication year.
Title / Judul: Paper title.
Method / Metode / Algoritma: Independent variable / technique ($X$).
Dataset / Benchmark: Test scenario or dataset used.
Results / Temuan / Hasil: Key quantitative findings ($Y$).
Gap / Limitation / Kelemahan: Identified research gap.
paper-search)If you have paper-search-mcp installed alongside academic-proposal-mcp:
Verify & Confirm Data: Ensure student and supervisor personal information (Nama, NIM, Departemen, Program Studi, Dosen Pembimbing, NIP, Lokasi) is collected.
Plan Queries: Call plan_proposal_research(topic="...") to derive search queries optimized for ArXiv, Google Scholar, and Semantic Scholar.
Retrieve Papers: Run paper-search tools (search_arxiv, search_semantic, etc.).
Assemble Document: Pass search results into generate_praproposal_from_topic(...) for Pre-Proposal (.odt) or generate_proposal_from_topic(...) for Thesis Proposal (.docx).
Prompt Automation: Use the built-in MCP prompts (auto_praproposal_workflow or auto_proposal_workflow) in Antigravity or your AI client to execute the entire research and assembly workflow automatically.
Distributed under the GNU Affero General Public License v3.0 (AGPL-3.0). See LICENSE for more details. Contributions, issue reports, and pull requests to expand academic formatting capabilities or validation rules are warmly welcomed.
Mengekstraksi seluruh isi dokumen proposal .docx menjadi format Markdown bersih yang mudah dibaca dan diolah oleh LLM / pengguna.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Proposal Skripsi v1.0.docx |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It discloses the transformation from .docx to Markdown and the intended audience, but it does not state whether the tool returns the Markdown content, writes a file, or performs any side effects. Failure cases and output format details are also omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and the core action is front-loaded. It is appropriately sized for a tool with one parameter, though brevity comes at the cost of missing behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does not explain how the Markdown is returned to the caller, which is essential for an agent to consume the result. It also does not disambiguate the tool from inspect_proposal_document, leaving an incomplete picture for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the filename parameter or how to provide it. The only semantic cues come from the parameter name and default value in the schema; the description adds no detail about path handling, file format expectations, or whether the filename is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: it extracts the entire content of a .docx proposal document into clean Markdown. The purpose is distinct from the sibling tools, though it does not explicitly name or distinguish itself from closely related tools like inspect_proposal_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 inspect_proposal_document or generate_academic_proposal. The usage context is only implied by the tool name and description; there are no explicit conditions, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Membuat berkas Dokumen Pra-Proposal Skripsi (.odt) berbasis template resmi SA2-01A. Menerima metadata mahasiswa dan struktur konten (latar_belakang, landasan_kepustakaan, rumusan_masalah, metode, daftar_pustaka).
| Name | Required | Description | Default |
|---|---|---|---|
| metadata | Yes | ||
| sections | Yes | ||
| output_filename | No | Praproposal Skripsi v1.0.odt | |
| custom_template_filename | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the output format (.odt), template usage, and accepted inputs, but it does not mention side effects such as file overwriting, return behavior, or requirements like template availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no filler. The primary output is stated first, followed by input structure, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, nested objects, no output schema, and no annotations, the description is too thin. It omits the structure of the metadata object, the behavior of custom_template_filename, and any details about how the generated file is returned or stored, leaving an agent unable to reliably construct valid arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It adds meaning by enumerating the content sections (latar_belakang, landasan_kepustakaan, rumusan_masalah, metode, daftar_pustaka), but it leaves the metadata object entirely unspecified and does not clarify output_filename or custom_template_filename semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Membuat'), a concrete resource ('berkas Dokumen Pra-Proposal Skripsi (.odt)'), and the official template basis ('SA2-01A'). It clearly distinguishes this tool from the sibling generate_academic_proposal by specifying the pre-proposal document type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for generating a pra-proposal document from provided metadata and content sections, which contrasts with topic-based siblings like generate_praproposal_from_topic. However, it does not explicitly state when to prefer this tool over alternatives or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Membuat dokumen DOCX proposal skripsi lengkap berbasis template resmi FILKOM UB. Dapat digunakan oleh mahasiswa mana pun dengan mengisi parameter metadata dan teks bab.
| Name | Required | Description | Default |
|---|---|---|---|
| metadata | Yes | ||
| bab1_data | Yes | ||
| bab2_subbab | Yes | ||
| bab3_subbab | Yes | ||
| tabel_jadwal | No | ||
| output_filename | No | Proposal Skripsi v1.0.docx | |
| daftar_referensi | Yes | ||
| tabel_tahapan_metode | No | ||
| tabel_tinjauan_pustaka | No | ||
| custom_template_filename | No | ||
| tabel_operasionalisasi_variabel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the output format (DOCX), completeness of the proposal, and the official template basis, which is meaningful. However, it does not mention side effects such as file saving, overwriting, template availability, validation, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The primary function is front-loaded, and the second sentence adds audience and input expectations without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, nested objects, many optional table inputs, no annotations, and no output schema, the description is far too thin. It does not explain required parameter structures, table formats, output file behavior, or how it relates to sibling proposal-generation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for 11 undocumented parameters. It only vaguely refers to 'parameter metadata dan teks bab', providing almost no detail about structures like bab1_data, bab2_subbab, daftar_referensi, or optional tables.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Membuat dokumen DOCX proposal skripsi lengkap' (create a complete thesis proposal DOCX document), and adds the official FILKOM UB template qualifier. It does not explicitly name sibling tools or contrast with praproposal/topic-based generation, so it does not fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it 'Dapat digunakan oleh mahasiswa mana pun' with filled metadata and chapter text, but gives no guidance on when to prefer this tool over siblings like generate_academic_praproposal or generate_proposal_from_topic. No when-to-use or when-not-to-use conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Menghasilkan dokumen pra-proposal skripsi (.odt) SA2-01A secara otomatis dari topik penelitian, data CSV literatur di workspace, dan/atau data paper yang diperoleh dari MCP paper-search. Menyusun Latar Belakang (<= 500 kata), Landasan Kepustakaan (<= 250 kata), Rumusan Masalah (numbering), Metode (<= 250 kata), dan Daftar Pustaka.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| variabel_x | No | ||
| variabel_y | No | ||
| csv_content | No | ||
| csv_filename | No | ||
| output_filename | No | Praproposal Skripsi v1.0.odt | |
| retrieved_papers | No | ||
| student_metadata | No | ||
| latar_belakang_notes | No | ||
| metode_penelitian_notes | No | ||
| custom_template_filename | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It reveals the output format and section composition but is silent on side effects (whether a file is written to the workspace and whether existing files are overwritten), authentication needs, whether paper-search must be available as a dependency, and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences that front-load the main purpose and pack the key constraints (format, form code, word limits) efficiently. No wasted words, though the second sentence's section list could arguably have been trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, zero schema descriptions, no annotations, and no output schema, the description is too thin. It doesn't explain what the tool returns (file path? confirmation?), where the file is saved, or the roles of several parameters, leaving an agent unable to assemble a correct call for all inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for 11 undocumented parameters. It explains topic, CSV data, and retrieved papers, but leaves variabel_x, variabel_y, student_metadata, latar_belakang_notes, metode_penelitian_notes, and custom_template_filename entirely unexplained, relying only on their self-evident names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (generate), resource (thesis pre-proposal .odt SA2-01A document), and the sources (topic, CSV literature, MCP paper-search). It lists the composed sections with explicit word limits (Background ≤500, Literature ≤250, Method ≤250). However, it doesn't differentiate itself from the near-twin sibling generate_academic_praproposal, which appears to produce the same kind of document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given. It never contrasts with siblings like generate_proposal_from_topic or generate_academic_praproposal, leaving an agent to guess which one to pick. The mention of sources (CSV, paper-search) implies context but provides no exclusions or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Menghasilkan dokumen proposal skripsi (.docx) lengkap hanya dengan memberikan topik penelitian, data CSV literatur di workspace, dan/atau data paper yang diperoleh dari MCP paper-search. Secara otomatis menyusun Bab 1, Bab 2 (beserta tabel tinjauan pustaka), Bab 3, dan daftar referensi, lalu menyimpannya langsung ke workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| variabel_x | No | ||
| variabel_y | No | ||
| csv_content | No | ||
| csv_filename | No | ||
| output_filename | No | Proposal Skripsi v1.0.docx | |
| retrieved_papers | No | ||
| student_metadata | No | ||
| latar_belakang_notes | No | ||
| metode_penelitian_notes | No | ||
| custom_template_filename | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It does disclose the main side effects: it generates a .docx, composes chapters, and saves the document to the workspace. However, it does not mention overwrite behavior, confirmation/return value, or prerequisites/authorization, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core purpose and inputs, and the second adds the resulting chapters and file destination. It is slightly dense with slash-separated input alternatives but stays within two purposeful sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, zero schema descriptions, no annotations, and no output schema, the description is not enough for an agent to call the tool correctly for all intended uses. It covers the headline purpose but leaves most optional parameters, file naming, and completion behavior to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate for all 11 parameters. It only clarifies topic, CSV literature data, and paper-search data; variabel_x, variabel_y, output_filename, student_metadata, latar_belakang_notes, metode_penelitian_notes, and custom_template_filename remain unexplained by both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening phrase gives a specific action and artifact: generate a complete thesis proposal .docx from a topic. It names the content (Bab 1-3, references) and key inputs, which strongly implies this is the topic-based proposal generator, though it never explicitly contrasts it with siblings like generate_praproposal_from_topic or generate_academic_proposal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is appropriate when the user has a research topic and optionally CSV literature or paper-search results, but it does not state when to prefer this tool over the sibling generators or when not to use it. No explicit exclusions or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Menghasilkan laporan audit kepatuhan proposal skripsi dalam format Markdown berdasarkan rubrik evaluasi dan checklist Research Design Canvas (Chapter 1, 2, dan 3). Dapat langsung disimpan ke workspace sebagai berkas Markdown (.md).
| Name | Required | Description | Default |
|---|---|---|---|
| student_id | Yes | ||
| student_name | Yes | ||
| proposal_title | Yes | ||
| rumusan_masalah | Yes | ||
| save_to_workspace | No | ||
| tujuan_penelitian | Yes | ||
| variabel_dependen | Yes | ||
| manfaat_penelitian | Yes | ||
| variabel_independen | Yes | ||
| output_markdown_filename | No | proposal_rubric_checklist_report.md |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the ability to save to workspace, implying a write side-effect, but does not disclose other behaviors such as whether the operation is read-only, whether it requires prior steps, or what happens when save_to_workspace is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two sentences, front-loaded with the main purpose and mentioning the save capability. It contains no extraneous information and is structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters (8 required) and no output schema, the description is incomplete. It does not describe how to provide the parameters, what constitutes valid input, or the structure of the generated report, leaving significant gaps for a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for parameters. The description does not explain any of the 10 parameters or expected formats, failing to compensate for the lack of schema documentation. An agent would have no idea what 'rumusan_masalah' or 'manfaat_penelitian' should contain beyond the parameter title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a compliance audit report in Markdown based on a rubric and Research Design Canvas for chapters 1-3. It distinguishes itself from siblings like export_proposal_as_markdown (which exports the proposal itself) and generate_academic_proposal (which generates the proposal content) by specifying the audit-report nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool over alternatives. It only implies its purpose, lacking any 'use this when' or 'instead of X' statements, so an agent receives no routing cues beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mengambil rubrik lengkap checklist Research Design Model Canvas v2.0 (LB01-LB06, LR01-LR06, M01-M05) sebagai panduan bagi pengguna atau asisten AI dalam menyusun naskah ilmiah.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden for behavioral disclosure. The verb 'Mengambil' implies a read-only retrieval, but the description does not disclose return format, required permissions, or potential absence of data. For a zero-argument getter this is minimal but acceptable; the behavior is mostly inferred rather than stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the action, the resource, and the purpose with no filler or redundancy. It is front-loaded with the verb and resource, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core purpose is covered, but the description omits the output shape and does not differentiate itself from the sibling generate_rubric_checklist_report. With no output schema and no annotations, the agent may still need to infer whether this tool returns the full checklist or the report format, so completeness is adequate but not strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline of 4 applies; there is nothing for the description to add. The description correctly does not invent parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Mengambil' = retrieves) on a specific resource (Research Design Model Canvas v2.0 rubric with codes LB01-LB06, LR01-LR06, M01-M05), which is clearly a retrieval operation distinct from sibling tools like generate_rubric_checklist_report or validate_canvas_compliance. It does not name an alternative explicitly, which keeps it below a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: 'sebagai panduan ... dalam menyusun naskah ilmiah' (as a guide for composing scientific manuscripts). It gives no explicit when-not-to-use guidance and does not contrast with sibling tools such as generate_rubric_checklist_report, leaving some ambiguity for an agent deciding between related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Menduplikasi versi aktif pra-proposal skripsi (.odt) ke versi baru dan mencatat riwayat perubahan ke version_history.json. Contoh: current_version='v1.0', new_version='v1.1', changelog='Penyesuaian rumusan masalah tunggal dan metode riset'
| Name | Required | Description | Default |
|---|---|---|---|
| changelog | Yes | ||
| new_version | Yes | ||
| current_version | Yes | ||
| filename_prefix | No | Praproposal Skripsi |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the two core behaviors (duplicating the active .odt version and recording to version_history.json) and identifies the file type. However, for a file-mutating tool it omits edge-case behavior: what happens if new_version already exists, whether current_version is validated, and overwrite semantics — gaps that are more significant given zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the primary action is front-loaded and the concrete example earns its place by illustrating parameter values. Efficient and well-ordered, though the undocumented filename_prefix could arguably have been covered in the same space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file-mutating tool with no annotations and no output schema, this is moderately complete: core action and input formats are covered, but filename_prefix semantics, edge-case/conflict behavior, and differentiation from the near-identical increment_proposal_version sibling are all missing. Adequate core, clear gaps around the edges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The example clarifies the format of current_version/new_version (v1.0, v1.1) and changelog content. However, the optional filename_prefix parameter is entirely unexplained — its purpose and default ('Praproposal Skripsi') effect are never mentioned. Compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: duplicating the active pra-proposal skripsi (.odt) to a new version and recording changes to version_history.json. The example (v1.0→v1.1) makes the action concrete. It distinguishes from the sibling increment_proposal_version only implicitly via the 'pra-proposal' resource name, not explicitly, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The near-identical sibling increment_proposal_version exists, and the description never tells an agent when to choose praproposal over proposal — the distinction is left entirely to inference from the resource name. No exclusions or conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Menduplikasi versi aktif proposal skripsi ke versi baru dan mencatat riwayat perubahan ke version_history.json. Contoh: current_version='v1.0', new_version='v1.1', changelog='Penyelarasan rumusan masalah tunggal'
| Name | Required | Description | Default |
|---|---|---|---|
| changelog | Yes | ||
| new_version | Yes | ||
| current_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core mutation: it duplicates a version and writes to version_history.json. However, it does not mention potential side effects like overwriting, validation of version format, idempotency, or what happens if the new_version already exists. While the example implies version format, it lacks depth on error conditions or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by an illustrative example. It is concise, front-loads the primary action, and includes a useful example that adds clarity without bloat. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what the tool returns or indicates success. It does not. It also doesn't mention prerequisites like the existence of the current version or the file. While the core operation is clear, an agent may wonder about the response format or error handling. For a simple mutation tool, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so by providing an example with concrete values (current_version='v1.0', new_version='v1.1', changelog='...'), which clarifies the role of each parameter. However, it does not formally describe each parameter's constraints (e.g., version format rules), leaving some interpretation to the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: duplicating the active thesis proposal version to a new version, and recording change history to a file. It clearly distinguishes from the sibling increment_praproposal_version by explicitly naming 'proposal skripsi' versus the praproposal counterpart. The example further clarifies the versioning pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (for thesis proposal versioning) but does not explicitly exclude the sibling tool for praproposals. It gives a concrete example but no direct 'when not to use' guidance. The sibling name offers implicit differentiation, but the description itself doesn't route explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Memeriksa struktur dokumen proposal skripsi (.docx) di dalam workspace. Mengembalikan informasi: jumlah paragraf, tabel, seksi, perkiraan kata, dan daftar heading bab/subbab.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Proposal Skripsi v1.0.docx |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only operation by using 'memeriksa' (inspect) and 'mengembalikan informasi' (returns information), but it does not explicitly state that it does not modify the file or mention any prerequisites or side effects. The description is adequate for a simple inspection but lacks explicit behavioral disclosures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the verb and resource, and lists the return values. It is concise and well-structured with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides the essential information: what it does and what it returns. It does not include error handling or edge cases, but those are not critical for this type of inspection tool. The description is complete enough for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'filename' with no description and 0% coverage. The description mentions 'dokumen proposal skripsi (.docx) di dalam workspace', which gives context that the filename refers to a .docx file in the workspace, adding some meaning beyond the raw schema. However, it does not explicitly state that the parameter is the file path or name, nor does it explain the default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'memeriksa' (inspect) and a clear resource 'struktur dokumen proposal skripsi (.docx)', and it explicitly lists the information returned (jumlah paragraf, tabel, seksi, perkiraan kata, daftar heading). It is clearly distinct from sibling tools like export_proposal_as_markdown or generate_rubric_checklist_report, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or comparisons with sibling tools. An agent would have to infer usage based on the name and function alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Membaca dan mem-parsing berkas CSV literatur penelitian dari workspace (misal: literature.csv). Mengekstrak kolom peneliti, tahun, judul, metode, hasil, dan research gap, serta menghasilkan matriks tabel tinjauan pustaka dan daftar referensi Harvard.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_content | No | ||
| csv_filename | No | literature.csv |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It implies a read-only parse operation ('Membaca dan mem-parsing') and discloses the extracted columns and outputs. However, it omits failure modes (e.g., missing columns, malformed CSV), whether it mutates the workspace, and any side effects. It adds value beyond the bare name but leaves meaningful behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The purpose, source, extraction columns, and outputs are packed efficiently into a compact description. The only minor inefficiency is that column extraction and output generation are listed in one long sentence, but nothing is redundant or wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description reasonably explains the inputs (CSV from workspace) and outputs (table matrix, Harvard references). However, it leaves gaps around parameter usage (csv_content vs csv_filename), error handling, and the structure of the produced matrix/references. Moderate complexity tool that could benefit from a usage note and clearer parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It references the default filename literature.csv, which clarifies csv_filename, but it never explains the csv_content parameter (when to pass raw CSV content vs relying on the workspace file, format expectations, or the interaction between the two parameters). Parameter names are somewhat self-explanatory, but the description adds little semantic depth beyond what the schema names convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (reads/parses), a clear resource (literature CSV files from workspace), the exact columns extracted (researcher, year, title, method, results, research gap), and the concrete outputs produced (literature review table matrix, Harvard reference list). This clearly distinguishes it from sibling tools that focus on proposals, compliance, or checklists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the tool reads from workspace files (e.g., literature.csv), which gives mild context. However, it provides no explicit when-to-use guidance, no exclusions, and no mention of alternatives. An agent must infer when parsing a literature CSV is the right call versus using proposal-generation siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Menurunkan rumusan masalah tunggal, variabel independen (X), variabel dependen (Y), tujuan penelitian terukur, serta kueri pencarian literatur yang dioptimalkan khusus untuk dijalankan pada MCP paper-search (search_arxiv, search_semantic, search_google_scholar).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| variabel_x | No | ||
| variabel_y | No | ||
| bidang_kajian | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies the tool outputs a plan and search queries, but it does not state whether the tool is read-only, whether it performs any searches itself, how outputs are returned, or whether any side effects occur. This leaves the agent guessing about external calls and mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one dense sentence, front-loaded with the main deliverable and free of filler. It loses a point because the long-final list of outputs reads more like a clause rather than an intuitive roadmap, but the content is concise and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a 0% schema-description coverage, the description leaves an agent without a clear expected output shape or workflow. It communicates the conceptual output but not enough operational detail for correct usage, such as optional parameter effects, formats, or handling when no variables are supplied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never names the actual parameters topic, variabel_x, variabel_y, or bidang_kajian. Although it mentions variabel X/Y concepts, it doesn't map them to the schema. The meaning of topic and bidang_kajian must be inferred entirely from the input-schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description names a concrete output: a single problem statement, independent/dependent variables, measurable objective, and literature-search queries. It is clearly distinct from siblings that generate full proposal text, because it explicitly targets MCP paper-search queries. However, it stops short of naming sibling tools to contrast with, so a small clarity gap remains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The only usage signal is that the produced queries are intended for paper-search MCP tools, but the description does not explain when this planning tool should be chosen over generate_proposal_from_topic or generate_academic_proposal. It also doesn't warn against using siblings for planning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Memvalidasi kepatuhan naskah proposal terhadap panduan Research Design Model Canvas v2.0. Dapat digunakan untuk segala topik skripsi/tesis. Memeriksa:
Rumusan masalah tunggal dan berorientasi pengukuran (non-deskriptif).
Variabel independen (X) dan dependen (Y) yang terdefinisi eksplisit.
Tujuan penelitian yang linier dengan capaian variabel.
Manfaat penelitian spesifik bagi stakeholders (bebas klausul klise).
| Name | Required | Description | Default |
|---|---|---|---|
| rumusan_masalah | Yes | ||
| tujuan_penelitian | Yes | ||
| variabel_dependen | Yes | ||
| manfaat_penelitian | Yes | ||
| single_problem_only | No | ||
| variabel_independen | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the validation criteria in detail (four checks), which is useful behavioral context. However, it does not state what the output looks like, whether it returns a pass/fail, a list of violations, or a score, nor does it mention any side effects (it appears read-only). The description adds value by listing the checks but lacks output/behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence and a numbered list of checks. It is concise and front-loaded with the main purpose. The numbered list is easy to parse. It could be slightly more compact, but the structure is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is moderately complete. It explains the validation criteria and the inputs, but it does not describe the return value/format, which is important for an agent to know what to do with the result. It also doesn't clarify the 'single_problem_only' parameter. For a validation tool, the output format is a significant missing piece.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description mentions the four main inputs (rumusan masalah, variabel independen/dependen, tujuan penelitian, manfaat penelitian) in its checklist, which maps to the required parameters. However, it does not explain the 'single_problem_only' boolean parameter, which is in the schema but not described. The description adds some meaning but leaves a gap for one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: validating a proposal manuscript against the Research Design Model Canvas v2.0 guidelines. It specifies the resource (naskah proposal) and the action (memvalidasi kepatuhan), and lists the four specific compliance checks. It distinguishes itself from siblings like generate_rubric_checklist_report or get_canvas_guidelines by focusing on validation of a manuscript against the canvas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it can be used for any thesis/dissertation topic, which gives a clear context. It does not explicitly name alternatives or when-not-to-use, but the sibling list shows related tools like get_canvas_guidelines (for retrieving guidelines) and generate_rubric_checklist_report (for generating a report), which are distinct. The usage context is clear enough, though explicit exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0export_proposal_as_markdowngenerate_academic_praproposalgenerate_academic_proposalgenerate_praproposal_from_topicgenerate_proposal_from_topicgenerate_rubric_checklist_reportget_canvas_guidelinesincrement_praproposal_versionincrement_proposal_versioninspect_proposal_documentparse_literature_csv_dataplan_proposal_researchvalidate_canvas_complianceScored across 13 tools
Tools have distinct purposes generally, but some overlap exists between generate_academic_proposal and generate_proposal_from_topic, as both create full proposal DOCX files, differing mainly in input method. Similarly, increment_proposal_version and increment_praproposal_version are distinct by format, so that's fine.
Most tools follow a verb_noun pattern like 'export_proposal_as_markdown', 'generate_academic_proposal', but there is inconsistency: 'validate_canvas_compliance' uses a noun-verb-noun order, and 'generate_rubric_checklist_report' is long and less consistent than others. Also, two tools use different phrasing for similar actions ('increment_proposal_version' vs 'generate_academic_proposal').
With 13 tools, the server is slightly on the heavier side but still within a reasonable range for a comprehensive academic proposal server covering proposal, praproposal, versioning, validation, and literature parsing. Each tool contributes to the workflow, though a few could be merged without loss.
The server covers the main lifecycle: planning (plan_proposal_research), generation (generate_academic_proposal, generate_proposal_from_topic), validation (validate_canvas_compliance), inspection (inspect_proposal_document), versioning (increment_proposal_version), and export (export_proposal_as_markdown). Minor gaps include no explicit tool for updating proposal content after generation or deleting versions, but agents can work around via versioning.
Generate on-brand proposals, reports, and contracts instantly. Auto-extracts brand from any URL.
Deterministic research automation with live OpenAlex search and reusable workflow programs.
Research portfolio management — organize projects and track research artifacts.
End-to-end agent-managed company brain. Docs, diagrams, plans, Knowledge Graph. Lean & affordable.
