DRA-MCP
OfficialClick 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., "@DRA-MCPGenerate a business trip application to Dresden for a project meeting on 12 Oct 2026 by train."
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.
Dienstreiseantrag Model Context Protocol (DRA-MCP)
A model context protocol server for filling out business trip application forms.

Note that DRA-MCP is in early stage of development. It may later be used in production and for teaching. Hence, suggestions and improvements are welcome, as long as we don't over-engineer it.
Setup
It is recommended to install uv first.
git clone https://github.com/scads/dra-mcp
cd dra-mcp
uv syncPut reusable applicant details in .env:
SERVICE_UNIT=
APPLICANT_NAME=
DEPARTMENT=
OFFICE_PHONE=
HOME_ADDRESS=
ADDITIONAL_HOME_ADDRESS=
TEMPORARY_STAY_ADDRESS=
IBAN=
BIC=
BANK_NAME=This file is ignored by Git because it may contain personal and banking information.
If you use this tool via an MCP-compatible AI-agent such as Jan.AI (open source), it is recommended to use privacy-preserving, local-only Large Language Models. If you use a cloud-service for this, be aware that information such as your home adress and bank account might be shared with this cloud service provider!
Related MCP server: Trip Planner MCP Server
MCP server
business_trip_mcp_server.py exposes create_business_trip_application as an MCP
tool via FastMCP, so an MCP-compatible AI agent can fill
out and generate the PDF for you. It also ships a
business_trip_travel_planning_guide prompt with detailed rules for choosing the
transport mode (train vs. flight) and estimating realistic departure/return
dates and times, assuming the traveller starts from Leipzig.
Install dependencies and run the server with uv:
uv sync
uv run python business_trip_mcp_server.pyPoint your MCP-compatible client (e.g. Jan.AI) at
this command (uv run python business_trip_mcp_server.py, working directory
dra-mcp) to add it as a stdio MCP server. Most clients (Jan.AI, Claude Desktop,
VS Code, ...) accept a JSON config such as:
{
"mcpServers": {
"dra": {
"active": true,
"args": [
"--directory",
"path/to/dra-mcp",
"run",
"business_trip_mcp_server.py"
],
"command": "uv"
}
}
}Use via Terminal and Python (without AI agents)
python business_trip.py --help
python business_trip.py `
--application-kind business-trip `
--destination "Dresden" `
--purpose "Project meeting" `
--departure-date 2026-10-12 `
--outbound-train `
--return-train `
--output completed-trip.pdfThe CLI accepts options for all applicant-editable text fields, choices, and checkboxes. Omitted fields stay blank in the PDF. Boolean options support both --option and --no-option; radio choices are listed by --help.
The same function can be called from Python:
from business_trip import create_business_trip_application
create_business_trip_application(
"completed-trip.pdf",
destination="Dresden",
purpose="Project meeting",
outbound_train=True,
)Contributing
Contributions are welcome! Please feel free to submit a Pull Request. Note: Large parts of the code in this repository were vibe-coded using GitHub Copilot integration in Visual Studio Code. When modifying code here, consider using a similar tool.
Acknowledgements
We acknowledge the financial support by the Federal Ministry of Research, Technology and Space of Germany and by Sächsische Staatsministerium für Wissenschaft, Kultur und Tourismus in the programme Center of Excellence for AI-research „Center for Scalable Data Analytics and Artificial Intelligence Dresden/Leipzig“, project identification number: ScaDS.AI
Available Tools
1 toolcreate_business_trip_applicationCreate Business Trip ApplicationA
You are helping fill out a German business-trip application (Dienstreiseantrag).
The applicant is based in Leipzig, Germany. Use the following rules to decide
transport mode, checkboxes, and dates before calling create_business_trip_application.
Do not make up information! E.g. if you don't know the applicant's home address, IBAN,
or other personal details, leave them None or null (not empty string).
You must provide these fields, and you need to reason some of them based on what is
given by the user:
destination (at least postal code + city + country, if not in Germany)
purpose (meeting name or similar)
departure_date
departure_time
business_start_date
business_start_time
business_end_date
business_end_time
return_date
return_time
These fields are optional and not required:
service_unit
applicant_name
department": "Antragsteller.Referat",
office_phone
home_address
additional_home_address
temporary_stay_address
overnight_cost_per_night
private_car_reason (only required if using a private car for traveling)
flight_reason (only required if using a flight for traveling)
private_stay_from
private_stay_until
private_stay_destination
iban
bic
bank_name
explanations
explanations_continuation
application_date If the user didn't provide them, do not fill them! Keep them None / null.
Choosing the transport mode
Destinations inside Germany, or otherwise reachable comfortably by rail in a few hours (e.g. neighbouring countries such as Poland, Czechia, or nearby parts of Austria/Netherlands), should use train + public transport for both legs: set
outbound_train=True,outbound_bus_or_public_transport=True,return_train=True,return_bus_or_public_transport=True.Destinations that are far away, overseas, or would otherwise require a very long train ride (roughly more than half a day of travel each way, e.g. most of Western/Southern Europe onward, or anywhere outside Europe) should use flight instead: set
outbound_flight=Trueandreturn_flight=True. Useflight_reason/flight_reason_continuationto justify the choice if asked.Only select one primary mode per leg unless additional legs (e.g. bus/public transport to/from the airport or station) are genuinely part of the journey.
Estimating departure and return dates/times
Assume the traveller starts and ends every trip in Leipzig. Before setting
departure_date/departure_time and return_date/return_time, estimate the
one-way travel time from Leipzig to the destination (and back):
Nearby destinations reachable within roughly 2-3 hours (e.g. Dresden, Berlin, Halle): same-day travel is fine; departure can be the morning of
business_start_dateand return the evening ofbusiness_end_date.Mid-distance destinations requiring roughly half a day of travel each way (e.g. Paris, Munich to a far corner of Germany, most of Central Europe by train, or a short flight including airport transfer time): if
business_start_timeis in the early morning (roughly before 9-10am), the traveller cannot arrive in time same-day, so setdeparture_dateto the day BEFOREbusiness_start_date(with an afternoon/eveningdeparture_time). Otherwise, an early-morning departure onbusiness_start_dateitself may be reasonable. Apply the same logic symmetrically to the return: ifbusiness_end_timeis late in the day and travel home would take half a day, setreturn_dateto the day AFTERbusiness_end_date; only keep the return on the same day if there is clearly enough remaining time after the business ends.Long-distance/overseas destinations reachable only by flight: budget extra time for airport transfers, check-in, and connections. Set the departure the day before the business start whenever the start time plus necessary travel time would not otherwise be reachable, and similarly delay the return by a day when the business end time is late.
When in doubt, prefer arriving with a comfortable buffer (e.g. arriving the evening before an early-morning meeting) over risking a missed appointment, but avoid padding travel by more than necessary (don't add a full travel day for a destination that's only 1-2 hours away).
Note that departure_date and departure_time must be reasonably BEFORE
business_start_date and business_start_time, and return_date and return_time
must be reasonably AFTER business_end_date and business_end_time.
General notes
Dates accepted by the tool are
YYYY-MM-DDorDD.MM.YYYY; times are free text (e.g. "08:00").Personal fields (home address, IBAN, etc.) fall back to values in
.envif not provided; do not invent these values yourself, ask the user if they are missing and not already on file.Leave fields unset (do not guess) when information is genuinely unknown; blank fields stay empty in the generated PDF for the applicant or office to fill in later.
When the application was created, provide a markdown link to the file, e.g. .
| Name | Required | Description | Default |
|---|---|---|---|
| bic | No | ||
| iban | No | ||
| purpose | Yes | ||
| bank_name | No | ||
| breakfast | No | ||
| department | No | ||
| destination | Yes | ||
| return_date | Yes | ||
| return_time | Yes | ||
| explanations | No | ||
| home_address | No | ||
| office_phone | No | ||
| return_train | No | ||
| service_unit | No | ||
| bahncard_rate | No | ||
| flight_reason | No | ||
| meal_provider | No | ||
| return_flight | No | ||
| travel_end_at | No | ||
| applicant_name | No | ||
| bahncard_class | No | ||
| departure_date | Yes | ||
| departure_time | Yes | ||
| outbound_train | No | ||
| travel_card_to | No | ||
| bahncard_number | No | ||
| outbound_flight | No | ||
| application_date | No | ||
| application_kind | No | ||
| requests_advance | No | ||
| travel_card_from | No | ||
| business_end_date | Yes | ||
| business_end_time | Yes | ||
| employment_status | No | ||
| overnight_payment | No | ||
| private_stay_from | No | ||
| travel_start_from | No | ||
| bonus_program_name | No | ||
| overnight_provider | No | ||
| overnight_required | No | ||
| private_car_reason | No | ||
| private_stay_until | No | ||
| return_private_car | No | ||
| business_start_date | Yes | ||
| business_start_time | Yes | ||
| meals_provided_free | No | ||
| return_official_car | No | ||
| bahncard_valid_until | No | ||
| outbound_private_car | No | ||
| outbound_official_car | No | ||
| has_field_service_role | No | ||
| return_other_transport | No | ||
| temporary_stay_address | No | ||
| additional_home_address | No | ||
| additional_participants | No | ||
| uses_official_air_miles | No | ||
| outbound_other_transport | No | ||
| overnight_cost_per_night | No | ||
| private_stay_destination | No | ||
| explanations_continuation | No | ||
| uses_personal_travel_card | No | ||
| flight_reason_continuation | No | ||
| participates_in_bonus_program | No | ||
| return_bus_or_public_transport | No | ||
| private_car_reason_continuation | No | ||
| return_other_transport_selected | No | ||
| return_passenger_in_private_car | No | ||
| outbound_bus_or_public_transport | No | ||
| outbound_other_transport_selected | No | ||
| outbound_passenger_in_private_car | No | ||
| requests_flight_cost_reimbursement | No | ||
| requests_recognition_for_private_car | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses accepted date/time formats, that missing personal fields fall back to .env rather than being invented, that unknown fields stay null (blank in the PDF), and that the output is a PDF referenced by markdown link. It does not mention auth/permissions or side effects beyond file creation.
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?
Given the complexity, the length is largely justified and it is well front-loaded and organized under markdown headers. There is minor waste and a malformed artifact ('department": "Antragsteller.Referat"') that slightly mars an otherwise clean structure.
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?
An output schema exists, so return-value documentation is unnecessary, and the description instead covers the required-field contract, transport reasoning, and output-link convention. The main remaining gap is the large set of undocumented optional parameters.
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% across 72 parameters, so the description must compensate. It explains the 10 required fields well (destination format, the transport-mode booleans, and date/time semantics) and lists several optionals, but dozens of parameters (bahncard_*, meal/overnight fields, bonus-program, travel_end_at, employment_status, application_kind) are never described, leaving the agent to infer from 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 opening line states a specific verb and resource: helping create/fill out a German business-trip application (Dienstreiseantrag), with the creation call named explicitly. There are no sibling tools to differentiate from, and the scope (destination, transport, dates) is immediately legible.
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 gives unusually rich context on how to reason before calling: transport-mode selection rules, date/time estimation logic, and the constraint that departure precedes business_start and return follows business_end. It stops short of stating when NOT to use the tool, but no alternatives exist to route against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
create_business_trip_application
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of misselection or overlapping purpose. The tool's purpose is clearly stated and distinct.
The single tool uses a clear snake_case verb_noun pattern (create_business_trip_application), consistent with common MCP naming conventions.
A single tool for a complex, specialized task feels thin. While it covers creation, the expected range for a well-scoped server is typically 3–15 tools, so this is borderline.
The tool covers creation of a business trip application but lacks read, update, or delete operations. The lifecycle is incomplete for managing applications beyond initial creation.
Maintenance
Related MCP Connectors
Travel tools for AI agents: plan and edit real trips, search stays and tours, import travel videos.
TravelMind: 8 MCP tools for travel (12306 trains, flights, hotels, geocode, planning, policy).
- geoOAuthco.thinair
Geocoding, routing, isochrones, traffic, weather, and place search for AI agents. 19 MCP tools.
Read and update your Everway trips and itineraries from any MCP-compatible AI assistant.
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables AI agents to plan trips by searching flights, accommodations, and activities, and managing itineraries collaboratively with role-based permissions.206 npm26 PyPI1MIT
- FlicenseNot gradedqualityDmaintenanceEnables managing travel itineraries with CRUD tools for journeys, stops, and plan items, plus weather lookup, integrated with public MCP servers for time and web search.-
- FlicenseNot gradedqualityCmaintenanceEnables travel-related queries and planning including weather, train and flight information, itinerary generation, and travel knowledge retrieval via RAG, using an AI agent with MCP protocol.-
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to plan trips in MyNextAdventure by creating trips, managing itineraries, adding flights, hotels, and activities, and sharing results through the MCP protocol.MIT