This server lets you search ServiceNow's public best-practices library at mynow.servicenow.com without any authentication, exposing two tools:
servicenow_search — Search across Knowledge articles, Best Practices, Developer Portal docs, Now Community posts, and other indexed content using natural-language or keyword queries.
Filter by content type: Narrow results using the contentType parameter (e.g., kb_knowledge, sn_communities_post).
Auto-detect content type from query: Natural-language cues (e.g., "stream connect best practices") are automatically detected and routed to the appropriate filter, with the cue phrase removed from the actual search text.
Paginate results: Use offset and limit (1–50) to navigate large result sets; hasMore indicates additional pages.
Graceful fallback: If a content type filter yields no results despite matches existing, the server falls back to unfiltered results and signals this via contentTypeFilterDegraded/note fields.
Discover content types organically: Responses include table, contentTypeLabel, and a contentTypeFilters list with live counts.
servicenow_list_content_types — Retrieve valid content-type identifiers paired with human-readable labels to use as contentType filter values without guessing.
Results are cached for up to 6 hours; use the refresh flag to force a fresh sweep and bypass the cache.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@best-practices-mcp search for IT incident management best practices"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A CLI for searching and downloading content from mynow.servicenow.com — ServiceNow's public
best-practices library/landing page — across content types (Best Practices, Product
Documentation, Developer Portal docs, Now Community posts, and more).
mynow.servicenow.com is a public site — there's no login, token, or API key needed. It's
not a traditional SSO-protected ServiceNow instance; it's a public-facing Now Experience app
running in "Genius Search" / guest-session mode.
There's also no public, documented REST API for its search — it's reverse-engineered from a
Playwright network capture of the site's own search UI (see scripts/probe.ts and
src/servicenow/search.ts for the confirmed request/response shape). The flow:
GET any page on the site → returns a guest session cookie plus a CSRF token embedded in
the HTML as window.g_ck.
POST /api/now/v1/batch, wrapping a GraphQL call to the site's Genius Search data broker,
using that cookie + token.
Parse result[0].executionResult.output.data.GlideSearch_Query.search for results, facets,
and total hit count.
This was confirmed with a cold, browser-free curl round-trip (no Playwright, no reused session) — genuinely unauthenticated, not just working because of a live browser session.
If search ever stops working, the site's frontend likely changed one of the fixed config
IDs in src/servicenow/search.ts (SEARCH_DEFINITION_SYS_ID, SEARCH_CONTEXT_CONFIG_ID,
SEARCH_EVAM_CONFIG_ID). Re-discover them with a fresh Playwright capture filtered to
xhr/fetch traffic (write to a file, grep it — never dump raw capture output into a
conversation) rather than guessing. Then re-run npm run probe to confirm.
Related MCP server: ServiceNow MCP Server
npm install
npm run build # compile to dist/No environment variables are required — SN_INSTANCE_URL defaults to
https://mynow.servicenow.com and only needs overriding if pointing at a different instance.
node dist/index.js help # or -h / --help — human-readable command list
node dist/index.js commands # same list as structured JSON, for agents (also: help --json)
node dist/index.js search "stream connect best practices" [--content-type <table>] [--limit <n>] [--offset <n>]
node dist/index.js list-content-types [--refresh]
node dist/index.js login # opens a browser, blocks until you complete SSO by hand
node dist/index.js login-status
node dist/index.js download <resultUrl> # a search result's `url` fieldOr install it as a global/linked bin (package.json already declares
mynow-cli pointing at dist/index.js) and drop the node dist/index.js prefix.
For development, npm run dev runs the CLI directly with tsx (no build step), and
npm run probe -- "some query" exercises the live search flow end-to-end.
There's no dedicated bulk-download command — an agent (or a shell loop) drives it by calling
search to enumerate results, then download once per result url:
node dist/index.js search "stream connect" --limit 50 \
| jq -r '.results[].url' \
| while read -r url; do node dist/index.js download "$url"; doneThe API returns a fixed 10 rows per request and pages via an opaque
paginationToken (base64 of an internal offset breadcrumb, e.g. offset:0,10). Use offset
to page through the full corpus and limit to control how many rows you get back:
offset is a row index into the full corpus (offset=10 → second page, offset=20 → third,
etc.). It's implemented by constructing a token that jumps directly to that row — the server
doesn't validate the breadcrumb, so any offset is random-accessible in a single request.
limit (1–50) can exceed the 10-row page size; the server is paged internally
(ceil(limit / 10) requests, following the API's own returned token after the initial jump) to
gather that many rows.
hasMore in the response is true when more results exist beyond offset + limit
(offset + limit < totalResults).
Because the offset jump relies on the reverse-engineered token format, npm run probe exercises
offset paging end-to-end — if the encoding ever changes, re-discover it from a fresh capture (see
below) rather than guessing.
Search itself needs no auth, but the actual file behind a file-backed result (presentations,
workbooks, docs) is gated behind a real ServiceNow ID / Okta SSO login — confirmed live via
Playwright (see scripts/probe-headed-login.ts).
login — opens a real, visible browser window and blocks in the terminal until you
complete the ServiceNow ID / Okta login by hand, then saves the resulting session to
.auth/servicenow-storage-state.json (gitignored — this is a live credential). Check
login-status any time to see whether a session file exists on disk and its age.
download <resultUrl> — pass a search result's url. Two mechanisms depending on
content type, both starting from the same cookie-replayed <table>.do?...&XML record fetch
(confirmed to accept cookie replay outside the browser):
Most content types (e.g. marketing decks, u_dotcom_gsdr): no browser needed at all — the
record's own fields carry the real file location directly (often a separate public CDN, no
ServiceNow auth needed for that hop).
Best Practices Library assets (u_x_snc_accel_asset_file_gsdr — this project's primary
target content type): the record's own x_snc_nl_data_extr_file_content field carries the
full extracted text of the underlying file (confirmed for both .docx and .pptx sources)
— this is preferred, since it's what an agent actually wants and needs no browser at all.
Only when that field is empty does this fall back to the real file's binary bytes, which
live behind a separate API (api.servicenow.com/bpl/v1/attachment/<id>) gated by a real
Okta OAuth Bearer token minted client-side at click time. A short-lived headless browser
(reusing the captured session, no new login) drives the actual download click to mint that
token, then a plain fetch uses it to pull the file bytes — see
scripts/probe-bpl-token-capture.ts for how this was confirmed.
Every download response includes a sourceUrl — the human-facing page for that record (the
Best Practices asset page for BPL content, or the original search result URL otherwise).
That's the link to hand to a person: open it in a browser and complete their own SSO/login —
there's no requirement that it be publicly reachable, it just needs to be the real
destination page rather than a backend export URL. The downloaded file/text itself is for
agentic/bulk use, using the session captured by login.
If the session is missing or has expired, download returns a clear error telling you to run
login again — no path ever launches a browser other than the brief, automated one used to
mint a Best Practices Library token.
contentType filters client-side by matching the result's own table or content-type label
— there's no separate discovery tool for valid values yet. An unfiltered search's results
carry their own table/contentTypeLabel, which is enough to learn valid filters
organically; contentTypeFilters in the response also lists all available content types with
live counts for the current query.
List content-type values for servicenow_search's contentType filter: raw internal table identifiers (e.g. 'u_hi_kb_knowledge_gsdr') paired with their human-readable label. These cannot be guessed from standard ServiceNow table names (e.g. 'kb_knowledge' is wrong) — a wrong guess silently returns zero results instead of erroring. Backed by a cache built from real search traffic plus a warm-up sweep on first use or once the cache is more than 6 hours old; set refresh to force a fresh sweep.
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No | Force a fresh warm-up sweep instead of using the cached content types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses caching mechanics (backed by real search traffic, warm-up sweep, 6-hour expiry, refresh behavior) and the silent failure mode of incorrect guesses. This provides sufficient transparency for an agent to understand side effects and statefulness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences that front-load the purpose, then explain why the tool is necessary (cannot guess), and finish with caching details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one optional boolean parameter and no output schema, the description fully covers the tool's purpose, rationale, caching behavior, and parameter usage. It is complete for an agent to decide when to invoke it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the 'refresh' parameter 100% with a clear description. The tool description adds context about the caching lifecycle and explains when to use refresh, enhancing the semantic understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('content-type values for servicenow_search's contentType filter'), and specifies the content (raw internal table identifiers paired with human-readable labels). It effectively distinguishes from the sibling tool 'servicenow_search' by describing what this tool provides for that search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the identifiers cannot be guessed and that wrong guesses silently return zero results, implying when to use this tool. It also explains caching behavior and when to set the refresh parameter. However, it does not explicitly state 'use this before servicenow_search to get correct identifiers', though this is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ServiceNow's public best-practices library (mynow.servicenow.com) across Knowledge, Best Practices, Developer Portal docs, and other indexed content. No authentication required. Leave contentType unset to search all sources; use the 'table' field on prior results to discover valid contentType filter values. A natural-language content-type cue in the query itself (e.g. 'stream connect best practices') is detected and routed to that contentType filter automatically, with the cue phrase removed from the search text — see the response's searchedQuery/detectedContentType fields for what was actually searched. Set contentType explicitly to override this detection. contentType filtering only applies to a small fixed raw page, not the full corpus — if that filter would return nothing despite real matches existing (totalResults > 0), the response falls back to unfiltered results and sets contentTypeFilterDegraded/note rather than silently returning empty.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Search term(s) | |
| offset | No | ||
| contentType | No | Optional table/source filter (e.g. 'kb_knowledge', 'sn_communities_post'). Leave unset to search all sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses no authentication required, automatic content-type detection, routing of query cues, fallback when filter returns nothing, and response fields (searchedQuery, detectedContentType, contentTypeFilterDegraded/note). Fully transparent beyond annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with front-loaded purpose sentence. Contains useful details but slightly verbose; could be more concise. Still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers authentication, filter behavior, fallbacks, and partial response structure. Lacks full response details but acceptable for search tool. Paging (offset/limit) not elaborated beyond schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (2/4 parameters described). Description adds meaning: how to discover contentType values, automatic detection, and fallback. Compensates for schema gaps and adds unique semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool searches ServiceNow's public best-practices library (mynow.servicenow.com) across multiple content types. Distinguishes from sibling tool by specifying search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to set contentType, how to discover valid values, and fallback behavior. Does not explicitly mention alternatives beyond listing content types, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: one lists content types for filtering, the other performs searches across the knowledge base. No ambiguity between them.
Both tools follow the consistent pattern 'servicenow_verb_noun' (list_content_types and search), making them easily distinguishable and predictable.
With only 2 tools, the server is minimal but appropriate for its narrow focus on searching ServiceNow best practices. The helper tool is essential for effective use of the search tool.
The tool surface covers the core workflows: retrieving valid content types and performing searches with smart fallback. Minor gaps exist (e.g., no tool to fetch a single result in detail), but overall it's well-scoped.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search and fetch AgendaForge public documentation and marketing content. No authentication needed.
Read-only search and page retrieval from the public Atisbo documentation corpus. No authentication.
Search and read the public Applivery docs (MDM & app distribution). Read-only, no auth.
Public fellowship and grant search with sourced details and live filter vocabularies.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wiz0floyd/mynow-cli'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
