Skip to main content

Documentation Index

Fetch the complete documentation index at: https://gpars.io/llms.txt

Use this file to discover all available pages before exploring further.

​
Activation and processing flow

1

Manifest provided

The Agent provides the manifest to the Agent Runtime.
2

Validation

The Agent Runtime validates manifest structure and manifest-local capability references.
3

Agent loop begins

The agent loop begins. The agent’s lifecycle is independent of MCP server availability.
4

MCP request issued

When the agent issues an MCP request, it passes through the plane boundary enforcement point.
5

Identity verification

The enforcement point verifies the agent’s identity using infrastructure under the user’s control (not by trusting the manifest’s id field).
6

Policy evaluation

The enforcement point evaluates the request against the user’s security policy. Operations that violate the policy are denied with AUTHORIZATION_DENIED.
7

Availability check

If the target MCP server is unavailable, the enforcement point returns SERVER_UNAVAILABLE. The agent MAY retry, wait, or adapt its approach.
8

Request forwarded

If the request is permitted and the server is available, the enforcement point forwards the request. The MCP server processes it and returns a result or an operational error (e.g., invalid parameters, resource not found).
The manifest is a declarative statement of what the agent is designed to do — not an activation gate or provisioning request. The Agent Runtime validates the manifest, while concrete MCP client wiring is provided by runtime or deployment configuration outside the manifest. Concrete MCP server binding, policy enforcement, and availability are controlled at the Action Plane boundary. MCP servers handle operational concerns; the enforcement point handles security concerns.