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 "Install 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 |
| One-shot generator for academic pre-proposal form ( |
|
| Assembles and generates a complete academic pre-proposal document ( |
|
| Generates a comprehensive academic audit checklist report in Markdown format based on standard evaluation rubrics. |
|
| Validates research proposal rigor against standard academic research design principles. |
|
| Retrieves the complete rubric and checklist for academic research design criteria. | (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. |
|
| 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 of a proposal document (paragraph count, table count, sections, words, heading tree). |
|
| 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}"
}
}
}
}generate_academic_proposal)Here is an example payload using fictional student and institutional data:
{
"metadata": {
"judul": "OPTIMIZING DISTRIBUTED SENSOR NETWORK LIFETIME USING REINFORCEMENT LEARNING ROUTING ALGORITHMS",
"nama_mahasiswa": "Alex Mercer",
"nim": "STD-2026-94821",
"program_studi": "Department of Computer Science & Informatics",
"departemen": "School of Computing",
"fakultas": "Faculty of Engineering and Technology",
"universitas": "Metropolis Institute of Technology",
"kota": "Metropolis",
"tahun": "2026"
},
"bab1_data": {
"latar_belakang": [
"The rapid proliferation of Internet of Things (IoT) devices in environmental monitoring has introduced critical challenges regarding power efficiency and network longevity in wireless sensor networks (WSNs).",
"Conventional routing protocols, such as static shortest-path routing, frequently exhaust intermediate relay nodes prematurely, resulting in network fragmentation and degraded data reliability.",
"To overcome these operational constraints, this research proposes an adaptive reinforcement learning routing mechanism that dynamically balances energy expenditure across network nodes while sustaining throughput."
],
"rumusan_masalah_pengantar": "Based on the operational challenges and efficiency gaps identified above, the primary research question is formulated as follows:",
"rumusan_masalah": "To what extent does the proposed reinforcement learning routing algorithm improve overall network lifetime and packet delivery ratio compared to conventional static routing protocols in large-scale wireless sensor networks?",
"rumusan_masalah_penjelasan": "This single research question evaluates the causal relationship between the independent variable (reinforcement learning routing mechanism) and key dependent performance indicators (network operational lifetime and packet delivery ratio).",
"tujuan_umum": "evaluate and quantify the network longevity and transmission efficiency improvements achieved by the reinforcement learning routing protocol compared to baseline routing approaches.",
"tujuan_khusus": [
"Analyze the energy consumption profiles and bottleneck factors in baseline sensor routing workflows.",
"Design and model the adaptive reinforcement learning routing algorithm.",
"Develop a proof-of-concept simulation environment for multi-hop sensor networks.",
"Evaluate network lifetime, packet delivery ratio, and convergence time through rigorous benchmark simulations."
],
"manfaat": [
"For Sensor Network Practitioners: Provides an operational blueprint for resilient and energy-balanced wireless sensor deployments.",
"For Academic Researchers: Contributes empirical evidence and benchmark datasets regarding reinforcement learning applications in low-power communication systems."
],
"batasan_masalah": [
"Evaluation is conducted within a simulated network environment consisting of 100 to 500 heterogeneous nodes.",
"Hardware-level physical layer modifications are outside the scope of this investigation.",
"Channel conditions are modeled based on standard log-distance path loss propagation."
],
"sistematika_pembahasan": [
"CHAPTER 1 INTRODUCTION: Details background context, research problem formulation, objectives, practical and theoretical benefits, scope limitations, and outline.",
"CHAPTER 2 LITERATURE REVIEW: Synthesizes foundational networking concepts, reinforcement learning formulations, prior benchmark studies, and identified research gaps.",
"CHAPTER 3 METHODOLOGY: Defines research design, experimental testbed parameters, evaluation metrics, and timeline."
]
},
"bab2_subbab": [
{
"title": "Wireless Sensor Network Routing Protocols",
"level": 2,
"paragraphs": [
"Routing protocols in sensor networks must strike a delicate balance between routing overhead and battery conservation. Standard multi-hop schemes often incur uneven drain rates on central clusters."
]
},
{
"title": "Reinforcement Learning in Dynamic Networks",
"level": 2,
"paragraphs": [
"Q-learning and policy-gradient algorithms enable decentralized agents to discover optimal forwarding policies through continuous environmental reward feedback."
]
}
],
"bab3_subbab": [
{
"title": "Simulation Design and Experimental Setup",
"level": 2,
"paragraphs": [
"The experimental framework is implemented using an event-driven network simulator modeling randomized node deployments and Poisson packet arrival processes."
]
}
],
"daftar_referensi": [
"Akyildiz, I.F., Su, W., Sankarasubramaniam, Y. & Cayirci, E., 2002. Wireless sensor networks: a survey. Computer Networks, 38(4), pp.393–422.",
"Sutton, R.S. & Barto, A.G., 2018. Reinforcement learning: An introduction. 2nd ed. Cambridge: MIT Press."
],
"output_filename": "Proposal Skripsi v1.0.docx"
}generate_proposal_from_topic)Instead of writing out every chapter by hand, you can generate a complete proposal by prompting with just a Topic, an optional literature CSV file, or retrieved research papers:
{
"topic": "Optimizing Distributed Sensor Network Lifetime using Reinforcement Learning Routing Algorithms",
"variabel_x": "Reinforcement Learning Adaptive Q-Routing",
"variabel_y": "Network Operational Longevity and Packet Delivery Ratio",
"csv_filename": "literature.csv",
"output_filename": "Proposal Skripsi v1.0.docx"
}The server will automatically:
Formulate a single, measurable research question: "Sejauh mana implementasi [X] mampu meningkatkan [Y] secara terukur..."
Parse the CSV file and generate the literature review comparison matrix (tabel_tinjauan_pustaka) and Harvard citations (daftar_referensi).
Generate Chapters 1, 2, and 3 formatted according to academic guidelines.
Run Research Design Canvas v2.0 validation checks.
Save the final .docx directly into your mounted workspace.
generate_praproposal_from_topic)Generate an official pre-proposal form document (.odt, format SA2-01A) directly from a topic prompt:
{
"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",
"jenis_penelitian": "Implementatif",
"tipe_penelitian": "Pengembangan Sistem & Komparasi Algoritma",
"asal_judul": "Usulan Sendiri",
"lokasi": "Malang",
"nama_pembimbing": "Dr. Mahrus Ali, S.Kom., M.Kom.",
"nip_pembimbing": "-"
},
"output_filename": "Praproposal_Skripsi_SA2-01A.odt"
}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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
