Skip to main content
Glama

sn_read_docs

Retrieve ServiceNow official documentation from GitHub markdown. Explore release indexes, search topics by keyword, or fetch specific doc files with automatic version resolution.

Instructions

Access the official ServiceNow AI Platform documentation from https://github.com/ServiceNow/ServiceNowDocs — pure markdown, optimised for LLM use.

IMPORTANT: Never fetch servicenow.com/docs — it is a JS SPA with no readable content.

Three execution modes: get_index — Fetch llms.txt (full release index) so you can study the layout and navigate on your own. Pass 'publication' to drill into one area's TOC. search — Pass a keyword to find relevant topics across all publications and supplement the results with GitHub code search in the ServiceNowDocs repo. Returns file_url and file_path values ready for get_file. get_file — Directly read any doc file when you know the path or URL (after reading an index or following a relative markdown link).

Version resolution (fully dynamic — zero hard-coded branch names): • Pass 'version' with a release name (e.g. 'Xanadu', 'Zurich', 'Australia'). • Default branch is fetched live from GitHub API — always correct, zero maintenance. • Valid branches come from llms_template.txt in the repo — the authoritative list. • Matching is case-insensitive and fuzzy against that live list. • Unknown/mistyped versions fall back to the default branch with a clear notice.

Recommended workflow:

  1. mode='get_index' → understand what's available

  2. mode='get_index', publication='api-reference' → browse a specific area

  3. mode='get_file', file_url='<url from step 2>' → read the doc OR: mode='search', search='GlideRecord' → find topics by keyword

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoExecution mode. Default: 'get_index'. 'get_index' to explore, 'search' to find, 'get_file' when path is already known.
searchNoFor mode='search': keyword to find across all topic headings (e.g. 'GlideRecord', 'REST API', 'flow designer', 'catalog item').
versionNoServiceNow release to target (e.g. 'Australia', 'Zurich', 'Yokohama', 'Xanadu'). Resolved dynamically from the live GitHub repo — no hard-coded values. Omit to use the repo's current default branch. Invalid/unknown versions fall back to the default branch with a notice.
file_urlNoFor mode='get_file': full raw.githubusercontent.com URL. Copy directly from get_index output. Takes priority over file_path.
file_pathNoFor mode='get_file': repo-relative path (e.g. 'markdown/api-reference/scripts/GlideRecord.md').
max_resultsNoFor mode='search': max topic results to return (default 30).
publicationNoFor mode='get_index': publication folder to get TOC for (e.g. 'api-reference', 'it-service-management', 'platform-administration'). Omit to get the top-level llms.txt for the whole release.
Behavior5/5

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

With no annotations provided, the description carries the full transparency burden. It discloses dynamic version resolution, fuzzy matching, fallback behavior for unknown versions, GitHub code search supplementation, and the fact that content is pure markdown. This is thorough and honest about how the tool behaves.

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

Conciseness5/5

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

The description is long but extremely well structured: purpose, critical warning, mode definitions, version resolution, and recommended workflow are clearly separated with headers and bullets. Every sentence adds necessary context, and the most important information is front-loaded.

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

Completeness5/5

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

This is a complex tool with 7 parameters, 3 modes, dynamic version resolution, and no output schema. The description covers all modes, parameter usage, version fallback behavior, and a recommended workflow. It leaves no significant ambiguity for an agent to misuse the tool.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining how modes map to parameters, giving concrete examples like 'search='GlideRecord'', and adding semantics such as 'case-insensitive and fuzzy' version matching. This goes beyond the schema but does not dramatically expand parameter understanding.

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?

The description opens with a specific verb-resource pair ('Access the official ServiceNow AI Platform documentation') and immediately distinguishes the tool from the forbidden servicenow.com/docs SPA. It then defines three distinct execution modes, making the purpose unmistakable.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance: it warns against the JS SPA, gives a numbered recommended workflow, and explains exactly when to use each mode. This goes far beyond a generic 'use for docs' and gives the agent actionable decision logic.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ImJaineel/SN-MCP-Server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server