The map your agent reads before it picks a tool.
Agent tooling for SAP development is multiplying: servers that reach into a system, servers over the documentation, skills that carry a framework's rules. Each of them acts. None of them says which of the others to use, whether it is still maintained, or what it does not do. That is the part the atlas answers, for your agent as much as for you.
Connecting an agent
Any MCP client: the endpoint
The server over streamable HTTP at https://onedevatlas.dev/mcp, stateless and without a session. What a request sends is read to answer it and not stored.
claude mcp add --transport http onedevatlas https://onedevatlas.dev/mcpWhat an agent can ask
| Choosing | |
|---|---|
| match_capability | a described need matched to the closest three capabilities, and the closest use cases |
| recommend_for_task | one capability's options with their readings and when not to use them |
| compare_options | the options compared on what each maintainer states, filtered by it; what does not say is kept apart |
| assess_use_cases | a developer task with its sourced contributions, their conditions, the work that remains and what is not known |
| Looking up | |
| search | across every kind of entry, by name or words, an old name included |
| get | one entry in full: prose, recipe, crawled signals, edges and sources |
| Checking | |
| check_source | a URL in; whether the atlas marked it stale, and what changed after the date it was written |
| Edges of the map | |
| where_core_stops | where the core ends and a package, a plugin or your own code takes over, and how SAP delivers it |
| list_gaps | where nothing credible exists, and the gaps still open, each with the date it opened |
| Shared with SAP Developers | |
| connected_people | the people the atlas and SAP Developers both name, paired by a reviewed identity, with its basis and date |
| connected_resources | the resources both hold, paired, and the ones still unresolved |
Questions it is built for
- I need to cache expensive OData reads in a CAP Node.js service. What are the options, and which are still maintained?
match_capability, recommend_for_task - Which MCP servers for our ABAP system can read source but say they cannot write it?
compare_options - Our security team only allows OAuth. Which ABAP MCP servers state they support it, and what guardrails do they name?
compare_options - An agent should change ABAP in a system we run ourselves. What contributes to that, under which conditions, and what is left to us?
assess_use_cases - I am following a post from March 2024 to add authentication to CAP. What has changed since?
check_source - Does CAP already handle this, or do I need a plugin?
where_core_stops
How an answer reads
- Order is not preference. Options come alphabetically. Nothing is sorted by quality or by downloads, and the atlas never says which to use.
- Readings stay separate. Liveness, compatibility and practice each carry a tier and the evidence behind it, and are never added into a score.
- Unknown is an absence. A reading with no data is grey, not low.
- “Does not say” is not “no”. What a maintainer’s documentation never mentions is listed apart from what it denies.
- A use case answer is derived, never authored. Each option reads shown working, covers, covers under conditions, likely, no, not known or not assessed. An empty result means nothing is recorded, not that nothing exists.
- A ref travels with its name. The ref is the address for the next call; the name is what a person reads.
- An entry that is gone says so.
getanswersunreachablewhile its repository does not answer, andremoved: trueonce a person has removed it. - Every value is dated and sourced, and a facet carries the sentence it rests on. Prose drafted with AI says so in the field
drafted_with_ai.
An agent that configured nothing
Most agents arrive by fetching a URL, and cannot add a server mid-task. They are served without one:
- Every page is complete in its HTML. Readings, coverage and prose are server-rendered, so a fetcher that runs no scripts receives the product.
- A JSON and a Markdown file beside every page. /capabilities/caching.json and /capabilities/caching.md next to /capabilities/caching, each named in the page’s head, and the whole graph at /graph.json. Prebuilt, cached, no rate limit.
- A plain-text map. /llms.txt, and /llms-full.txt for everything in one file.
- Discovery. /.well-known/mcp.json and a
Linkheader name the endpoint, for clients built to read them.
The static files carry the load and cannot go down separately from the site. The endpoint is the richest surface and the only one that can fail on its own, so it is never the only way in.
The skills
The atlas indexes skills for SAP development and writes none. It has two skills about itself, not published yet, and every tool they name is checked against the server in CI.
- onedevatlas tells an agent when the atlas helps (choosing, adding a dependency, reviewing a manifest, trusting a source), the order a choice needs the tools in, and how to read what comes back. It names no tool for SAP development and prefers none.
- onedevatlas-manifest writes the onedevatlas.json of a project the user maintains, from what the project’s own files state, and leaves the commit to them.
Agent tooling in the atlas
The atlas maps agent tooling the way it maps everything else: as capabilities, each with the artifacts that provide it and the readings on each. Today that is 94 MCP servers and 41 skills, across these concerns and the rest of AI & Agents:
| Agent access to your code | 48 | Letting a coding agent read and act on your project or system |
| Agent access to your systems | 39 | Giving an AI agent access to the systems you run over MCP |
| Serve your application over MCP | 15 | Exposing application data and operations to agents over MCP |
| Documentation | 15 | Finding answers in written documentation, and writing what is missing |
| Agent guidance | 50 | Packaged knowledge that teaches a coding agent a framework |
| Tool governance | 9 | Controlling what an agent may call, with an audit trail |
Those tools are the hands and the reference shelf. The atlas is neither: it acts on no system and is not documentation. It is the index over all of them, and over the packages, plugins and posts an agent is about to rely on. How it relates to SAP’s own agent surfaces and to the other catalogues is on the neighbours page.
A maintainer of one of them states its facts in onedevatlas.json, a file in the repository, and the second skill writes it with them.
What it will not do
- Address the model reading a page. The endpoint is announced as a fact about the site, never as an instruction to call it. The credulity that makes checking sources necessary is not a channel the atlas uses.
- Run anybody’s code. A recipe says where it was read and when. Nothing is marked verified.
- Answer from a model. There is no LLM at query time. Every answer is a lookup over prebuilt data.