MCP

What It Is

Jetstack exposes an MCP server over JSON-RPC with support for:

  • protocol initialization
  • tools listing and invocation
  • resources listing and reading
  • resource templates
  • prompts listing and retrieval

Why It Matters

MCP gives Jetstack a structured tool- and resource-oriented integration surface, especially useful for agentic clients and AI-enabled runtime scenarios.

Protocol Notes

The server negotiates among supported protocol versions and exposes a server-style capability model rather than a simple REST endpoint shape.

Main Capability Areas

Tools

Tools expose executable tenant functionality in a structured way. This is especially relevant when another system or agent should perform controlled actions rather than just read data.

Resources

Resources expose structured readable content and may also expose templates for parameterized resource retrieval.

Prompts

Prompts allow prompt discovery and retrieval for agent-facing workflows.

Operational Importance

MCP matters operationally because some remote AI providers need public MCP reachability. That makes MCP configuration both an application concern and a deployment concern.

Identity, Permissions, And Application Users

MCP access is not anonymous. It runs under a Jetstack user identity carried by the bearer token used for MCP authentication.

That means MCP access inherits the same core control model as the rest of the platform:

  • the acting user identity matters
  • the user’s roles define the baseline permission envelope
  • object writes remain attributable to that identity

On top of that user-bound identity, MCP tokens may also carry MCP-specific scope restrictions for:

  • allowed tools
  • allowed resources
  • allowed prompts
  • selected MCP features

This combination is important. The user identity defines the main permission context, and MCP-specific scopes can narrow the exposed surface even further.

For production MCP integrations, create a dedicated non-human User rather than reusing a personal account.

Recommended setup:

  1. Create a User dedicated to the MCP client or agent domain.
  2. Assign only the roles the MCP integration actually needs.
  3. Place the user into a dedicated Group such as Application access.
  4. Issue or derive the MCP token from that user context.
  5. Apply MCP-specific scopes where the integration should see only a subset of tools or resources.

Why this matters

  • accountability is preserved in object metadata
  • permission reviews stay understandable
  • revocation does not disrupt a real person’s account
  • agent-oriented access can be constrained twice: by user roles and by MCP scopes

Datetime Handling

Datetime values exchanged through MCP follow the same conventions as the REST API:

  • storage is UTC end-to-end
  • record-write tools (jetstack_record_create, jetstack_record_update, jetstack_record_patch) accept ISO 8601 with explicit offset (2026-05-22T09:00:00+02:00) and convert to UTC for storage
  • filter values on jetstack_record_list follow the same rules
  • the jetstack_query SQL tool relies on MySQL's native ISO 8601 handling — its tool description spells out the acceptable parameter shapes, and the LLM is expected to send UTC-equivalent values
  • pDate and pMonth fields are calendar values without time or timezone semantics

Full rules in REST API → Timezones.

Best Practices

  • document which tools and resources are intended for external or agent use
  • keep protocol expectations aligned between client and server
  • review public reachability requirements before enabling provider-side MCP use
  • use dedicated application users instead of personal accounts for persistent MCP integrations
  • group service identities separately so administrators can review them easily
  • when writing tool-using prompts, prefer ISO 8601 with explicit offset for any user-supplied wall-clock — it avoids ambiguity in the LLM's translation step
Previous← Internal Api ReferenceNextRest Api Reference →