Install Jentic One Beta

Connect the Phare to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Phare, 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%2Fphare.io%2Fphare" | sh

Step 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%2Fphare.io%2Fphare" | sh
jentic register       # connects your agent to your Jentic One instance

Jentic 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.

Capabilities

What an agent can do with Phare API.

Create HTTP, TCP, or ICMP uptime monitors with check regions, an interval, and success assertions

Pause and resume a monitor during planned work, or delete it

Report uptime statistics for one monitor or the whole project between from and to timestamps

Open an incident with an impact such as partial_outage or major_outage and post updates through investigating to resolved

GET STARTED

Start building with Phare API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use Phare API for, with concrete tasks.

★ Incident response agent through Jentic

When an alert fires, an AI agent can handle the status communication while engineers fix the problem. Through Jentic the agent searches for 'open an uptime incident', loads the Phare createUptimeIncident operation with its input schema, and opens an incident with a title, impact, and exclude_from_downtime flag, then posts updates as the state moves from investigating to resolved. The bearer token is injected at call time by your own Jentic One instance.

Call POST /uptime/incidents with title 'Checkout errors', impact 'partial_outage', and exclude_from_downtime false, then POST /uptime/incidents/{incidentId}/updates with state 'identified' and content describing the cause

Monitor setup from a service inventory

Platform teams add monitoring as part of shipping a new service. Creating a Phare monitor needs a name, a protocol of http, tcp, or icmp, the request to send, and between one and six regions, with an optional interval, timeout, success assertions, and confirmation counts before an incident opens or recovers.

Call POST /uptime/monitors with name 'Marketing site', protocol 'http', a request for https://example.com, regions from the spec's region list, and interval 60

Deploy-safe maintenance windows

Planned work should not page anyone or count as downtime. A maintenance window needs a title, monitoring_mode, starts_at, and ends_at, and can attach monitors and status pages so visitors see the scheduled work. Windows can be cancelled or completed early, and individual monitors can be paused and resumed around a deploy.

Call POST /uptime/maintenance-windows with title 'Database upgrade', monitoring_mode, starts_at, and ends_at for the planned slot, then POST /uptime/maintenance-windows/{maintenanceWindowId}/complete when the work finishes

Uptime reporting for stakeholders

Monthly service reviews need uptime numbers per service. The project report aggregates uptime statistics for a from and to window, and the per-monitor report breaks out a single monitor, so an agent can assemble a summary without exporting from the dashboard.

Call GET /uptime/reports with from and to covering last month, then GET /uptime/monitors/{monitorId}/report for the lowest-uptime monitor

Key Endpoints

48 endpoints — the phare api runs uptime monitoring, incidents, and status pages for the phare.

METHOD

PATH

DESCRIPTION

POST

/uptime/monitors

Create a monitor

POST

/uptime/monitors/{monitorId}/pause

Pause a monitor

GET

/uptime/monitors/{monitorId}/report

Get a monitor's uptime statistics

GET

/uptime/reports

Get aggregated uptime statistics

POST

/uptime/incidents

Create an incident

POST

/uptime/incidents/{incidentId}/updates

Post an incident update

POST

/uptime/maintenance-windows

Schedule a maintenance window

GET

/uptime/status-pages/{statusPageId}/current-status

Get a status page's current status

POST

/uptime/monitors

Create a monitor

POST

/uptime/monitors/{monitorId}/pause

Pause a monitor

GET

/uptime/monitors/{monitorId}/report

Get a monitor's uptime statistics

GET

/uptime/reports

Get aggregated uptime statistics

POST

/uptime/incidents

Create an incident

POST

/uptime/incidents/{incidentId}/updates

Post an incident update

POST

/uptime/maintenance-windows

Schedule a maintenance window

GET

/uptime/status-pages/{statusPageId}/current-status

Get a status page's current status

Why Jentic?

What agents get from Jentic-routed access to this vendor.

Setup

Wiring Phare by hand means creating a bearer token, sending it in the Authorization header, and adding an X-Phare-Project-Id or X-Phare-Project-Slug header on project operations when the key is organization-scoped. Through Jentic you install once, import Phare from the API Directory, store the token once, and your agent calls it.

Permission scoping

Phare puts the monitor id in the URL path (/uptime/monitors/{monitorId}/pause), so a rule can pin your agent to one monitor and the operations you pick. You choose the operations it may call, so destructive ones like deleting a monitor or a status page are not included unless you add them.

Credential isolation

Your Phare token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.

Intent-based discovery

Agents search Jentic by intent such as 'open an uptime incident' or 'pause a monitor', and Jentic returns the matching Phare operation with its input schema, including the required fields, so the agent calls the right endpoint without browsing the reference docs.

FAQs

Specific to using Phare API through Jentic.

What authentication does the Phare API use?

The Phare API authenticates with a bearer token (BearerAuth) per its OpenAPI spec, sent as 'Authorization: Bearer <token>'. With an organization-scoped API key, project-level operations also need an X-Phare-Project-Id or X-Phare-Project-Slug header to pick the project. Through Jentic the token is stored by your own instance and attached at call time.

Can I pause a monitor during a deploy with the Phare API?

Yes. POST /uptime/monitors/{monitorId}/pause stops checks for that monitor and POST /uptime/monitors/{monitorId}/resume starts them again. For longer planned work, a maintenance window attaches monitors and status pages to a scheduled starts_at and ends_at.

What are the rate limits for the Phare API?

The OpenAPI spec does not specify API rate limits. Check the Phare documentation at https://docs.phare.io for current limits. Note that the rate_limit field on alert rules controls how often an alert fires, not how often you can call the API.

Is there a Phare MCP server?

You don't need an MCP server to give your agent Phare. Jentic connects it directly from the API Directory: import it, store your token once, and your agent calls the monitor, incident, and status page operations on demand without loading another server's tool definitions into its context.

How do I open an incident through Jentic?

Search Jentic for 'open an uptime incident', load the POST /uptime/incidents operation, and execute it with the required title, impact, and exclude_from_downtime fields, optionally linking monitors. Then post progress with the incident updates operation. To run it on your own infrastructure, install Jentic One from its GitHub repo.

Can I limit what my agent is allowed to do with the Phare API?

Yes. Write a rule that allows GET /uptime/monitors/{monitorId}/report plus the pause and resume operations for one monitor id, and the agent can read that monitor's uptime and pause it around a deploy while other monitors and status pages stay untouched. Every call it makes is logged for review.

Phare

AI ReadinessAI-Aware (B)63/100

See full scorecard

Official vendor OpenAPI document · agent-readyDeveloper ToolsMonitoring Observabilitybearer48 EndpointsREST

For Agents

Create and pause Phare uptime monitors, read uptime reports, open and update incidents, schedule maintenance windows, and manage status pages and alert rules.

Use for: Create an HTTP monitor for https://example.com checking every minute, Pause the monitor for the API while we deploy, Get the uptime report for last month, Open a major outage incident for the checkout service

Not supported: Does not collect application logs, traces, or performance metrics, and does not run on-call paging schedules. Use for uptime monitors, incidents, maintenance windows, and status pages only.

The Phare API runs uptime monitoring, incidents, and status pages for the phare.io platform. It creates HTTP, TCP, and ICMP monitors that check from up to six regions at intervals from 30 seconds to an hour, pauses and resumes them, and reports uptime statistics per monitor or across a project for a time window. Incidents carry an impact level and a timeline of updates, maintenance windows can be scheduled, cancelled, or completed, and alert rules route events to integrations such as Slack, Discord, Telegram, email, SMS, ntfy, ilert, Pushover, and outgoing webhooks.

Jentic One on Github View OpenAPI Document

Show dimension breakdown

Foundational Compliance

Base layer of spec validity and structural soundness.

Grade: DSignals: 4

86%

Lint Results

Aggregated quality score from linter diagnostics, weighted by severity.

100%

Resolution Completeness

Percentage of `$ref` references that resolve successfully.

Specification Validity

Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).

Structural Integrity

Structural correctness score based on schema issues using logarithmic dampening.

Developer Experience & Jentic Compatibility

Clarity, completeness, and ingestion readiness for developers and tooling.

Grade: A-Signals: 4

49%

Example Density

How richly the API is illustrated with examples.

95%

Example Validity

Percentage of examples that conform to their schemas.

50%

Response Coverage

Percentage of operations with complete response definitions (success, client error, server error).

100%

Tooling Readiness

Health of API ingestion, bundling, and resolution within Jentic pipelines.

AI-Readiness & Agent Experience

Semantic breadth, depth, and agent comprehension for AI systems.

Grade: C+Signals: 4

66%

Description Coverage

Coverage of descriptions across API elements.

Error Standardization

Coverage of RFC 9457 Problem Details for error responses.

100%

OperationId Quality

Coverage, uniqueness, and casing consistency of operationIds for AI inference.

64%

Summary Coverage

Coverage of summaries across operations/tags/info.

Agent Usability

Functional utility, complexity comfort, and AI orchestration readiness.

Grade: A+Signals: 1

94%

Complexity Comfort

Agent comfort level based on API operational and structural complexity.

Security

Trust, risk posture, and security compliance.

Grade: B-Signals: 1

60%

Authentication Strength

Average quality of security schemes based on authentication method strength (weakest link for OAuth2).

AI Discoverability

Findability, semantic richness, and reasoning readiness.

Grade: BSignals: 1

64%

Descriptive Richness

Clarity and depth of descriptions across API elements.

Connect the Phare to your agent

Capabilities

Start building with Phare API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

Phare

Jentic AI Readiness Score

Phare

Foundational Compliance

Lint Results

Resolution Completeness

Specification Validity

Structural Integrity

Developer Experience & Jentic Compatibility

Example Density

Example Validity

Response Coverage

Tooling Readiness

AI-Readiness & Agent Experience

Description Coverage

Error Standardization

OperationId Quality

Summary Coverage

Agent Usability

Complexity Comfort

Security

Authentication Strength

AI Discoverability

Descriptive Richness