Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the AppDeploy MCP API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fappdeploy.ai%2Fappdeploy" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fappdeploy.ai%2Fappdeploy" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with AppDeploy MCP API.
Create and update web application deployments
Apply a specific version to a deployed app
List and inspect apps, deployment status, versions, logs, and source
Change an app's configuration
Delete an app under an explicit destructive scope
GET STARTED
Patterns agents use AppDeploy MCP API for, with concrete tasks.
★ AI agent deploying an app
A coding agent that has just built a change needs to ship it without a developer running deploy commands. Through Jentic the agent searches for deploying a new app version, loads the deployment operation with its OAuth credentials already injected, and submits the deployment request. The agent gets back the deployment result so it can confirm the ship succeeded.
Call POST /mcp with a request to create a deployment for the app and confirm the returned status
Deployment status checks
An agent monitoring a release reads deployment status, versions, and logs to decide whether a rollout is healthy. AppDeploy's read scope lists and inspects apps, deployment status, versions, logs, and source, so the agent can report on a release without write access. This supports a read-only monitoring role separate from the agent that ships changes.
Call POST /mcp with a request to read the current deployment status and recent logs for an app
Configuration updates
An operations agent needs to change an app's configuration and apply it as part of a deployment. AppDeploy's write scope covers creating or updating deployments, applying versions, and changing configuration, so the agent can adjust settings and roll them out in the same flow. The delete scope stays separate so configuration work never risks removing the app.
Call POST /mcp with a request to update the app configuration and apply the new version
3 endpoints — the appdeploy api deploys and manages web applications through a single json-rpc endpoint, with oauth scopes that separate reading deployment state from writing versions and removing apps.
METHOD
PATH
DESCRIPTION
/mcp
Send a JSON-RPC deployment message
/.well-known/oauth-protected-resource/mcp
Get the protected-resource metadata
/.well-known/oauth-authorization-server
Get the authorization-server metadata
/mcp
Send a JSON-RPC deployment message
/.well-known/oauth-protected-resource/mcp
Get the protected-resource metadata
/.well-known/oauth-authorization-server
Get the authorization-server metadata
What agents get from Jentic-routed access to this vendor.
Setup
Wiring the AppDeploy API by hand means completing its OAuth 2.0 authorization code flow with PKCE and dynamic client registration, or falling back to a bearer token, and routing every tool call through its single JSON-RPC endpoint. Through Jentic you install once, import AppDeploy from the API Directory, store the credentials once, and your agent calls it.
Permission scoping
AppDeploy declares separate OAuth scopes for reading deployment state, writing deployments, and deleting apps. You choose the operations your agent may call, so you can allow the read and write operations and leave the destructive delete out of the allowed set unless you add it.
Credential isolation
Your AppDeploy credentials are stored once, encrypted, by your own Jentic One instance, which completes the OAuth exchange at execution time. They never enter the agent's prompt, logs, or context, nor does the resulting access token.
Intent-based discovery
Agents search Jentic by intent such as 'deploy a new app version' or 'check deployment status', and Jentic returns the matching AppDeploy operation with its input schema so the agent calls the right one without reading the reference docs.
Alternatives and complements available in the Jentic catalogue.
Specific to using AppDeploy MCP API through Jentic.
What authentication does the AppDeploy API use?
The AppDeploy API uses OAuth 2.0 with the authorization code flow, PKCE, and dynamic client registration, declaring separate scopes for reading, writing, and deleting, per its OpenAPI spec. Clients that cannot complete OAuth may send a bearer access token or API key instead, though OAuth is preferred because it carries scopes. The two discovery endpoints need no credential. Through Jentic the OAuth exchange runs at call time, so the agent receives only a scoped token.
Can I deploy a new app version with the AppDeploy API?
Yes. With the write scope, an agent sends a deployment request to POST /mcp to create or update a deployment and apply a version. The read scope then lets it confirm the deployment status and inspect logs without any further write access.
What are the rate limits for the AppDeploy API?
The OpenAPI spec does not define request-rate ceilings. Throughput is governed by your AppDeploy plan and the scopes your token holds. Check the AppDeploy documentation for the limits that apply to your account before scripting frequent deployments.
Is there an AppDeploy MCP server?
AppDeploy exposes its tools through a JSON-RPC endpoint, and Jentic connects that endpoint directly from the API Directory using its OpenAPI spec. Import the API, store your OAuth credentials once, and your agent calls the deployment operations on demand, with no separate server to run or keep loaded in the agent's context.
Can I limit what my agent is allowed to do with the AppDeploy API?
Yes. Write a rule that allows only the read and write scopes, so the agent can inspect deployments and ship new versions but cannot invoke the destructive delete scope that removes an app, and every call it makes is logged. You add the delete scope to the allowed set only when you explicitly want it.
How do I deploy an app through Jentic?
Search Jentic for 'deploy a new app version', load the deployment operation, and run it after your OAuth credentials are stored. To run it on your own infrastructure, install Jentic One from its GitHub repo.
For Agents
Deploy and manage web applications: create and update deployments, apply versions, read status and logs, change configuration, and delete apps under scoped permissions.
Use for: Deploy a new version of my app, Check the status of a deployment, List my deployed apps, Read the logs for an app
Not supported: Does not host databases, manage DNS, or run CI build pipelines. Use for deploying and managing web applications only.
The AppDeploy API deploys and manages web applications through a single JSON-RPC endpoint, with OAuth scopes that separate reading deployment state from writing versions and removing apps. Read operations list and inspect apps, deployment status, versions, logs, and source; write operations create or update deployments, apply versions, and change app configuration; a separate delete scope covers removing an app. Two discovery endpoints publish the OAuth protected-resource and authorization-server metadata so clients can complete the auth flow.
This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.
Base layer of spec validity and structural soundness.
Aggregated quality score from linter diagnostics, weighted by severity.
Percentage of `$ref` references that resolve successfully.
Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).
Structural correctness score based on schema issues using logarithmic dampening.
Clarity, completeness, and ingestion readiness for developers and tooling.
How richly the API is illustrated with examples.
Percentage of examples that conform to their schemas.
Percentage of operations with complete response definitions (success, client error, server error).
Health of API ingestion, bundling, and resolution within Jentic pipelines.
Semantic breadth, depth, and agent comprehension for AI systems.
Coverage of descriptions across API elements.
Coverage of RFC 9457 Problem Details for error responses.
Coverage, uniqueness, and casing consistency of operationIds for AI inference.
Coverage of summaries across operations/tags/info.
Functional utility, complexity comfort, and AI orchestration readiness.
Agent comfort level based on API operational and structural complexity.
Trust, risk posture, and security compliance.
Average quality of security schemes based on authentication method strength (weakest link for OAuth2).
Findability, semantic richness, and reasoning readiness.
Clarity and depth of descriptions across API elements.
Score it yourself
Every API in the directory is allowlisted, so you can re-score it with no key required.
npx @jentic/api-scorecard-cli score <openapi-url>