MoDora HTTP Skill

Use this skill to analyze PDFs with a remote MoDora HTTP service. This skill requires a user-provided settings.json and sends the user's model endpoint and A...

Security Scan

The skill's code and docs consistently implement a PDF -> remote MoDora server flow that uploads a user-owned settings.json containing model endpoints and API keys (with an explicit consent guard), but the registry metadata omits the environment variables the scripts actually use and the behavior involves transmitting sensitive credentials to an external operator — proceed only with caution and a trusted server.

Purpose & Capability

The skill's name and description match what the code does: upload PDFs, poll processing, and ask questions via a remote MoDora HTTP server. Asking the user to supply a settings.json that includes their model endpoint and API key is coherent with the stated design (the remote server will use those credentials to call the user's model). However, the registry metadata did not declare the environment variables the scripts read (MODORA_BASE_URL, MODORA_ALLOW_REMOTE_CREDENTIALS, MODORA_SETTINGS_FILE), which is a metadata inconsistency that reduces transparency.

Instruction Scope

The SKILL.md and scripts explicitly instruct the agent to read an absolute file path and send the contents of a user-provided settings.json (including API keys and base_url) to the remote server via /api/upload and /api/chat. The scripts enforce explicit acknowledgement before sending credentials (command-line flag or MODORA_ALLOW_REMOTE_CREDENTIALS=1) and intentionally avoid falling back to server defaults. Functionally this stays within the advertised purpose but it does transmit highly sensitive data off-host, which is a real privacy/exfiltration risk that must be accepted by the user/operator.

Install Mechanism

No install spec or third-party downloads; the skill is instruction + small Python scripts that use only the standard library (urllib, json, pathlib, etc.). Nothing is written to disk by a package installer. This is lower risk from an install mechanism perspective.

Credentials

The runtime uses several environment variables (MODORA_BASE_URL to select the target server, MODORA_ALLOW_REMOTE_CREDENTIALS for consent, MODORA_SETTINGS_FILE as an alternative to --settings-file) and requires the user to supply a settings.json with api_key and base_url for their model. Those env vars and the need to provide credentials are proportionate to the skill's function, but the registry metadata did not list them as required; the skill therefore omits important declarations. Also, the skill will transmit whatever is in settings.json to the remote operator, so users should avoid using high-privilege production keys.

Persistence & Privilege

The skill is not always-enabled and does not request persistent platform privileges. It does not modify other skills or system-wide agent configuration. It runs only when invoked and requires explicit consent to transmit credentials.

What to consider before installing

This skill will send the contents of a user-supplied settings.json (including model base_url and api_key) to whatever MODORA_BASE_URL you point it at. The scripts require explicit consent (a --allow-remote-credentials flag or MODORA_ALLOW_REMOTE_CREDENTIALS=1) before sending credentials, and they do not fall back to server defaults. Before installing or running: 1) only use this with a MoDora server operator you trust; 2) prefer creating a limited-scope API key (not a production admin key); 3) verify MODORA_BASE_URL points to the expected host and consider running MoDora locally if you cannot trust a third party; 4) be aware the registry metadata omitted the env vars the scripts use (MODORA_BASE_URL, MODORA_ALLOW_REMOTE_CREDENTIALS, MODORA_SETTINGS_FILE) — double-check and set them deliberately; 5) if you need higher assurance, review and run the included Python scripts in an isolated environment before giving any credentials.

MoDora

Use this skill to work with a deployed MoDora service over HTTP.

This skill is for external skill access, not for the logged-in MoDora web UI.

Security Warning

This skill sends the user's settings.json to the remote MoDora service. That file may contain model endpoints and API credentials.

The intended behavior of this MoDora deployment is to use those settings only for the current request flow and not as a shared server default for other users. This deployment is not intended to maliciously store or reuse those credentials. However, the credentials are still transmitted to a remote service, and that trust boundary is real.

Only use this skill if you trust the operator of the target MoDora server. If you do not trust that server, do not use this skill and deploy MoDora locally instead.

This skill is appropriate when the user wants to:

• upload a PDF to MoDora
• wait for document preprocessing to complete
• ask questions about one uploaded document
• verify that the public MoDora service is reachable

This skill assumes the MoDora backend is exposed as an HTTP base URL. Set MODORA_BASE_URL before running scripts. Example:

export MODORA_BASE_URL="http://42.193.125.159:18081"

If MODORA_BASE_URL is unset, scripts default to http://127.0.0.1:8005.

The scripts are implemented in Python so they work across Linux, macOS, Windows, and WSL as long as python3 is available.

Skill access is separate from the logged-in frontend:

• skill requests send X-Modora-Client: skill
• skill requests do not use the frontend login session
• skill requests must provide a user-owned settings JSON file
• skill requests cannot use server default model instance IDs such as local-default or remote-default
• if the user does not provide a valid settings file, the skill must stop instead of falling back to server defaults
• skill scripts require explicit acknowledgement before sending credentials to the remote MoDora service

Required settings file

Every skill invocation that uploads a document or asks a question must provide a user-owned settings.json.

Start from settings.template.json and fill in the user's own values.

The settings file must:

• be provided by the skill user, not copied from the server UI defaults
• be completed by the agent or user with the user's own model credentials and endpoints
• include pipelines.<module>.modelInstance for each pipeline module
• define model instances that include the user's own api_key, base_url, and model identifier where required
• avoid server default model instance IDs such as local-default and remote-default
• use multimodal-capable model instances for the MoDora pipeline

MoDora requires multimodal models. Do not choose text-only models for OCR-adjacent reasoning, enrichment, retrieval, metadata generation, or QA.

If the user does not provide this file, stop and report the requirement. Do not continue with upload or QA.

Preferred workflow

1. Prepare a settings.json file owned by the skill user. A good starting point is skills/modora/settings.template.json.
2. Run python skills/modora/scripts/health.py to verify the backend is alive.
3. Confirm that you trust the remote MoDora service operator and explicitly allow remote credential transfer.
4. Run python skills/modora/scripts/upload.py /absolute/path/to/file.pdf --settings-file /path/to/settings.json --allow-remote-credentials to upload a document.
5. Run python skills/modora/scripts/wait.py <filename> until processing reaches completed.
6. Run python skills/modora/scripts/chat.py <filename> "<question>" --settings-file /path/to/settings.json --allow-remote-credentials to ask a question.

For the common one-shot flow, prefer:

python skills/modora/scripts/analyze_pdf.py /absolute/path/to/file.pdf "Your question" --settings-file /path/to/settings.json --allow-remote-credentials

Rules

• Always use an absolute file path when uploading.
• Always provide a user-owned settings JSON file.
• The agent should help fill in the user's own API settings instead of relying on server defaults.
• Explicitly confirm remote credential transfer before running upload or chat commands.
• Never fall back to server-side defaults when the settings file is missing.
• Do not call chat.py before the task status becomes completed.
• Do not use server default model instance IDs such as local-default or remote-default.
• Use multimodal-capable model instances across the MoDora pipeline.
• If the backend returns an error, surface the response body instead of hiding it.
• If the service is unreachable, tell the user the MoDora public backend is not available.
• If the user supplies a different service URL, set MODORA_BASE_URL for that command.

Script summary

• scripts/health.py: GET /health
• scripts/upload.py: POST /api/upload after explicit remote credential acknowledgement
• scripts/wait.py: poll GET /api/task/status/{filename}
• scripts/chat.py: POST /api/chat after explicit remote credential acknowledgement
• scripts/analyze_pdf.py: health -> upload -> wait -> chat with explicit remote credential acknowledgement