MCP Server for accessing Jamf Documentation (learn.jamf.com)
This server demonstrates solid definition quality across 6 well-structured tools. All tools have verb-noun naming (jamf_docs_list_*, jamf_docs_search, jamf_docs_get_*, jamf_docs_batch_*, jamf_docs_glossary_*), explicit descriptions ranging from 90-200 chars, and detailed JSON Schema input definitions with typed parameters. Parameters are well-documented with descriptions, enums where appropriate (e.g., product filters, language locales, output modes), and reasonable constraints (maxTokens 100-50000, pagination limits 1-100). All tools are read-only with clear risk classification. Batch operations and pagination support reduce agent iteration. Output schema structure is implicitly clear from parameter design (markdown/json/compact modes indicate structured output). However, output schemas are not explicitly documented in the source excerpt, parameter relationships (e.g., url vs mapId+contentId alternatives) could be more explicit, and error handling patterns are not visible in the code provided. The server follows good composition patterns (search→get_article→glossary is a clean chain) and accepts natural identifiers (product names, language locales as enums). Missing: explicit error recovery guidance and actionable error messages.
Retrieve full content of multiple Jamf documentation articles in a single call for efficient batch processing
Retrieve the full content of a specific Jamf documentation article by URL or content identifiers
Browse the table of contents for a Jamf product documentation or publication
Look up Jamf terminology and definitions in the Jamf documentation glossary
List all available Jamf products and their documentation versions
Search Jamf documentation by keyword with optional product, topic, and version filters
Output schema documentation is implicit rather than explicit. Tool descriptions do not specify what fields are returned or structure of responses (e.g., jamf_docs_search returns what object shape? Does it include article metadata, URLs, excerpts?). LLMs cannot plan downstream operations without knowing return field names and types.
jamf_docs_get_article parameters 'url' vs 'mapId+contentId' are marked as alternatives but relationship is ambiguous. Description says 'Alternative: use mapId + contentId' but does not state whether these are mutually exclusive or if both can be supplied. Undocumented mutual exclusivity causes silent misuse.
jamf_docs_batch_get_articles has 'articles' parameter documented as 'Array of article identifiers (URLs, mapId+contentId pairs, or search result references)' but does not formally specify the object schema for array items. Is each item {url?: string, mapId?: string, contentId?: string}? Or a string? LLM must guess the structure.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 72 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
No visible error handling patterns in the code excerpt. Tools lack recovery guidance (e.g., 'Product not found. Try jamf_docs_list_products to see available products.'). Irreversible operations are read-only so lower risk, but error categorization (retryable vs user-fixable) is absent.
Parameter descriptions for 'topic' in jamf_docs_search says 'See jamf_docs_list_products for the full list of 21 topic IDs' but does not enumerate them inline or provide examples. LLM cannot discover valid topics without calling another tool first, increasing API overhead.