adityamparikh opened a new pull request, #131:
URL: https://github.com/apache/solr-mcp/pull/131
## Summary
- Adds `add-fields` and `add-field-types` MCP tools to extend a Solr
collection's schema additively through the MCP layer.
- Partially closes #30. Replace/delete operations, `add-copy-field`,
`add-dynamic-field`, and `add-codec-factory` are deliberately deferred (see
spec for rationale).
- Both tools take `List<Map<String, Object>>` matching Solr's Schema API
JSON shape; batched via `SchemaRequest.MultiUpdate`. No transformation layer.
- Both tools are `@PreAuthorize("isAuthenticated()")` — HTTP enforces auth,
stdio bypasses (same pattern as existing tools).
- Renames `metadata/` package to `schema/` since it only ever held
schema-related types.
## Design and plan
- Spec:
[`docs/superpowers/specs/2026-05-17-schema-modification-design.md`](docs/superpowers/specs/2026-05-17-schema-modification-design.md)
- Plan:
[`docs/superpowers/plans/2026-05-17-schema-modification.md`](docs/superpowers/plans/2026-05-17-schema-modification.md)
Why two tools instead of one combined? LLM tool-use ergonomics:
single-purpose tools eliminate cross-wiring risk between field and field-type
definitions. The orphan-field-type cost of separation is harmless.
Why no replace/delete? Schema replace/delete silently breaks indexed data
without an explicit reindex. AI-driven workflows are the wrong place to expose
that footgun without a guardrail design.
Why `Map<String, Object>` instead of records? Solr field-type shape includes
analyzers/tokenizers/filters with class-specific param bags; records collapse
to `Map<String, Object>` at the leaves anyway. Map shape matches SolrJ's
`AddField(Map)` constructor — zero transformation.
## Tool descriptions include inline recipes
`add-field-types` description includes three common recipes inline
(case-insensitive exact match, dense vector for semantic search, autocomplete)
to give the LLM a diagnostic-to-fix bridge — symptom in user prompt → recipe in
description → exact analyzer chain.
## Test plan
- [x] Unit tests (Mockito, `@DisabledInNativeImage`) — validation, happy
path, error propagation, single-analyzer, separate index/query analyzers,
DenseVectorField
- [x] Integration tests (Testcontainers, real Solr) — schema round-trip,
custom analyzer behavior at index + query time, DenseVectorField round-trip,
duplicate-field / unknown-type error propagation
- [x] MCP protocol tests in `McpClientIntegrationTestBase` — end-to-end
`add-fields` → `index-json-documents` → `search` workflow, exercised against
both HTTP and stdio transports
- [x] `./gradlew clean build` — BUILD SUCCESSFUL, all tests pass
- [x] `./gradlew jibDockerBuild` — Jib JVM image built
- [x] `./gradlew bootBuildImage -Pnative` — Paketo native stdio image built
- [x] `./gradlew bootBuildImage -Pnative -Pprofile=http` — Paketo native
HTTP image built
- [x] `./gradlew nativeTest -Pnative` — 168/168 native tests pass (113
Mockito tests appropriately skipped)
The `nativeTest` run also caught a real native-image reflection gap:
`Jackson.convertValue(map, AnalyzerDefinition.class)` needs reflection metadata
for `AnalyzerDefinition` (and `FieldTypeDefinition` defensively). Fixed in
[`fix(native): register AnalyzerDefinition and FieldTypeDefinition for
reflection`](https://github.com/adityamparikh/solr-mcp/commit/dc285e7).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
