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.

​
Manifest structure

The manifest MUST be provided to the Agent Runtime before the agent loop begins. The formal schema is defined in agent_capability_manifest_schema.json. Minimal structure: 
{
  "id": "org:example/agent:researcher-v1",
  "capabilities": []
}

​
Capabilities

The field capabilities is REQUIRED. Each entry MUST include:
  • id — a manifest-local identifier for the declared agent capability.
  • description — a human-readable description of what the agent is designed to do.
{
  "capabilities": [
    {
      "id": "files_editing",
      "description": "Can inspect and modify files in a project workspace."
    },
    {
      "id": "version_control",
      "description": "Can inspect repository state and prepare local commits."
    }
  ]
}
Capability IDs are local references within a single manifest. GPARS v0.1 does not assign global semantics to these IDs, does not define a universal capability ontology, and does not require Action Planes to infer concrete MCP tools from them. They exist so Agent Runtimes, Action Planes, user interfaces, deployment configuration, and audit logs can refer to the same declared agent behavior. Capability declarations describe the agent’s intended classes of behavior. They do not describe what the environment must provide, they are not a precondition for starting the agent loop, and they are not authorization grants. Concrete MCP client wiring, MCP server selection, tool exposure, and policy enforcement are controlled outside the manifest by Agent Runtime configuration and the Action Plane.

​
Identity field

The id field is REQUIRED. It MUST uniquely identify the agent within its operational domain. The format, issuance mechanism, and verification model are implementation-defined in v0.1.

​
Capability descriptions

Capability descriptions in v0.1 are human-readable and non-authoritative. They help users, Agent Runtimes, and Action Plane components understand what the agent is designed to do, but they do not define permissions and MUST NOT be treated as authorization grants. Whether the agent is actually permitted to exercise any operation is determined by the user’s security policy.