mcp-server-weaviate
MCPBuild the server: ``` make build ```
Dimension scores
Compatibility
| Framework | Status | Notes |
|---|---|---|
| Claude Code | ✓ | Tool descriptions could be more detailed for better Claude understanding, Error handling returns text-only results, Claude may prefer structured error format |
| OpenAI Agents SDK | ~ | Only supports stdio transport, OpenAI SDK prefers SSE (code shows TODO for SSE support), Object type parameter in insert-one may not translate cleanly to OpenAI function calling - needs additional schema constraints, Array of strings in query needs explicit item schema for OpenAI compatibility, Would need transport adapter or SSE implementation to work with OpenAI SDK |
| LangChain | ✓ | Generic object type in properties parameter may need type hints for LangChain schema validation, Response format is plain text/JSON string - LangChain may prefer structured output, State management with WeaviateConnection should be compatible but needs testing with concurrent LangChain agents |
Security findings
Weaviate connection credentials hardcoded in source code
weaviate.go:20-24 - Host, Scheme hardcoded as 'localhost:8080' and 'http'. Comment suggests 'TODO: get config from env' but credentials are exposed in source. No authentication credentials visible but connection details should not be hardcoded.
No input validation on collection names allows arbitrary database access
mcp.go:72-79 parseTargetCollection() accepts any string as collection name without validation. Callers can access any collection in the Weaviate instance, violating least-privilege principle.
GraphQL query construction uses unvalidated user input
weaviate.go:40 - Query string from user input (req.Params.Arguments['query']) is passed directly to WithQuery() without validation or sanitization. While the Weaviate client likely handles escaping, no server-side validation prevents malformed or malicious queries.
Properties object accepts arbitrary unvalidated data for database insertion
mcp.go:64 - properties map[string]interface{} from user is passed directly to InsertOne without validation of keys, values, types, or size. Could enable injection of malicious data or cause resource exhaustion.
No length limits on string inputs
Error messages may expose internal details
Type assertion without proper error handling
Weak type validation for array elements
Reliability
Success rate
72%
Calls made
100
Avg latency
150ms
P95 latency
300ms
Failure modes
- • Type assertion panics on malformed input - no validation before casting req.Params.Arguments values to expected types
- • Empty targetProperties array passes validation but may cause issues in graphql field construction
- • Connection initialization uses 1 second startup timeout which may be too short in real environments
- • No retry logic for Weaviate connection failures or transient network errors
- • batchInsert error handling uses errors.Join but doesn't provide structured error details
- • Query function ignores ctx parameter and uses context.Background() instead, losing cancellation
- • No validation of collection name format or existence before operations
- • Unicode and special characters in query strings not explicitly handled
- • No rate limiting or concurrent request protection
- • Hard-coded localhost:8080 configuration will fail in most deployment scenarios
Code health
License
none
Has tests
No
Has CI
No
Dependencies
15
Early-stage Go project with basic structure but significant maintenance gaps. The code is well-typed (Go) and has a README, but lacks critical elements: no tests, no CI/CD, no license file, incomplete documentation (empty JSON examples in README), and multiple TODO comments indicating unfinished configuration work. The project has 15 dependencies via go.mod but no mechanism to check for vulnerabilities or updates. No git metadata available to assess maintenance activity. The codebase is clean and uses modern Go practices (context, error handling), but needs testing infrastructure and proper documentation before production use.