Check that the server is up and report its version.

Fetch JDK class javadoc or a Spring Boot reference section as markdown.

identifier resolution order:

1. "spring" or "spring:" (e.g. "spring:using") → Spring Boot reference section;

2. dotted names like "java.util.List" → fully-qualified class; the module is resolved from the search index when possible, otherwise java.base is tried first and then a fixed list of fallback modules;

3. plain names like "HttpClient" → exact-name lookup in the search index (class/interface preferred when the name is ambiguous, with a "note" listing alternates).

topic (e.g. "methods", "fields", "constructors", "nested") keeps only that heading section plus title/description; if no such section exists the full content is returned with a "note" listing the available headings. max_tokens truncates the final markdown to roughly that many tokens (estimated as len(text)//4), cut at a line boundary, and sets "truncated": true when applied.

On failure returns {"error", "suggestion"} — try java_search() to find the right name or package.

Search JDK classes and Spring Boot reference sections by name.

Ranks entries of the cached search index (exact > startswith > substring > fuzzy per token; every token must match). Spring sections are included as pseudo-entries, so e.g. 'spring using' finds the "Using" section. Returns {"query", "count", "results": [{name, package, module, kind, url, score}], "index_stale"}.

Look up an artifact on Maven Central (metadata only).

Returns the newest matching version, the top 20 versions and project / javadoc links. When version is given and not found, the error carries a suggestion listing available versions. Metadata is cached for 1 day keyed by the search-API URL; failures are never cached.

Note: max_tokens is reserved for future javadoc content fetching and currently has no effect — only metadata is returned.

Real health check: search index, local cache and upstream endpoints.

The cache check gains read_only: true plus read_only_reason when the database cannot be written (P5). It stays an "ok" check on purpose: a cache that only reads is a degraded optimisation, not a sick server, so overall does not change.

Probes docs.oracle.com, docs.spring.io and search.maven.org with a light GET (10s timeout each). Never raises; returns {"server", "version", "checks": {...}, "overall": "ok"|"degraded"|"error"} where overall is "error" when the search index is unavailable, "degraded" when any check fails, and "ok" otherwise.

Also returns a top-level politeness block with the politeness layer's counters: robots cache rows/fetches/hits, requests blocked by robots.txt, throttle waits and per-host delays, conditional GETs / 304 revalidations, 429 / transport retries, stalls, request budgets and whether the layer is disabled (JAVA_SPRING_MCP_POLITENESS_DISABLED). It sits outside checks on purpose: it is diagnostics and must never change overall.

Find where a Spring Boot topic is documented: section titles and headings.

Matches the documentation's own titles ("Auto-configuration", "Profiles", "Web", "Security") and the h2/h3/h4 headings inside pages, so "data jpa" finds reference/data/sql.html#jpa-and-spring-data even though no page is titled "JPA". Each hit carries title, url, section, version, score, matched_on ("title", "path" or "heading") and a short excerpt.

version (e.g. "4.1") searches that docs line; omitted searches the latest one and the result reports which version that was. limit caps hits (1-25). max_tokens bounds the excerpt text across the hits (estimated as len(text)//4): whole hits past the budget are dropped and "truncated" is set.

The index is a single page — the reference navigation tree (296 entries on the measured 4.1.1 docs) — cached for a week. Headings are harvested only for queries the titles cannot answer, at most 4 pages per call, and are persisted under their own cache key, so a repeat search costs zero requests.

On failure returns {"error", "suggestion"}.

Read a Spring Boot reference section or subsection as clean markdown.

section / subsection are resolved against the documentation's own navigation tree, so "web", "data"+"sql", "using"+"auto-configuration", "how-to"+"actuator" and "installing" all work, and a name that does not exist comes back with the sections that do. Resolution is offline when the index is cached, so no request is wasted guessing a URL and getting a 404.

When subsection is not a page of its own, the section page is returned with only the matching heading section kept (plus title and description) — the same behaviour as java_docs(topic=...) — and a "note" lists the available headings when nothing matches.

version (e.g. "4.1") reads that docs line; omitted reads the latest. max_tokens truncates the markdown to roughly that many tokens (estimated as len(text)//4) at a line boundary and sets "truncated".

On failure returns {"error", "suggestion", "candidates"}.

List the spring.io guides, or read one guide as markdown.

No guide → the catalogue (title, url, type, category, description) from spring.io's own guide data: the HTML index is rendered client-side, so scraping it yields no guides at all, and the sitemap fallback yields URLs without titles. topic filters the catalogue by title, slug, category or description.

guide → that guide as markdown. Guide pages are server-rendered even though the index is not, so "gs/spring-boot", "accessing-data-jpa" or a full https://spring.io/guides/… URL all work. topic then keeps only the matching heading section, as java_docs(topic=...) does. max_tokens truncates (estimated as len(text)//4).

On failure returns {"error", "suggestion"}.

Read Spring Initializr's own metadata: project options or dependency catalogue.

section="options" → the choices start.spring.io offers (Spring Boot versions with the newest released one called out, Java versions, project types, packaging, and the defaults for groupId/artifactId/version). No version is hardcoded anywhere: it is whatever Initializr is serving today.

section="dependencies" → the dependency catalogue (id, name, description, group, reference doc link), filtered by query over those fields. Without query the whole catalogue is returned, truncated to max_tokens.

On failure returns {"error", "suggestion"}.

Turn a need ("jpa", "web", "oauth2 client") into real starter coordinates.

No artifact name is invented. The need is matched against Spring Initializr's own dependency catalogue, then Initializr is asked to generate the Maven pom and the Gradle build file for those ids, and those are returned — parsed coordinates plus ready-to-paste snippets. That matters: the catalogue id "web" generates spring-boot-starter-webmvc on Spring Boot 4.1, not the spring-boot-starter-web that string-building spring-boot-starter-<id> would produce.

build is "both" (default), "maven" or "gradle". boot_version pins the line (plain form, e.g. "4.1.1"); omitted uses Initializr's newest released default. max_tokens truncates the snippets.

On failure returns {"error", "suggestion"} — an unmatched need returns an error rather than a guess.

Release and migration notes for a Spring project, from its GitHub releases.

project is "spring-boot" (default), "spring-framework", "spring-security", "spring-data-jpa", "spring-batch" or "spring-ai". version picks a release ("4.1.1", or "4.1" for its newest patch); omitted picks the newest released version — never a milestone or snapshot, and never a hardcoded number: it is whatever GitHub lists today.

focus is "all", "breaking-changes" (the release's Attention Required / Noteworthy Changes sections), "new-features" (New Features) or "deprecations". Deprecations are found by keyword across every section because no spring-boot release body has a deprecation heading (measured over 100 releases). Migration-guide and release-notes wiki links found in the body are returned under wiki_links.

max_tokens truncates the rendered notes (estimated as len(text)//4). Releases are cached for a day: unauthenticated GitHub allows 60 requests per hour per IP, and one call spends at most one of them.

On failure returns {"error", "suggestion"}.