Skip to main content
Glama

java_docs

Fetch JDK class javadoc or Spring Boot reference sections as markdown for API documentation lookup.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicNo
identifierYes
max_tokensNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full burden and does so richly: module resolution with a fixed fallback list, ambiguous-name handling that returns a 'note' with alternates, topic-section filtering and its full-content fallback, truncation clipped at line boundaries with a 'truncated' flag, and an error shape of {error, suggestion}. This is behavior well beyond what the schema exposes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded one-line purpose followed by an ordered resolution list and two behavior paragraphs; every sentence conveys a rule an agent needs. It is dense rather than padded, though slightly longer than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations exist, yet the description covers the return format (markdown), the 'truncated' and 'note' fields, and the error contract, so an agent knows what to expect. Minor gap: the success payload's overall shape is only loosely implied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: it fully specifies the accepted 'identifier' forms (spring / spring:<section>, dotted FQN, plain name), the 'topic' heading filter with its no-section fallback, and exactly how 'max_tokens' is estimated (len//4) and applied. Every parameter is given meaning the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Fetch') and two concrete resources ('JDK class javadoc' or 'a Spring Boot reference section') with the output format ('as markdown'). An agent can distinguish this document-fetch tool from java_search without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The numbered identifier resolution order tells the agent exactly which input form maps to which source, and the failure clause explicitly routes to java_search(). It does not, however, distinguish this tool from the sibling spring_reference / spring_guides tools, which overlap with the 'spring:<section>' behavior.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.