A context-to-action control plane for AI agents: connect an agent, see what it does, and control what it is allowed to cause
Four tools with complete schemas and descriptions, but descriptions are domain-specific and lack LLM-optimized guidance. All tools are READ_ONLY (good security posture). Schemas are well-formed with typed parameters and defaults. However, descriptions focus on what the API returns rather than when/why an LLM should call the tool. No error handling guidance, no parameter constraints (enums), and no output schema documentation. Tool names are clear (verb_noun pattern) but descriptions average ~150 chars and lack actionable context for agent selection.
What this agent is currently authorised to do - the same declared/granted/observed/undeclared/ungranted/capability_outside_authority/unused_authority drift view GET /v1/agents/{id}/drift returns.
The latest Authority Contract governing this agent, if any was issued with contract_id "<agent_id>-<domain>-starter" (the convention agent_plane.domains.{software,cloud}'s suggested_contract() uses) or explicitly passed via contract_id.
Why one specific decision was allowed, denied, or required approval - the full trace GET /v1/decisions/{id} returns.
Who is this agent, per the registry: definition, lifecycle state, identity assurance, trust domain.
Descriptions lack LLM-optimized guidance on WHEN to call each tool. Descriptions state WHAT the API returns but not WHEN an agent should select this tool vs. a similar one, or what prerequisites exist.
No output schema documentation. Tools return complex objects (agent definitions, authority drift views, decision traces, contracts) but the response structure is not documented for LLM planning.
No error handling guidance. If an agent_id is invalid or a decision_id does not exist, the tool provides no recovery hint (e.g., 'Try search_agents() first' or 'Decision not found; check audit logs').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Parameter 'tenant' has a default value ('default') but no description explaining what a tenant is or when to override it. LLMs cannot infer multi-tenancy semantics.
Tool names do not clearly distinguish between querying agent identity (whoami), querying agent permissions (authority), and querying authorization decisions (explain_decision). Descriptions should clarify the distinction.