Building sndev.io: ServiceNow docs for AI agents

If you’ve ever tried to get an AI agent to write ServiceNow code, you know the problem. The agent is confident. It produces clean-looking JavaScript. It references class names and method signatures with total authority. And then you paste it into your ServiceNow instance and it fails because the method doesn’t exist, or the parameter order is wrong, or the thing it’s calling is only available in a scope the agent never knew about.

It’s not the agent’s fault. ServiceNow’s scripting API is enormous — hundreds of classes, thousands of methods, multiple scopes (server, client, both), and a documentation site that requires a login, loads slowly, and doesn’t have a consistent structure. The training data is there, but it’s noisy. The agent is doing its best with incomplete information.

I wanted to fix this.

The documentation problem

ServiceNow publishes detailed API reference PDFs with each release. The Zurich release docs alone cover 240+ scripting classes and 160+ REST API groups. They’re thorough and accurate — the problem is they’re locked in PDF format and distributed across multiple files.

Getting an agent to reliably reference these docs means either:

1. Dumping raw PDF text into a context window (slow, expensive, inconsistent formatting)
2. Pointing the agent at the documentation website (requires auth, slow, no structured access)
3. Building something structured

I went with option 3.

I wrote Python scripts to parse the PDFs and extract every class, method, parameter, return type, description, and scope into structured JSON. The result is a 1.5MB spec.json that covers the full scripting API, plus separate files for the REST API and product-to-API mappings. It’s not perfect — 33 classes had parsing edge cases and are missing their methods — but it covers the overwhelming majority of what agents actually need.

The MCP server

sndev.io is a Model Context Protocol server built on Cloudflare Workers. It exposes three tools:

• search — query scripting classes and methods
• search_rest — query REST API endpoints
• search_products — find which APIs are available for a given ServiceNow product

The tool interface is deliberately flexible. Instead of a rigid query parameter, each tool accepts a JavaScript expression that gets evaluated against the spec data. So you can ask for something narrow:

spec.classes["GlideRecord"]?.methods["query"]

Or run a broader search across the whole spec:

Object.entries(spec.classes)
  .filter(([_, cls]) => cls.scope === "server")
  .flatMap(([cn, cls]) =>
    Object.entries(cls.methods)
      .filter(([mn]) => mn.toLowerCase().includes("attachment"))
      .map(([mn, m]) => ({ class: cn, method: mn, description: m.description }))
  )

This gives agents real flexibility without requiring a special query language. The spec data is just a JavaScript object — agents can traverse it however they need.

Making agents actually useful for ServiceNow

The effect is noticeable. When an agent has access to sndev.io, it stops guessing at method signatures. It can look up what scope a class is available in before generating code. It can find the right REST endpoint for a given operation instead of hallucinating one that doesn’t exist.

The goal isn’t to replace human ServiceNow developers. It’s to make the agent half of the pair more grounded. When an agent can answer “does this method exist and what does it take?” in real time, the whole workflow moves faster and the output is more trustworthy.

ServiceNow is one of the most widely deployed enterprise platforms in the world, and the developer tooling around AI assistance has lagged behind what’s available for more open ecosystems. sndev.io is a small step toward closing that gap.

Check it out at sndev.io.