A WebAssembly-based MCP server that dynamically loads and manages tools/components from OCI registries or the filesystem, with capability-based security policies
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Wassette presents a specialized MCP server for component/tool lifecycle management with capability-based security policies. Tool definitions are visible and structured, but there are systematic gaps in parameter descriptions and output schema documentation. All 12 tools have names starting with action verbs (load-, unload-, list-, get-, grant-, revoke-, search-, reset-) and brief descriptions. However, parameter descriptions are minimal or absent for most tools, and return schemas are not documented in the provided source. The schema definitions show basic structure (object type with properties and required arrays) but lack detailed type information and validation constraints. Error handling guidance is absent. Naming is generally clear (verb_noun pattern), but several permission-related tools (grant-storage-permission, revoke-network-permission, etc.) could benefit from clearer parameter documentation regarding expected formats and validation rules.
Tools (12)
get-policyread onlysource verified63/100
Gets the policy information for a specific component
Parameter descriptions are missing or minimal across all tools. The 'path' parameter in load-component, 'id' in unload-component, 'component_id' across permission tools, 'domain' and 'variable' in network/environment tools lack guidance on format, constraints, and examples. LLMs cannot infer parameter meaning from names alone.
Output schemas are not documented in any tool. Return types, field names, and structures are completely undocumented. LLMs cannot plan downstream tool calls or extract required data when return schemas are missing.
Add 50-150 character descriptions to every parameter explaining its purpose, expected format, and constraints. For example: 'path: Filesystem or OCI registry path to the component (e.g., /opt/components/foo or oci://registry.io/components/foo:v1.0.0). Supports absolute paths and registry URIs.'
Document output schemas for all tools. For list-components, specify: '{"components": [{"id": string, "name": string, "status": string, "loaded_at": ISO8601}], "total": integer}'. For get-policy, specify what policy fields are returned.
Add error handling guidance to each tool. Document expected errors (e.g., 'component_not_found', 'permission_denied', 'invalid_path'), classify them as retryable or user-fixable, and suggest recovery steps. Example: 'Error: component_not_found. Try search-components() with a partial name or list-components() to see available options.'
Expand tool descriptions to 100-200 characters. Include WHAT the tool does, WHEN to use it, and any prerequisites. Example for grant-storage-permission: 'Grants read-write filesystem access to a component for a specific path. The component must be loaded first (load-component). If permission already exists, this call is idempotent. Use revoke-storage-permission to remove access.'
Document parameter constraints formally. For load-component's 'path' param: specify regex pattern (e.g., '^(/[\w/-]+\.wasm|oci://[\w./:@-]+)$') or enum (if only certain paths are valid). For grant-network-permission's 'domain' param: clarify if wildcards (*.example.com) are supported.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 2 points across a rubric change (v1 → v2)
66/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
C
66
<=2025-11-25
v2
2026-03-09
C
64
-
v1
writesource verified57/100
Revokes environment variable access permission from a component
No error handling guidance or recovery instructions. Tools do not document what errors can occur (e.g., 'component not found', 'permission already granted', 'invalid path format'), how to classify them (retryable vs. user-fixable), or what the LLM should do next.
Parameter constraints and validation rules are undocumented. For example, 'path' in load-component may accept filesystem paths or OCI registry URIs, but the format and constraints are not specified. 'domain' in grant-network-permission should clarify whether it accepts wildcards, IP ranges, or specific domains, this must be documented.
Permission and security tools lack clear documentation about what permissions they grant/revoke and what scope they apply to. For example, grant-storage-permission grants access to a 'path' but does not clarify whether this is read-only, read-write, recursive, or applies to subdirectories.
Tool descriptions are brief (20-70 characters) and lack actionable context. For example, 'Grants storage/filesystem access permission to a component' does not explain when to use this tool vs. revoke-storage-permission, what happens if permission is already granted, whether the operation is idempotent, or what the downstream effects are.
No documentation about idempotency or side effects. For critical operations like reset-permission (which clears all permissions), LLMs need explicit confirmation that this operation is destructive and irreversible.
list-components and search-components lack pagination guidance. If component registries can contain thousands of entries, these tools should accept limit/offset parameters and return a total count or next_cursor to handle large result sets.
list-componentssearch-components
Add idempotency hints to permission tools. Explicitly state: 'Calling this tool twice with the same parameters produces no additional side effects (idempotent). If permission already exists, this returns success without modification.'
For reset-permission, add a confirmation step or dry-run option. Document that this tool revokes ALL permissions for a component and is irreversible. Consider adding a 'confirm' parameter that defaults to false to prevent accidental execution.
Add pagination support to list-components and search-components. Include parameters: 'limit' (default 20, max 100) and 'offset' (default 0). Return 'total' count and 'next_offset' in response so LLMs can fetch all results iteratively.
Document tool composition and chaining. For example: 'After search-components() finds a component, pass its 'id' to load-component() to load it. Then use grant-*-permission() tools to configure access policies before the component starts processing requests.'
Add examples to tool descriptions (not as literal strings, but as inline guidance). Example for load-component: 'Supports WASM binaries from filesystem (/opt/components/arxiv.wasm) or OCI registries (oci://registry.microsoft.com/mcp/arxiv:latest). Registry URIs are preferred for versioning and distribution.'
Define what 'component_id' uniquely identifies. Is it a UUID, a semantic version, a name, or an opaque token? Document: 'component_id: The unique identifier returned by load-component() (e.g., 'arxiv-rs-1.0.0'). Use list-components() to discover available IDs.'
For security-critical tools (all permission grants/revokes), add audit trail documentation. Specify: 'This operation is logged with the caller identity, timestamp, and the permission granted/revoked. Audit logs are available via [audit-tool-name].'
Clarify the semantics of permissions. For grant-network-permission with domain='example.com', does this allow HTTPS to *.example.com and https://example.com:443? Explicitly state the rules.
For get-policy, document the policy structure returned. Example: 'Returns the current policy for a component in YAML format, including all granted permissions, restrictions, and constraints applied.'
Add prerequisites or dependency hints. For example, grant-storage-permission should note: 'The component must be loaded first (call load-component). Permissions take effect immediately and apply to all future operations by this component.'