Documentation

Guidelines for writing and maintaining documentation for the vCon MCP Server project.

Table of Contents


Documentation Types

1. API Reference (docs/api/)

Purpose: Complete reference for all tools, resources, prompts, types, and schemas.

Audience: Developers integrating with or extending the server.

Content:

  • All input/output parameters

  • Type definitions

  • Examples for every function

  • Error responses

  • Performance characteristics

2. User Guides (docs/guide/)

Purpose: Help users accomplish specific tasks.

Audience: End users and developers using the server.

Content:

  • Step-by-step instructions

  • Common use cases

  • Troubleshooting

  • Best practices

3. Developer Guides (docs/development/)

Purpose: Help developers contribute to the project.

Audience: Contributors and maintainers.

Content:

  • Architecture explanation

  • Code standards

  • Testing procedures

  • Plugin development

4. Examples (docs/examples/)

Purpose: Practical code examples and tutorials.

Audience: All users, especially beginners.

Content:

  • Complete working examples

  • Real-world scenarios

  • Copy-paste ready code

5. Reference (docs/reference/)

Purpose: Technical specifications and standards.

Audience: Advanced developers and spec implementers.

Content:

  • IETF vCon spec details

  • Database schema

  • Protocol specifications

  • Migration guides


Writing Style

General Principles

  1. Be Clear - Use simple, direct language

  2. Be Concise - Get to the point quickly

  3. Be Consistent - Follow established patterns

  4. Be Complete - Cover all necessary information

  5. Be Accurate - Keep documentation current

Voice and Tone

  • Use active voice: "The server validates..." not "The vCon is validated by..."

  • Use second person: "You can create..." not "One can create..."

  • Be direct: "Set the environment variable" not "You might want to consider setting..."

  • Be helpful: Include context and reasoning

Examples

Good:

The server validates the structure and returns the UUID.


Markdown Standards

Headings

Use ATX-style headings (with #):

Rules:

  • Only one H1 per document

  • Don't skip heading levels

  • Use sentence case for headings

  • Add a blank line before and after headings

Lists

Unordered lists:

Ordered lists:

Task lists:

Internal links:

External links:

Emphasis

Tables

Alignment:

Admonitions

Use blockquotes with emoji for callouts:


Code Examples

Code Blocks

Always specify the language:

Complete Examples

Provide complete, working examples:

Inline Code

Use backticks for:

  • Function names: createVCon()

  • Variable names: vconUuid

  • File names: config.ts

  • Command names: npm

  • Type names: VCon

Terminal Commands

Show commands and expected output:

Multi-Step Examples

Number steps clearly:


API Documentation

Tool Documentation Template

Type Documentation Template


User Guides

Guide Structure

  1. Title - Clear, action-oriented

  2. Introduction - What you'll learn

  3. Prerequisites - What's needed

  4. Steps - Numbered, clear instructions

  5. Verification - How to confirm success

  6. Troubleshooting - Common issues

  7. Next Steps - What to do next

Example Guide Template


Build and Deploy

VitePress Setup

The documentation uses VitePress. To work on docs:

Adding New Pages

  1. Create markdown file in appropriate directory

  2. Add to sidebar in docs/.vitepress/config.ts

  3. Link from index or related pages

  4. Test locally before committing

Example sidebar config:

Documentation Workflow

  1. Create branch for documentation changes

  2. Write/update documentation

  3. Test locally with npm run docs:dev

  4. Check links are working

  5. Build with npm run docs:build

  6. Commit with appropriate message

  7. Create PR for review

Keeping Docs Updated

When code changes:

When adding features:

Documentation Review Checklist

Before submitting documentation:


Style Guide Summary

Do's ✅

  • Use clear, simple language

  • Provide complete examples

  • Include error handling

  • Show expected output

  • Link to related content

  • Keep content current

  • Test all examples

Don'ts ❌

  • Use passive voice excessively

  • Skip error cases

  • Assume prior knowledge

  • Use jargon without explanation

  • Provide incomplete examples

  • Leave content outdated

  • Include untested code


Documentation Templates

New Feature Documentation

When adding a new feature, create:

  1. API Reference - Complete technical specs

  2. User Guide - How to use the feature

  3. Example - Working code example

  4. Changelog Entry - What changed

Bug Fix Documentation

When fixing a bug:

  1. Update relevant docs where bug was documented

  2. Add troubleshooting entry if user-facing

  3. Update changelog with fix details

Deprecation Documentation

When deprecating a feature:

  1. Add deprecation notice to docs

  2. Document migration path to replacement

  3. Update changelog with timeline

  4. Keep old docs with "DEPRECATED" header


Resources

Tools

  • VS Code with Markdown Preview

  • Grammarly for spell/grammar checking

  • markdown-link-check for broken links

  • VitePress documentation framework

References


Questions?

  • Check existing documentation for examples

  • Ask in GitHub Discussions

  • Review recent PRs for documentation changes

  • Contact documentation maintainers

Remember: Good documentation is as important as good code! 📚

Last updated