VisionMCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vision.capabilitiesA | List available, blocked, and experimental capabilities for the active profile. |
| system.doctorC | Core doctor: offline, no optional dependency required. |
| project.createC | Create a portable project (millimetres, right-handed, Z-up). |
| project.statusC | Return project status and directory health. |
| vision.open_projectA | Open an existing project path and remember it for this session. |
| vision.close_projectA | Forget a project path from the session map (does not delete files). |
| vision.list_artifactsC | List content-addressed artifacts recorded in the project. |
| vision.get_artifactC | Resolve a content-addressed artifact by SHA-256 digest. |
| vision.observeB | Capture a local visual target into durable OBSERVED evidence (no browser). |
| vision.queryC | Query an observed perceptual graph with exact artifact citation. |
| vision.explain_regionC | Explain evidence, authority, and uncertainty at an observed pixel. |
| vision.compareC | Compare two captures by digest identity and overview metadata. |
| vision.verifyC | Verify a capture by evidence digest or verify a receipt file. |
| vision.progressC | Return compact perception progress and evidence counts. |
| vision.review_queueC | List items that still require named human or policy review. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Each tool has a clearly distinct purpose: capabilities, system doctor, project management (create/status/open/close), artifact listing/resolution, visual capture (observe, query, explain, compare, verify), progress reporting, and review queue. No two tools overlap in function.
Naming uses a mix of conventions: 'vision.capabilities' (noun), 'system.doctor' (noun), 'project.create' (verb), 'vision.open_project' (verb with underscore). While readable, the pattern is inconsistent across tools.
With 15 tools, the server covers project, artifact, and visual capture workflows comprehensively without unnecessary bloat. The count feels well-scoped for the domain.
The tool surface covers core operations: project lifecycle (create/status/open/close), artifact access, visual capture and verification, and review. Minor gaps like absence of project update/delete or artifact removal exist, but the domain is self-contained.