Agentic Atlas

Server Details

Patterns for designing and reviewing AI skills, agents, and multi-agent workflows. Find guidance on context economy, delegation, verification, and tool design; inspect claims, worked examples, maturity labels, and source references. Five read-only tools let agents discover relevant patterns, compare concise cards, read specific sections, and explore relationships. Hosted Streamable HTTP at https://agentic-atlas.dev/mcp/ — no installation, account, or API key required. Browse the atlas at https://agentic-atlas.dev/.

Ownership verified

Status: Healthy
Uptime: 99.9% over 42 days
Last Tested: 2026-10-04 09:22
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-09-30 18:30 across 5 tools

Disambiguation4/5

Most tools have distinct roles: orient discovers ids, read fetches one entity, links reveals relationships, navigate exposes structure, and cards batch-reads summaries. The boundary between atlas_cards (batch card summaries) and atlas_read (full single node) can be confused, but the descriptions clarify the difference.

Naming Consistency4/5

All tools share the consistent 'atlas_' prefix, which makes the set predictable. However, the suffixes mix nouns (cards, links) with verbs (navigate, orient, read), a minor stylistic deviation from a uniform verb_noun pattern.

Tool Count5/5

Five tools is well-scoped for a read-oriented knowledge atlas, with each tool covering a distinct access mode: discovery, single read, batch read, traversal, and relationships. No tool feels redundant or missing.

Completeness5/5

The read-only domain (a published atlas) is fully covered by discovery, retrieval, structural navigation, relationship traversal, and batch access, and several tools note paging. There are no obvious dead ends for the apparent read-only purpose.

Available Tools

5 tools

atlas_cardsRead Atlas CardsB

Read-onlyIdempotent

Inspect

Read 1-8 canonical ids as one ordered Card per id: identity, Hook, and sealed claims with source addresses. Set provenance=true to expand every cited source's Release-bound audit facts in the same atomic response.

ParametersJSON Schema

Name	Required	Description
`ids`	Yes	1-8 distinct canonical node ids.
`provenance`	No	Include expanded audit facts for cited sources.
`expected_revision`	No	A prior payload's 'coherence'; 'revision_changed' refuses a moved Release.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`scope`	Yes
`coherence`	Yes
`projection`	Yes
`payload_class`	Yes

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond that: the 1-8 id bound, ordered Card output, atomic response semantics, and the fact that provenance=true expands every cited source's audit facts in the same response.

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

Conciseness4/5

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

Two sentences with the core action front-loaded and no filler. The second sentence efficiently covers the provenance flag, though the domain vocabulary is dense and could obscure the core read operation for an unfamiliar agent.

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

Completeness3/5

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

Given annotations covering safety, a 100%-covered input schema, and an output schema, the description is mostly complete for invocation. However, it omits sibling differentiation and when-to-use guidance, which are material for an agent choosing among the five atlas tools.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents ids, provenance, and expected_revision. The description adds marginal context by mapping ids to ordered Cards and clarifying that provenance expansion occurs atomically, but it does not add syntax or format details beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: reading 1-8 canonical ids as one ordered Card per id, with fields (identity, Hook, sealed claims, source addresses). It is clear what the tool does, but it does not distinguish itself from siblings such as atlas_read, atlas_links, or atlas_navigate.

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

Usage Guidelines2/5

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

There is no guidance on when to use atlas_cards versus the sibling tools (atlas_read, atlas_links, atlas_navigate, atlas_orient). The only usage cue is the implicit 1-8 id limit, which is operational rather than comparative.

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

atlas_linksRead Atlas LinksA

Read-onlyIdempotent

Inspect

Page one subject's relationship occurrences, outbound then inbound, each with direction, reference class, source Section, and the far end's Hook, plus its identity unless the class is 'undisclosed'.

ParametersJSON Schema

Name	Required	Description
`bound`	No	Occurrences per page, 1-50.
`cursor`	No	scope.next_cursor from a prior atlas_links page; repeat the same other arguments.
`subject`	Yes	The node id whose occurrences are paged.
`expected_revision`	No	A prior payload's 'coherence'; 'revision_changed' refuses a moved Release.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`scope`	Yes
`coherence`	Yes
`projection`	Yes
`payload_class`	Yes

TDQS

A4/5.0

Behavior4/5

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

The description adds meaningful behavioral details beyond the annotations: it specifies the ordering (outbound then inbound), the inclusion of identity unless the class is 'undisclosed', and that it returns direction, reference class, source Section, and far end's Hook. Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description complements rather than repeats. It does not mention the revision check, but that is covered in the expected_revision parameter description.

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 a single, dense sentence that front-loads the primary action ('Page one subject's relationship occurrences') and then efficiently lists the specific details. There is no redundant phrasing or filler. It is concise yet packed with the key information needed to understand the tool's behavior.

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

Completeness4/5

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

Given that an output schema is present, the description does not need to explain the return format. It covers the essential behavioral aspects: what is returned (direction, reference class, source Section, far end's Hook, identity condition), the ordering, and pagination via 'Page'. The revision handling is documented in the expected_revision parameter, and the annotations cover safety. A minor omission is the lack of mention of the revision check, but that is already in the schema, so the description is sufficiently complete for correct invocation.

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

Parameters3/5

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

The input schema provides 100% coverage with descriptions for all four parameters, so the baseline is 3. The description does not add additional meaning to the parameters themselves; it focuses on the output content rather than parameter usage. For instance, 'subject' is described in the schema as 'The node id whose occurrences are paged,' which aligns with the description's 'one subject'. No extra value is added beyond the schema.

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 states a specific action: 'Page one subject's relationship occurrences', and details the output fields and ordering. It clearly differentiates from siblings by focusing on relationship occurrences, while other tools like atlas_navigate or atlas_read likely handle different concerns. The verb 'Page' and the resource are explicit, 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 Guidelines3/5

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

The description does not explicitly state when to use this tool versus its siblings. It implies that it is for listing relationship occurrences, but there is no direct guidance on when to prefer it over atlas_navigate, atlas_read, etc. The usage context is inferred from the tool's name and description, not explicitly given.

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

atlas_navigateNavigate the AtlasA

Read-onlyIdempotent

Inspect

Read 'tree', the canonical ordered traversal of every published node, or 'tour', the publisher-curated first learning path.

ParametersJSON Schema

Name	Required	Description	Default
`view`	No	'tree' for the canonical traversal, 'tour' for the curated walk.	tree
`expected_revision`	No	A prior payload's 'coherence'; 'revision_changed' refuses a moved Release.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`scope`	Yes
`coherence`	Yes
`projection`	Yes
`payload_class`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful semantic context about scope ('every published node') and curation, but it does not disclose behavior around expected_revision or error/refusal cases, which are only partially visible in the schema.

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 one efficient, front-loaded sentence. Every clause earns its place by defining both views without repetition or filler.

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

Completeness4/5

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

For a read-only, idempotent tool with two optional parameters and an output schema, the description is nearly complete. It explains the two views, while the schema covers parameter details and the annotations cover safety behavior. A little more explicit sibling differentiation would make it fully complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description repeats the tree/tour meaning already present in the schema and adds no additional parameter semantics beyond that, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Read') and clearly names two concrete resources: 'tree' (the canonical ordered traversal of every published node) and 'tour' (the publisher-curated first learning path). It is clear what the tool does, though it does not explicitly distinguish itself from sibling tools like atlas_read.

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

Usage Guidelines3/5

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

The description implies the use cases by defining tree and tour: tree for the full canonical order, tour for a curated path. However, it does not explicitly state when to use this tool over siblings or when to avoid it, leaving some routing to inference.

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

atlas_orientOrient in the AtlasA

Read-onlyIdempotent

Inspect

Discover canonical identity from an ordinary-language query — the entry point when no canonical id is held. Ranked: identity fields and sealed claims decide candidacy, Section text only when no identity field matches; ordered by identity score, then Section score, then how many words matched, then manifest position. Node candidates carry id, status, Hook, and disclosure class; Decision and term candidates carry exactly a read address and Hook. A term's Hook is its full sealed definition. Results are paged. A miss is a successful empty payload.

ParametersJSON Schema

Name	Required	Description
`kind`	No	Restrict to 'pattern', 'concept', 'example', or 'decision', or 'term'; any kind excludes Roadmap entries. Decision and term candidates carry directly readable addresses.
`bound`	No	Candidates per page, 1-8.
`query`	No	Ordinary design vocabulary. Stopwords are dropped and each remaining word matches whole tokens (a word of four or more characters also matches longer tokens it begins) in canonical ids, titles, Hooks, sealed Card claims, and published Section headings and bodies, each word weighed by how few subjects carry it in an identity field. A Section match orders a candidate but makes one only when no subject matches in an identity field, so total counts the candidates, not every subject a word touches. With kind='decision', the searchable identity is the raw canonical id, title, and complete sealed Decision body. With kind='term', the canonical glossary key and sealed definition are searched. Empty lists every subject of the selected kind.
`cursor`	No	scope.next_cursor from a prior atlas_orient page; repeat the same other arguments.
`status`	No	One status-ladder rung; published subjects are 'fleshed' or 'stable'.
`expected_revision`	No	A prior payload's 'coherence'; 'revision_changed' refuses a moved Release.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`scope`	Yes
`coherence`	Yes
`projection`	Yes
`payload_class`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds real behavioral context: results are paged, and 'a miss is a successful empty payload' tells the agent not to treat zero results as an error. The ranking cascade (identity score, Section score, word matches, manifest position) is also non-obvious behavior worth disclosing.

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

Conciseness3/5

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

Purpose is front-loaded and the length is defensible for a six-parameter ranked search, but the prose is dense and jargon-laden ('Hook', 'sealed claims', 'disclosure class', 'manifest position') without definition. The candidate-shape sentences also restate what the schema's kind description already says about decision/term addresses.

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

Completeness4/5

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

An output schema exists so return values need no explaining, and the safety profile is covered by annotations. The description still supplies ranking logic, paging, and empty-result semantics, leaving only the undefined Atlas vocabulary as a residual gap.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already carries parameter meaning and the baseline is 3. The description adds ranking context but no per-parameter syntax or format detail beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Discover canonical identity from an ordinary-language query' — and gives scope via 'the entry point when no canonical id is held', which implicitly separates it from id-based siblings like atlas_navigate and atlas_read. It never names those siblings, so differentiation must be inferred.

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

Usage Guidelines4/5

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

Provides a clear selection condition: use this when no canonical id is held, implying the navigate/read siblings are for when one is. No explicit exclusions or named alternatives, so it stops short of the top band.

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

atlas_readRead an Atlas Node or SectionA

Read-onlyIdempotent

Inspect

Read a complete Node (bare id: identity, hierarchy, Hook, and every Section; relationship occurrences are omitted), one Section ('node-id#section-slug'), one Decision record ('decision:'), or one exact glossary definition ('term:').

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	A bare node id; 'node-id#section-slug', the slug read off a Node's sections, a Card claim's sources, or a Link's occurrence (slugs are not guessable); or 'decision:<decision-id>'; or 'term:<key>'.
`expected_revision`	No	A prior payload's 'coherence'; 'revision_changed' refuses a moved Release.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`scope`	Yes
`coherence`	Yes
`projection`	Yes
`payload_class`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat those. It adds valuable behavioral context by defining what a 'complete Node' includes and explicitly stating that relationship occurrences are omitted. The 'slugs are not guessable' warning also helps call construction. No contradiction with annotations.

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?

A single well-structured sentence front-loads the action and resource scope, then uses semicolon-separated address patterns for clarity. Every clause earns its place, and there is no filler or restatement of the title.

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?

Given a 2-parameter schema with 100% coverage, an output schema, and safety annotations, the description fully covers the operational contract: what can be read, what each address form means, and what is omitted. Nothing critical an agent needs to invoke it correctly is missing.

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 description coverage is 100%, so the address parameter is already well documented. The description adds meaning beyond the schema by clarifying that a bare id returns a complete Node with identity/hierarchy/Hook/Sections and by framing each address form as a distinct read target. This exceeds the baseline 3 without duplicating the schema.

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?

States a specific verb 'Read' and enumerates the exact resource types: complete Node (identity, hierarchy, Hook, Sections, excluding relationship occurrences), Section, Decision record, and glossary definition. This level of specificity clearly differentiates it from sibling tools without requiring schema inspection.

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

Usage Guidelines4/5

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

Provides clear context for when to use this tool: whenever a Node, Section, Decision record, or glossary definition is needed. It also notes that relationship occurrences are omitted, which implicitly tells the agent to look elsewhere, likely atlas_links, if relationship data is required. It does not name alternatives explicitly, so it stops short of a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesSep 30, 2026
- Changedatlas_cards1 field changed
  - changedInput schema / properties / ids / description
```
Previous value: -"1-4 distinct canonical node ids."New value: +"1-8 distinct canonical node ids."
```
- Changedatlas_orient4 fields changed
  - addedInput schema / properties / query / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - addedInput schema / properties / query / default
```
Added value: +null
```
  - removedInput schema / properties / query / type
```
Removed value: -"string"
```
  - removedInput schema / required
```
Removed value: -[
-  "query"
-]
```

8 tool updatesSep 7, 2026

Changedatlas_cards2 fields changed

addedInput schema / properties / provenance

Added value: +{
+  "default": false,
+  "description": "Include expanded audit facts for cited sources.",
+  "type": "boolean"
+}

changedOutput schema / properties / projection / const

Previous value: -"agent-projection/v5"New value: +"agent-projection/v6"

Removedatlas_decisions
Removedatlas_define
Changedatlas_links1 field changed
- changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v5"New value: +"agent-projection/v6"
```
Changedatlas_navigate1 field changed
- changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v5"New value: +"agent-projection/v6"
```

Changedatlas_orient3 fields changed

changedInput schema / properties / kind / description

Previous value: -"Restrict to 'pattern', 'concept', or 'example'; excludes Roadmap entries."New value: +"Restrict to 'pattern', 'concept', 'example', or 'decision', or 'term'; any kind excludes Roadmap entries. Decision and term candidates carry directly readable addresses."

changedInput schema / properties / query / description

Previous value: -"Ordinary design vocabulary. Stopwords are dropped and each remaining word matches whole tokens (a word of four or more characters also matches longer tokens it begins) in canonical ids, titles, Hooks, sealed Card claims, and published Section headings and bodies, each word weighed by how few subjects carry it in an identity field. A Section match orders a candidate but makes one only when no subject matches in an identity field, so total counts the candidates, not every subject a word touches. Empty lists every subject."New value: +"Ordinary design vocabulary. Stopwords are dropped and each remaining word matches whole tokens (a word of four or more characters also matches longer tokens it begins) in canonical ids, titles, Hooks, sealed Card claims, and published Section headings and bodies, each word weighed by how few subjects carry it in an identity field. A Section match orders a candidate but makes one only when no subject matches in an identity field, so total counts the candidates, not every subject a word touches. With kind='decision', the searchable identity is the raw canonical id, title, and complete sealed Decision body. With kind='term', the canonical glossary key and sealed definition are searched. Empty lists every subject of the selected kind."

changedOutput schema / properties / projection / const

Previous value: -"agent-projection/v5"New value: +"agent-projection/v6"

Removedatlas_provenance

Changedatlas_read3 fields changed

changedInput schema / properties / address / description

Previous value: -"A bare node id; 'node-id#section-slug', the slug read off a Node's sections, a Card claim's sources, or a Link's occurrence (slugs are not guessable); or 'decision:<decision-id>'."New value: +"A bare node id; 'node-id#section-slug', the slug read off a Node's sections, a Card claim's sources, or a Link's occurrence (slugs are not guessable); or 'decision:<decision-id>'; or 'term:<key>'."

changedOutput schema / properties / payload_class / enum

Previous value: -[
-  "section",
-  "node",
-  "decision"
-]New value: +[
+  "section",
+  "node",
+  "definition",
+  "decision"
+]

changedOutput schema / properties / projection / const

Previous value: -"agent-projection/v5"New value: +"agent-projection/v6"

1 tool updateSep 5, 2026

Changedatlas_orient1 field changed

changedInput schema / properties / query / description

Previous value: -"Ordinary design vocabulary. Stopwords are dropped and each remaining word matches whole tokens (a word of four or more characters also matches longer tokens it begins) in canonical ids, titles, Hooks, sealed Card claims, and published Section headings and bodies; Section text is searched only when no subject matches in an identity field, and total counts subjects with at least one matching term. Empty lists every subject."New value: +"Ordinary design vocabulary. Stopwords are dropped and each remaining word matches whole tokens (a word of four or more characters also matches longer tokens it begins) in canonical ids, titles, Hooks, sealed Card claims, and published Section headings and bodies, each word weighed by how few subjects carry it in an identity field. A Section match orders a candidate but makes one only when no subject matches in an identity field, so total counts the candidates, not every subject a word touches. Empty lists every subject."

1 tool updateSep 5, 2026

Changedatlas_read1 field changed

changedInput schema / properties / address / description

Previous value: -"A bare node id, 'node-id#section-slug', or 'decision:<decision-id>'."New value: +"A bare node id; 'node-id#section-slug', the slug read off a Node's sections, a Card claim's sources, or a Link's occurrence (slugs are not guessable); or 'decision:<decision-id>'."

8 tool updatesSep 2, 2026

Changedatlas_cards1 field changed
- changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v4"New value: +"agent-projection/v5"
```
Changedatlas_decisions1 field changed
- changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v4"New value: +"agent-projection/v5"
```
Changedatlas_define1 field changed
- changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v4"New value: +"agent-projection/v5"
```
Changedatlas_links1 field changed
- changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v4"New value: +"agent-projection/v5"
```
Changedatlas_navigate1 field changed
- changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v4"New value: +"agent-projection/v5"
```

Changedatlas_orient2 fields changed

changedInput schema / properties / query / description

Previous value: -"Ordinary design vocabulary, matched case-insensitively against canonical ids, titles, Hooks, and published Section headings and bodies; empty lists every subject."New value: +"Ordinary design vocabulary. Stopwords are dropped and each remaining word matches whole tokens (a word of four or more characters also matches longer tokens it begins) in canonical ids, titles, Hooks, sealed Card claims, and published Section headings and bodies; Section text is searched only when no subject matches in an identity field, and total counts subjects with at least one matching term. Empty lists every subject."

changedOutput schema / properties / projection / const

Previous value: -"agent-projection/v4"New value: +"agent-projection/v5"

Changedatlas_provenance1 field changed
- changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v4"New value: +"agent-projection/v5"
```
Changedatlas_read1 field changed
- changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v4"New value: +"agent-projection/v5"
```

8 tool updatesAug 26, 2026
- Changedatlas_cards1 field changed
  - changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v3"New value: +"agent-projection/v4"
```
- Changedatlas_decisions1 field changed
  - changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v3"New value: +"agent-projection/v4"
```
- Changedatlas_define1 field changed
  - changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v3"New value: +"agent-projection/v4"
```
- Changedatlas_links1 field changed
  - changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v3"New value: +"agent-projection/v4"
```
- Changedatlas_navigate1 field changed
  - changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v3"New value: +"agent-projection/v4"
```
- Changedatlas_orient1 field changed
  - changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v3"New value: +"agent-projection/v4"
```
- Changedatlas_provenance1 field changed
  - changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v3"New value: +"agent-projection/v4"
```
- Changedatlas_read1 field changed
  - changedOutput schema / properties / projection / const
```
Previous value: -"agent-projection/v3"New value: +"agent-projection/v4"
```

8 tool updatesAug 26, 2026

Changedatlas_cards1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "coherence": {
+      "type": "string"
+    },
+    "data": {
+      "type": "object"
+    },
+    "payload_class": {
+      "enum": [
+        "cards"
+      ],
+      "type": "string"
+    },
+    "projection": {
+      "const": "agent-projection/v3"
+    },
+    "scope": {
+      "type": "object"
+    }
+  },
+  "required": [
+    "projection",
+    "coherence",
+    "payload_class",
+    "scope",
+    "data"
+  ],
+  "type": "object"
+}

Changedatlas_decisions1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "coherence": {
+      "type": "string"
+    },
+    "data": {
+      "type": "object"
+    },
+    "payload_class": {
+      "enum": [
+        "decisions"
+      ],
+      "type": "string"
+    },
+    "projection": {
+      "const": "agent-projection/v3"
+    },
+    "scope": {
+      "type": "object"
+    }
+  },
+  "required": [
+    "projection",
+    "coherence",
+    "payload_class",
+    "scope",
+    "data"
+  ],
+  "type": "object"
+}

Changedatlas_define1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "coherence": {
+      "type": "string"
+    },
+    "data": {
+      "type": "object"
+    },
+    "payload_class": {
+      "enum": [
+        "definition"
+      ],
+      "type": "string"
+    },
+    "projection": {
+      "const": "agent-projection/v3"
+    },
+    "scope": {
+      "type": "object"
+    }
+  },
+  "required": [
+    "projection",
+    "coherence",
+    "payload_class",
+    "scope",
+    "data"
+  ],
+  "type": "object"
+}

Changedatlas_links1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "coherence": {
+      "type": "string"
+    },
+    "data": {
+      "type": "object"
+    },
+    "payload_class": {
+      "enum": [
+        "links"
+      ],
+      "type": "string"
+    },
+    "projection": {
+      "const": "agent-projection/v3"
+    },
+    "scope": {
+      "type": "object"
+    }
+  },
+  "required": [
+    "projection",
+    "coherence",
+    "payload_class",
+    "scope",
+    "data"
+  ],
+  "type": "object"
+}

Changedatlas_navigate1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "coherence": {
+      "type": "string"
+    },
+    "data": {
+      "type": "object"
+    },
+    "payload_class": {
+      "enum": [
+        "tree",
+        "tour"
+      ],
+      "type": "string"
+    },
+    "projection": {
+      "const": "agent-projection/v3"
+    },
+    "scope": {
+      "type": "object"
+    }
+  },
+  "required": [
+    "projection",
+    "coherence",
+    "payload_class",
+    "scope",
+    "data"
+  ],
+  "type": "object"
+}

Changedatlas_orient1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "coherence": {
+      "type": "string"
+    },
+    "data": {
+      "type": "object"
+    },
+    "payload_class": {
+      "enum": [
+        "orient"
+      ],
+      "type": "string"
+    },
+    "projection": {
+      "const": "agent-projection/v3"
+    },
+    "scope": {
+      "type": "object"
+    }
+  },
+  "required": [
+    "projection",
+    "coherence",
+    "payload_class",
+    "scope",
+    "data"
+  ],
+  "type": "object"
+}

Changedatlas_provenance1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "coherence": {
+      "type": "string"
+    },
+    "data": {
+      "type": "object"
+    },
+    "payload_class": {
+      "enum": [
+        "provenance"
+      ],
+      "type": "string"
+    },
+    "projection": {
+      "const": "agent-projection/v3"
+    },
+    "scope": {
+      "type": "object"
+    }
+  },
+  "required": [
+    "projection",
+    "coherence",
+    "payload_class",
+    "scope",
+    "data"
+  ],
+  "type": "object"
+}

Changedatlas_read1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "coherence": {
+      "type": "string"
+    },
+    "data": {
+      "type": "object"
+    },
+    "payload_class": {
+      "enum": [
+        "section",
+        "node",
+        "decision"
+      ],
+      "type": "string"
+    },
+    "projection": {
+      "const": "agent-projection/v3"
+    },
+    "scope": {
+      "type": "object"
+    }
+  },
+  "required": [
+    "projection",
+    "coherence",
+    "payload_class",
+    "scope",
+    "data"
+  ],
+  "type": "object"
+}

8 tool updatesAug 25, 2026

Changedatlas_cards2 fields changed

changedInput schema / properties / expected_revision / description

Previous value: -"Optional coherence marker: the Release version (for example 'v1.0.2') read off any previous payload's 'coherence' field. Omit on a first call. When carried, a promotion that has moved the active Release off this marker is refused with the 'revision_changed' error rather than silently answered from a different Release."New value: +"A prior payload's 'coherence'; 'revision_changed' refuses a moved Release."

changedInput schema / properties / ids / description

Previous value: -"1 to 4 distinct canonical node ids, for example taken from atlas_orient candidates, atlas_links targets, or atlas_navigate tree entries."New value: +"1-4 distinct canonical node ids."

Changedatlas_decisions2 fields changed

changedInput schema / properties / expected_revision / description

Previous value: -"Optional coherence marker: the Release version (for example 'v1.0.2') read off any previous payload's 'coherence' field. Omit on a first call. When carried, a promotion that has moved the active Release off this marker is refused with the 'revision_changed' error rather than silently answered from a different Release."New value: +"A prior payload's 'coherence'; 'revision_changed' refuses a moved Release."

changedInput schema / properties / query / description

Previous value: -"Case-insensitive substring matched against each Decision's canonical id, title, and full body. An exact id returns that one summary; omit to list every admitted Decision."New value: +"Substring matched against canonical id, title, and body; omit to list every Decision."

Changedatlas_define2 fields changed

changedInput schema / properties / expected_revision / description

Previous value: -"Optional coherence marker: the Release version (for example 'v1.0.2') read off any previous payload's 'coherence' field. Omit on a first call. When carried, a promotion that has moved the active Release off this marker is refused with the 'revision_changed' error rather than silently answered from a different Release."New value: +"A prior payload's 'coherence'; 'revision_changed' refuses a moved Release."

changedInput schema / properties / term / description

Previous value: -"The glossary term to define, matched case-insensitively; a substring is accepted when it names exactly one term."New value: +"The term to define; a substring naming exactly one term is accepted."

Changedatlas_links4 fields changed

changedInput schema / properties / bound / description

Previous value: -"Maximum occurrences per page, 1-50 (default 12)."New value: +"Occurrences per page, 1-50."

changedInput schema / properties / cursor / description

Previous value: -"Opaque continuation token from a previous atlas_links payload's 'scope.next_cursor'. Repeat the same arguments alongside it; a cursor minted for a different request or a different Release is refused with 'invalid_argument'."New value: +"scope.next_cursor from a prior atlas_links page; repeat the same other arguments."

changedInput schema / properties / expected_revision / description

Previous value: -"Optional coherence marker: the Release version (for example 'v1.0.2') read off any previous payload's 'coherence' field. Omit on a first call. When carried, a promotion that has moved the active Release off this marker is refused with the 'revision_changed' error rather than silently answered from a different Release."New value: +"A prior payload's 'coherence'; 'revision_changed' refuses a moved Release."

changedInput schema / properties / subject / description

Previous value: -"The one canonical node id whose relationship occurrences are paged."New value: +"The node id whose occurrences are paged."

Changedatlas_navigate2 fields changed

changedInput schema / properties / expected_revision / description

Previous value: -"Optional coherence marker: the Release version (for example 'v1.0.2') read off any previous payload's 'coherence' field. Omit on a first call. When carried, a promotion that has moved the active Release off this marker is refused with the 'revision_changed' error rather than silently answered from a different Release."New value: +"A prior payload's 'coherence'; 'revision_changed' refuses a moved Release."

changedInput schema / properties / view / description

Previous value: -"'tree' for the canonical ordered traversal of every published node; 'tour' for the publisher-curated first learning path."New value: +"'tree' for the canonical traversal, 'tour' for the curated walk."

Changedatlas_orient6 fields changed

changedInput schema / properties / bound / description

Previous value: -"Maximum candidates per page, 1-8 (default 3)."New value: +"Candidates per page, 1-8."

changedInput schema / properties / cursor / description

Previous value: -"Opaque continuation token from a previous atlas_orient payload's 'scope.next_cursor'. Repeat the same arguments alongside it; a cursor minted for a different request or a different Release is refused with 'invalid_argument'."New value: +"scope.next_cursor from a prior atlas_orient page; repeat the same other arguments."

changedInput schema / properties / expected_revision / description

Previous value: -"Optional coherence marker: the Release version (for example 'v1.0.2') read off any previous payload's 'coherence' field. Omit on a first call. When carried, a promotion that has moved the active Release off this marker is refused with the 'revision_changed' error rather than silently answered from a different Release."New value: +"A prior payload's 'coherence'; 'revision_changed' refuses a moved Release."

changedInput schema / properties / kind / description

Previous value: -"Restrict candidates to one node kind: 'pattern', 'concept', or 'example'. Roadmap entries carry no kind, so any kind filter excludes them."New value: +"Restrict to 'pattern', 'concept', or 'example'; excludes Roadmap entries."

changedInput schema / properties / query / description

Previous value: -"Ordinary design vocabulary naming the problem or subject (for example 'context window budget'). Terms are split on non-alphanumeric characters and matched case-insensitively against canonical ids, titles, Hooks, and published Section headings and bodies. Section text is searched only when those identity fields produce no candidates, and a body-only match requires every query term. An empty string lists every subject in manifest order."New value: +"Ordinary design vocabulary, matched case-insensitively against canonical ids, titles, Hooks, and published Section headings and bodies; empty lists every subject."

changedInput schema / properties / status / description

Previous value: -"Restrict candidates to one maturity rung of the corpus status ladder; published subjects sit at 'fleshed' or 'stable'."New value: +"One status-ladder rung; published subjects are 'fleshed' or 'stable'."

Changedatlas_provenance2 fields changed

changedInput schema / properties / addresses / description

Previous value: -"Compact span addresses in 'node-id#section-slug' form, exactly as cited by a Card claim's 'sources'."New value: +"Span addresses ('node-id#section-slug') exactly as cited by Card claim 'sources'."

changedInput schema / properties / expected_revision / description

Previous value: -"Optional coherence marker: the Release version (for example 'v1.0.2') read off any previous payload's 'coherence' field. Omit on a first call. When carried, a promotion that has moved the active Release off this marker is refused with the 'revision_changed' error rather than silently answered from a different Release."New value: +"A prior payload's 'coherence'; 'revision_changed' refuses a moved Release."

Changedatlas_read2 fields changed

changedInput schema / properties / address / description

Previous value: -"One canonical address: a bare node id for the complete Node, 'node-id#section-slug' for one Section, or 'decision:<decision-id>' for one Decision record."New value: +"A bare node id, 'node-id#section-slug', or 'decision:<decision-id>'."

changedInput schema / properties / expected_revision / description

Previous value: -"Optional coherence marker: the Release version (for example 'v1.0.2') read off any previous payload's 'coherence' field. Omit on a first call. When carried, a promotion that has moved the active Release off this marker is refused with the 'revision_changed' error rather than silently answered from a different Release."New value: +"A prior payload's 'coherence'; 'revision_changed' refuses a moved Release."

Publisher details

Operator: Agentic Atlas · Publisher source
Operator website: https://agentic-atlas.dev/ · Publisher source
Vendor relationship: First-party · Publisher source
Documentation: https://github.com/aj604/agentic-atlas#consulting-the-atlas-as-an-agent · Publisher source
Trust center: Not available
Restrictions: No account, API key, paid plan, or local installation is required to connect to the hosted read-only endpoint. Reading and agent consumption, including commercial use, are permitted; republishing the corpus is not. See the repository license for terms. · Publisher source

Related MCP Connectors

WauldoOAuth
com.wauldo
Stateless agentic tools over MCP: concept extraction, long-context, knowledge graph, planning.
Knowledge & Memory Autonomous Agents
2
ToolAPI C
org.toolapi
Free public MCP for AI agents — 193 tools, 44 workflows. No API key.
Agent Orchestration Autonomous Agents
19322
Agentic.ai Directory A
io.github.u00dxk2
Independent directory of agentic AI tools — search, compare & recommend via MCP. Read-only.
Search AI & Machine Learning Agent Orchestration
102
protectwith-kb A
io.github.burademirung
AI-security knowledge as MCP: standards-mapped tools (OWASP, NIST, MITRE) for AI agents.
Security AI & Machine Learning
2

Related MCP Servers

Cortex MCP
BasharAmso
A
license
A
quality
D
maintenance
Delivers on-demand knowledge from a built-in library of 728 agents, skills, patterns, and examples across 26 domains to any MCP-compatible AI tool.
Updated a month ago (2026-08-20 11:39 UTC)
6
19 npm
1
MIT
task-orchestrator
Agent Orchestration Project Management Autonomous Agents
jpicklyk
A
license
Not graded
quality
A
maintenance
Server-enforced workflow discipline for AI agents. An MCP server providing persistent work items, dependency graphs, quality gates, and actor attribution. Schemas define what agents must produce — the server blocks the call if they don't. Works with any MCP-compatible client.
Updated 19 hours ago (2026-10-03 15:00 UTC)
207
MIT
base120-mcp
Developer Tools AI & Machine Learning
hummbl-io
A
license
Not graded
quality
B
maintenance
Serves 120 validated mental models as an MCP toolset, letting LLM clients search models by domain and generate structured reasoning scaffolds for engineering challenges. It upgrades reasoning, prompt engineering, and architectural decisions in Claude Desktop, Cursor, and Windsurf.
Updated a month ago (2026-09-04 01:27 UTC)
Apache 2.0
aai-gateway
Agent Orchestration Developer Tools
gybob
A
license
A
quality
D
maintenance
Unified MCP and skill management gateway for AI agents, enabling tool discovery, installation, and sharing with 99% context token savings.
Updated 2 months ago (2026-08-01 14:16 UTC)
8
102 npm
99
Apache 2.0

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?