Provides MCP-based access to the shared instruction, skill, and prompt registry for GitHub Copilot in VS Code, and generates native VS Code instruction and skill projections.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@universal-agent-control-plane Register a new code-review prompt template and validate compatibility across hosts"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An open-source control plane for sharing instructions, Agent Skills, prompts, tools, and optional state across AI agents in VS Code and other MCP-compatible hosts.
The project has one core goal:
Author reusable agent guidance once, validate it once, and deliver it through each host's supported mechanism without pretending every host has identical semantics.
This project is an alpha-stage local developer tool. Review generated user-level configuration before using it on a production workstation, and do not expose the HTTP gateway beyond localhost without adding authentication and transport security.
The diagram is embedded as SVG so GitHub can display it directly. Open the self-contained interactive architecture map for the full browser view.
The design uses two complementary delivery paths:
Native user-scope installation creates host-compatible instruction projections and live links to canonical skills.
MCP delivery exposes tools, prompts, resources, and optional shared state through the Model Context Protocol.
MCP is the integration protocol, not an instruction override mechanism. Each agent host still decides which resources, prompts, and tools it discovers, loads, or invokes.
Related MCP server: skillet
The original concept is valid, but several assumptions have changed:
GitHub Copilot in VS Code supports MCP servers natively. A custom REST wrapper is not required for current MCP-capable versions of VS Code.
VS Code supports portable Agent Skills stored in .github/skills/, .claude/skills/, or .agents/skills/, as well as user-level equivalents.
VS Code recognizes multiple instruction formats, including .github/copilot-instructions.md, AGENTS.md, CLAUDE.md, .github/instructions/*.instructions.md, and .claude/rules/.
Claude Code supports MCP, CLAUDE.md, .claude/rules/, and filesystem-based Agent Skills.
Skills and instructions are portable only where their host semantics overlap. A resolver and adapter layer is still useful for validation, precedence, compatibility checks, and installation.
This repository therefore aims for shared source, explicit adapters, and honest capability negotiation rather than claiming that all agents behave identically.
universal-agent-control-plane/
├── README.md
├── LICENSE
├── CHANGELOG.md
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── SECURITY.md
├── pyproject.toml
├── AGENTS.md
├── server.py
├── .vscode/
│ └── mcp.json
├── .github/
│ ├── ISSUE_TEMPLATE/
│ ├── workflows/
│ │ └── ci.yml
│ ├── dependabot.yml
│ └── pull_request_template.md
├── docs/
│ ├── universal-agent-control-plane.html
│ └── universal-agent-control-plane.svg
├── registry/
│ ├── manifest.yaml
│ ├── instructions/
│ │ └── global.md
│ ├── skills/
│ │ └── example-skill/
│ │ └── SKILL.md
│ └── prompts/
│ └── code-review.md
├── src/
│ └── universal_agent_control_plane/
│ ├── api.py
│ ├── cli.py
│ ├── execution.py
│ ├── global_install.py
│ ├── logging_config.py
│ ├── orchestration.py
│ ├── server.py
│ ├── registry.py
│ ├── storage.py
│ └── runners/
│ └── greeting.py
└── tests/
├── test_api.py
├── test_execution.py
├── test_global_install.py
├── test_orchestration.py
├── test_registry.py
└── test_storage.pyThe repository now includes a working Python MCP server, canonical registry, example skill and prompt, SQLite-backed shared state, VS Code configuration, and focused tests.
Component | Responsibility |
Canonical registry | Versioned source for instructions, skills, prompt templates, manifests, and compatibility metadata |
Registry resolver | Validates schemas, resolves scope and precedence, and produces a deterministic effective configuration |
MCP gateway | Exposes standard MCP tools, prompts, and resources over |
Global installer | Merges user MCP configuration, adds managed instruction projections, and creates live links to canonical skills |
Policy and state | Applies authorization and capability rules; stores optional namespaced state and append-only audit events |
Agent hosts | Consume MCP capabilities and/or native files according to host behavior and user approval |
Prefer standard MCP primitives instead of inventing REST-like endpoint names.
instructions://catalog
instructions://effective/{profile}
skills://catalog
skills://{name}/manifest
registry://manifestResources are the natural fit for discoverable, read-only context such as effective instructions and skill metadata.
review_codePrompts provide user-selectable templates. They should not be treated as silently injected system instructions.
registry_search
registry_validate
registry_resolve
skill_run
orchestrate
state_get
state_putTool schemas must be explicit and validated. skill.run should dispatch only to allow-listed implementations declared in the registry; it must never import an arbitrary module name supplied by a client.
The registry manifest should describe both content and compatibility:
schemaVersion: 1
profiles:
default:
instructions:
- instructions/global.md
skills:
- example-skill
targets:
vscode:
instructions: true
agentSkills: true
mcp:
tools: true
prompts: true
resources: true
claude-code:
instructions: true
agentSkills: true
mcp:
tools: true
prompts: true
resources: trueThe resolver should fail clearly when a target cannot represent a requested feature. Silent conversion would make behavior unpredictable.
Canonical source, generated projections Edit registry content, not generated host files.
Standards before adapters Use MCP and the Agent Skills standard directly where supported. Add adapters only for real semantic gaps.
Deterministic resolution Scope, precedence, inheritance, and conflicts must produce repeatable output with an explainable resolution trace.
Least privilege Separate read-only resources from mutating tools. Require explicit grants for filesystem, process, network, secret, and state access.
Human approval Hosts should preserve confirmation for consequential tool calls. The server must not disguise side effects.
Untrusted content boundaries Registry documents, tool results, remote resources, and skill packages are data—not authority. Validate paths, schemas, signatures, and origins.
Portable core, host-specific edges Keep shared skills portable, while allowing clearly labeled host extensions when a capability is not universal.
The first implementation should include:
localhost-only binding by default for Streamable HTTP
Origin validation and authentication for HTTP connections
environment or secret-store credentials rather than committed tokens
path traversal prevention and a configured registry root
allow-listed skill runners with declared permissions
input and output schema validation
per-client authorization and least-privilege scopes
namespaced, concurrency-safe state storage
append-only audit records for mutations and skill execution
resource size, execution time, and concurrency limits
no dynamic import or shell execution from untrusted skill names
A shared memory.json file is not sufficient for concurrent clients, access control, or crash-safe writes. SQLite is a reasonable local MVP; a pluggable store can follow.
Define the manifest and content schemas.
Load and validate instructions, prompts, and SKILL.md packages.
Resolve one profile deterministically.
Add unit tests for invalid paths, duplicate IDs, conflicts, and precedence.
Install user skills into supported directories as live links.
Generate a VS Code instruction projection and a managed Claude import.
Merge global MCP configuration without replacing unrelated servers.
Support dry-run, status/doctor, conflict detection, idempotent sync, and managed-only uninstall.
Implement stdio transport first.
Expose registry resources, prompt templates, and read-only validation tools.
Add localhost Streamable HTTP; authentication remains required before remote exposure.
Add permission-declared, allow-listed skill execution.
Add namespaced SQLite state and audit events.
Add contract tests against installed VS Code and Claude Code clients.
Publish a Python package and a reproducible launcher.
Install VS Code and Agent Host user configuration through the CLI.
Document migration from existing .github, .claude, and .agents customizations.
Injecting hidden system prompts into an agent host
Overriding a host's safety policy or tool approval UI
Guaranteeing identical model behavior across vendors
Treating executable skills as trusted merely because they are in the registry
Replacing native instruction and Agent Skills support when it already works
Building multi-agent orchestration before registry, transport, and security contracts are stable
The included .vscode/mcp.json starts the local server with the workspace virtual
environment. Install the project first:
.\.venv\Scripts\python.exe -m pip install -e ".[dev]"The root launcher keeps local use simple:
# Native stdio MCP
.\.venv\Scripts\python.exe .\server.py
# Streamable HTTP MCP plus REST compatibility routes
.\.venv\Scripts\python.exe .\server.py --httpThen open MCP: List Servers in VS Code and start
universal-agent-control-plane. The equivalent configuration is:
{
"servers": {
"universal-agent-control-plane": {
"command": "${workspaceFolder}\\.venv\\Scripts\\python.exe",
"args": [
"-m",
"universal_agent_control_plane.server"
],
"env": {
"PYTHONPATH": "${workspaceFolder}\\src",
"UACP_REGISTRY_ROOT": "${workspaceFolder}\\registry",
"UACP_DATA_DIR": "${workspaceFolder}\\.data"
]
}
}
}The server uses stdio by default and exposes:
resources: registry://manifest, instructions://effective/{profile},
skills://catalog, and skills://{name}/manifest
prompt: review_code
tools: registry_validate, registry_resolve, registry_search, skill_run,
orchestrate, state_get, and state_put
Run the optional localhost gateway:
.\.venv\Scripts\python.exe -m universal_agent_control_plane.apiThis exposes the native Streamable HTTP MCP endpoint at
http://127.0.0.1:8000/mcp and interactive REST documentation at
http://127.0.0.1:8000/docs.
REST compatibility routes are:
GET /health
GET /instructions?profile=default
GET /skills
POST /execute
POST /copilot/skill
GET /memory?namespace=...&key=...
POST /memory
POST /orchestrate
Current VS Code and Claude clients should use the native MCP endpoint. The REST routes exist for older clients, scripts, and extension commands; they do not imitate MCP tool discovery.
Skill runner modules are explicitly allow-listed in registry/manifest.yaml. Their
source modification time is checked on each call and changed modules are reloaded
without restarting the server. Both server modes write structured JSON logs to stderr
and .data/server.log.
Secrets must use environment files, input variables, or the platform secret store rather than literal values in this file.
The global installer makes the canonical registry available to supported agents in every workspace while leaving repository-level instructions available for project-specific rules.
# Preview destinations and conflicts; this performs no writes.
.\.venv\Scripts\uacp.exe install-global --dry-run
# Install global instructions, live skill links, and MCP configuration.
.\.venv\Scripts\uacp.exe install-global
# Reconcile managed links/configuration after adding or removing registry skills.
.\.venv\Scripts\uacp.exe sync-global
# Inspect the current installation.
.\.venv\Scripts\uacp.exe doctor
# Remove only UACP-managed files, links, blocks, and MCP entries.
.\.venv\Scripts\uacp.exe uninstall-globalThe installer owns only these projections:
Consumer | Managed user-scope projection |
VS Code/Copilot instructions |
|
Claude instructions | Marked import block in |
VS Code MCP | Merged server entry in |
Copilot Agent Host MCP | Merged server entry in |
Portable skills | Live links under |
On Windows, the live skill links use directory symbolic links when available and directory
junctions otherwise. They point to registry/skills, so editing a canonical SKILL.md
takes effect without copying it into every host directory.
Claude Code reads the canonical instruction file through its managed
@uacp-registry/instructions/global.md import. VS Code/Copilot reads a small global
instruction projection whose Markdown link targets the same canonical file. The installer
never overwrites an existing skill directory that it does not own and never replaces
unrelated MCP servers.
If the Claude CLI is installed, install-global registers the stdio server at user scope.
If it is absent, the install still configures Claude instructions and skills and returns
the exact claude mcp add-json ... --scope user command to run later.
Global configuration supplies defaults; it does not remove native project customization. Keep repository-specific behavior in the host-supported project files, such as:
.github/copilot-instructions.md
.github/instructions/*.instructions.md
AGENTS.md
CLAUDE.md and .claude/rules/
project-local .github/skills, .claude/skills, or .agents/skills
Project files should contain only rules specific to that repository. Avoid copying the global instruction set into each project.
Contributions are welcome. Start with CONTRIBUTING.md, follow the Code of Conduct, and review the Security Policy before reporting a vulnerability.
Use GitHub Issues for reproducible bugs and focused feature requests.
Use pull requests for reviewed changes; the CI workflow runs the supported Python test matrix automatically.
See CHANGELOG.md for release history.
One canonical registry can be consumed by current VS Code/Copilot and Claude Code.
Effective instructions and skills can be explained before installation.
Standard MCP discovery works for tools, prompts, and resources.
Installation is idempotent and supports dry-run, status, sync, and managed-only rollback.
Mutating actions are authenticated, authorized, validated, and audited.
Contract and security tests cover both supported clients.
Route one skill result to an agent target or a broadcast result envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| payload | Yes | ||
| skill_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It does not disclose whether the routing operation is async, mutating, validating, or what side effects occur per target value such as 'claude', 'copilot', 'other', or 'broadcast'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant content. The main cost is undefined terminology like 'result envelope', but the structure itself is efficient and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters, no annotations, and zero parameter descriptions, this description is too thin. An agent would not know what payload to provide, what the target options mean, or what a broadcast result envelope actually represents, making the tool under-specified for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only lightly maps to the parameters via 'skill result' and 'target'. It does not explain what payload should contain, what skill_name refers to, or what each target value actually does, so it fails to compensate for the schema's missing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Route', and identifies both the resource ('one skill result') and the destination types ('agent target or broadcast result envelope'). This clearly distinguishes it from sibling tools like skill_run, though the phrase 'result envelope' is somewhat jargon-heavy and not defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool or when to prefer an alternative. It implies a post-skill routing step, but it does not mention prerequisites, relationships to siblings, or conditions for choosing one target type over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a profile into effective instructions and skill metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | default |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It reveals that the tool computes effective instructions and skill metadata, implying a read-only resolution process, but it does not disclose whether any state changes occur, how defaults are handled, what 'effective' means, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff and places the core action first. However, it is so brief that it omits important contextual and behavioral details, making the conciseness slightly excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and has an output schema, which lightens the burden of describing return values. Still, with no annotations, no usage guidance, and no profile semantics, the description is only minimally sufficient for correct invocation and selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented 'profile' parameter. It only restates the parameter name generically and does not explain valid profile values, naming conventions, or how the default 'default' affects resolution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Resolve') and resource ('a profile') with a clear outcome ('effective instructions and skill metadata'). It distinguishes itself from siblings by implying a computation over the profile rather than a search or state operation, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus sibling tools like registry_search or registry_validate. No exclusions, prerequisites, or contextual triggers are provided, so an agent must infer the intended use case from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search instruction, skill, and prompt documents.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention matching semantics, scope of results, read-only nature, or any limitations beyond the generic search action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no fluff or repetition. It is appropriately front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the core purpose is clear. However, with no annotations and no parameter guidance, the definition leaves meaningful gaps around when and how to invoke it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add meaning to the required 'query' parameter. An agent gets no clue about expected query format, search behavior, or result filtering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and identifies a clear resource: instruction, skill, and prompt documents. This distinguishes it from siblings like registry_validate and registry_resolve, which imply different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus related registry tools. The description states only what it does, with no context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate the canonical registry and return actionable errors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that validation returns actionable errors, but does not disclose whether the tool modifies the registry, requires specific permissions, or only performs a read-only check. This leaves important behavior ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes to conveying the tool's purpose and expected output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is minimally viable. However, it leaves the meaning of 'canonical registry' and the potential side effects of validation undefined. Additional context about the registry or validation semantics would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers parameter semantics. The description adds no parameter details, but none are needed. The baseline of 4 applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Validate'), a target resource ('canonical registry'), and an outcome ('return actionable errors'). It is clear enough to distinguish from sibling tools like registry_search or registry_resolve, though it does not explicitly state those distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as registry_search, registry_resolve, or state_get. An agent must infer the intended use case from the name and short description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an allow-listed skill, reloading its implementation after source changes.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | ||
| skill_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety burden. It does disclose two useful behaviors: skills must be allow-listed, and implementations are reloaded after source changes. But it does not disclose side effects, failure modes, or what happens when a skill is not allow-listed, which matters for a code-execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. 'Allow-listed' and 'reloading after source changes' are both meaningful constraints that earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that runs a skill with a free-form payload, the description is too sparse: it lacks how to find allow-listed skills, how to structure payload, and what execution semantics to expect. The presence of an output schema covers return format, but the safety and parameter context remain incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter guidance. It never explains how skill_name is resolved or what payload should contain, and payload is a free-form object, leaving the most important input completely underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Run an allow-listed skill'. The reload-after-source-changes detail adds a distinguishing behavioral note. It doesn't explicitly contrast with siblings like orchestrate or registry_search, so it doesn't earn 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Reloading its implementation after source changes' implies the intended use case of running a skill after edits. However, the description does not explain when to prefer this tool over siblings like orchestrate, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a namespaced value from shared local state.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| namespace | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Read' clearly signals a non-mutating operation, which is useful. However, it does not disclose behavior such as what happens when the key is missing, whether state is per-session, or whether the value is serialized/typed. The description provides some transparency but leaves notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that front-loads the verb and resource. Zero filler; every word contributes to meaning. The brevity is appropriate for a simple two-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two required parameters and an output schema present, the description is mostly complete. The main missing context is failure behavior (missing key/namespace) and any serialization semantics, but given the tool's simplicity and the output schema, the description covers the essential scope adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds only the concept of namespace and key without explaining their semantics, formats, or relationship. The parameter names (namespace, key) are self-explanatory to a degree, and the required constraint is in the schema. The description adds little beyond what the schema property names imply, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a read operation on a namespaced value in shared local state, with a specific verb ('Read') and resource ('namespaced value'). It distinguishes itself from sibling state_put by implying the read/write split, and from orchestrate/skill_run/registry tools by virtue of focusing on local state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for retrieving values from shared local state, but does not explicitly state when to prefer it over other tools or when not to use it. No alternatives or exclusions are named, so the agent must infer context from the sibling list. It is adequate but lacks explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a namespaced value to shared local state and audit the mutation.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes | ||
| namespace | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the mutation is audited, which is valuable. However, it doesn't clarify whether writes are synchronous, whether they overwrite existing keys, whether there are size limits, or what happens on failure—important for a state-writing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence, front-loading the action and resource. Every word earns its place, and it doesn't waste space with restatements of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a write tool with no annotations and a sparse schema, the description leaves critical gaps: overwrite behavior, audit specifics, error handling, and how this relates to state_get for round-trip correctness. The output schema is noted but not described, so agents still can't anticipate the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'namespaced value' generically, providing no added meaning for 'namespace', 'key', or 'value'. The description doesn't explain value types, key constraints, or namespace semantics beyond what the field names already imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Write') and resource ('namespaced value to shared local state'), and mentions auditing the mutation, which distinguishes it from a plain put operation. However, it doesn't explicitly contrast with sibling tools like state_get or orchestrate, making the differentiation less direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it's for writing to shared state, and siblings like state_get clearly handle reading. But it doesn't explicitly state when to use this vs alternatives, nor does it mention prerequisites like namespace existence or whether overwriting is allowed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a different concern: orchestration, state read/write, registry lookup/validation/resolution, and skill execution. Even the two registry tools are clearly separated by search versus resolve/validate semantics.
Most tools follow a domain-prefix_verb pattern (state_get, state_put, registry_search, skill_run, registry_validate, registry_resolve), but orchestrate breaks the pattern by using a bare verb with no prefix. The inconsistency is minor and the names remain readable.
Seven tools is a well-scoped size for a control plane server. Each tool covers a distinct function without redundancy, and the count is neither too thin nor too heavy.
The core surface is fairly complete: state read/write, registry search/validate/resolve, skill execution, and result orchestration are all present. Minor gaps exist, such as no explicit state deletion or registry modification, but agents can work around them with the available tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Governed AI agent skills — one library, distributed to devs and exposed to remote agents over MCP.
Manage portable AI agent playbooks, Agent Skills, MCP configurations, personas, and memory.
Build and run grounded business agents over MCP: agents, knowledge bases, skills, Storylines.
A registry of 5,900+ peer-authored skills any MCP agent can search and load on demand.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Alan-VZ/universal-agent-control-plane'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
