Agent-design pattern guidance via 5 hosted read-only tools; Streamable HTTP, no auth, one Release.
Scored across 5 tools
Each tool has a distinct role: batch card fetching, relationship traversal, structured navigation, query-based discovery, and single-item reading. Some overlap exists between atlas_cards and atlas_read, but the described cost/use-case differences keep them separable.
All tools share the 'atlas_' prefix and snake_case, but the second part mixes nouns (cards, links) and verbs (read, navigate, orient). The naming is readable but not uniformly verb_noun.
Five tools cover the apparent read/explore scope of the atlas knowledge graph without redundancy or bloat. The count feels appropriate for the domain.
The toolset covers reading individual nodes, batching multiple cards, navigating relationships, traversing curated paths, and discovering entries by query. It seems complete for a read-oriented knowledge graph; write or mutation operations are not implied by the domain descriptions.
Read 1-4 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. Use atlas_read for Section wording or a complete Node.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | 1-4 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. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| scope | Yes | |
| coherence | Yes | |
| projection | Yes | |
| payload_class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context about atomic response and provenance expansion, which are not covered by annotations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that front-load the core purpose, then provide behavioral detail and routing guidance. No fluff or 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?
With an output schema present and annotations covering safety, the description covers the key behavioral aspects (returned card structure, provenance expansion, atomicity) and explicitly routes to an alternative. Nothing critical is missing for correct invocation.
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 100% for all parameters. The description adds meaningful guidance: clarifies the ids constraint (1-4 distinct) and explains the effect of provenance=true, going beyond the schema descriptions. expected_revision is left to schema, which is sufficient given coverage.
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?
States a specific action ('Read 1-4 canonical ids') and describes the output as 'ordered Card per id: identity, Hook, and sealed claims with source addresses'. It differentiates from sibling atlas_read by explicitly naming it and the alternative use case.
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?
Gives explicit guidance: 'Use atlas_read for Section wording or a complete Node' and instructs when to set provenance=true to expand audit facts. This tells the agent exactly when to choose this tool over an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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'. Use atlas_read for the full Node.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| scope | Yes | |
| coherence | Yes | |
| projection | Yes | |
| payload_class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds no additional behavioral detail beyond what the annotations and schema provide, but it does not contradict them.
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 two sentences, front-loads the core purpose, and includes a useful pointer to the sibling tool without unnecessary wording.
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?
The description enumerates the key returned fields and the exception for 'undisclosed' classes, and it references the appropriate alternative tool. It relies on the schema for pagination and revision details, which is acceptable given the rich 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 description coverage is 100% for all four parameters, and the description adds no extra parameter-level detail. The baseline of 3 applies because the schema fully documents the parameters.
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 a specific action ('Page one subject's relationship occurrences') and resource ('relationship occurrences'), and distinguishes itself from atlas_read by directing users there for the full Node.
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?
It explicitly provides an alternative ('Use atlas_read for the full Node'), making the intended use case clear. It does not mention every sibling tool, but the key distinction from atlas_read is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | Yes | 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. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| scope | Yes | |
| coherence | Yes | |
| projection | Yes | |
| payload_class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent, and the description reinforces this with 'read address' and no mutation language. It goes far beyond the annotations by explaining ranking logic, matching rules, paging behavior, and how misses are handled, giving full transparency into execution.
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 purpose is front-loaded in the first sentence, and the structure moves from general behavior to specific parameters. However, the query description is extremely dense and runs into multiple long paragraphs, making it harder to scan quickly; still, nearly every sentence contributes useful detail.
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?
The description covers all six parameters, explains their interactions, and provides sufficient behavioral detail such as ranking, filtering, kind-specific search scopes, and empty-query semantics. Given the tool's complexity and the existing output schema, nothing necessary for correct invocation or interpretation is missing.
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 100%, but the description substantially enriches each parameter. The 'query' parameter receives a thorough explanation of tokenization, weighting, and matching scopes—far more than the schema's 'ordinary design vocabulary'—and 'kind', 'bound', 'cursor', 'status', and 'expected_revision' all gain concrete behavioral meaning.
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 verb 'Discover' and object 'canonical identity' clearly state the tool's function as a search/discovery action. The phrase 'entry point when no canonical id is held' explicitly positions it against tools that require a known ID, distinguishing it from siblings like atlas_read 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'when no canonical id is held,' giving a clear condition for using this tool over alternatives. It also details behavior for 'kind' values and empty queries, but does not name alternative tools directly, so it falls just short of full explicitness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a complete Node (bare id: identity, hierarchy, Hook, and every Section — relationships are recovered through atlas_links), one Section ('node-id#section-slug'), one Decision record ('decision:'), or one exact glossary definition ('term:'). A Card from atlas_cards is usually cheaper than a whole Node.
| 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. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| scope | Yes | |
| coherence | Yes | |
| projection | Yes | |
| payload_class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description reinforces this with 'Read' in the title and explains the response content, adding useful context without contradicting annotations.
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 a single sentence that densely packs all address types and alternatives without being verbose. It is well-structured and front-loads the purpose, though slightly complex due to the number of address formats.
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?
With an output schema present, the description correctly focuses on input and purpose. It thoroughly explains address formats and expected_revision, and the relationship to sibling tools is clear. Minor details like error handling are not specified, but this is acceptable given the output 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?
Both parameters have detailed descriptions in the schema, achieving 100% coverage. The description adds no extra parameter-specific detail, so it remains at the baseline for high schema coverage.
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 tool reads a Node, Section, Decision, or glossary definition, with specific address formats. It also differentiates from siblings by mentioning atlas_links for relationships and atlas_cards as a cheaper alternative.
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?
Explicitly advises that a Card from atlas_cards is usually cheaper than a whole Node, guiding users toward an alternative when appropriate. Also clarifies that relationships are recovered through atlas_links, implying when to use that tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
atlas_cards2 fields changedInput schema / properties / provenanceAdded value: +{
+ "default": false,
+ "description": "Include expanded audit facts for cited sources.",
+ "type": "boolean"
+}Output schema / properties / projection / constPrevious value: -"agent-projection/v5"New value: +"agent-projection/v6"atlas_decisionsatlas_defineatlas_links1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v5"New value: +"agent-projection/v6"atlas_navigate1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v5"New value: +"agent-projection/v6"atlas_orient3 fields changedInput schema / properties / kind / descriptionPrevious 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."Input schema / properties / query / descriptionPrevious 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."Output schema / properties / projection / constPrevious value: -"agent-projection/v5"New value: +"agent-projection/v6"atlas_provenanceatlas_read3 fields changedInput schema / properties / address / descriptionPrevious 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>'."Output schema / properties / payload_class / enumPrevious value: -[
- "section",
- "node",
- "decision"
-]New value: +[
+ "section",
+ "node",
+ "definition",
+ "decision"
+]Output schema / properties / projection / constPrevious value: -"agent-projection/v5"New value: +"agent-projection/v6"atlas_orient1 field changedInput schema / properties / query / descriptionPrevious 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."atlas_read1 field changedInput schema / properties / address / descriptionPrevious 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>'."atlas_cards1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"atlas_decisions1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"atlas_define1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"atlas_links1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"atlas_navigate1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"atlas_orient2 fields changedInput schema / properties / query / descriptionPrevious 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."Output schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"atlas_provenance1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"atlas_read1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"atlas_cards1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"atlas_decisions1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"atlas_define1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"atlas_links1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"atlas_navigate1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"atlas_orient1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"atlas_provenance1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"atlas_read1 field changedOutput schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"atlas_cards1 field 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"
+}atlas_decisions1 field 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"
+}atlas_define1 field 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"
+}atlas_links1 field 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"
+}atlas_navigate1 field 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"
+}atlas_orient1 field 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"
+}atlas_provenance1 field 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"
+}atlas_read1 field 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"
+}atlas_cards2 fields changedInput schema / properties / expected_revision / descriptionPrevious 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."Input schema / properties / ids / descriptionPrevious 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."atlas_decisions2 fields changedInput schema / properties / expected_revision / descriptionPrevious 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."Input schema / properties / query / descriptionPrevious 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."atlas_define2 fields changedInput schema / properties / expected_revision / descriptionPrevious 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."Input schema / properties / term / descriptionPrevious 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."atlas_links4 fields changedInput schema / properties / bound / descriptionPrevious value: -"Maximum occurrences per page, 1-50 (default 12)."New value: +"Occurrences per page, 1-50."Input schema / properties / cursor / descriptionPrevious 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."Input schema / properties / expected_revision / descriptionPrevious 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."Input schema / properties / subject / descriptionPrevious value: -"The one canonical node id whose relationship occurrences are paged."New value: +"The node id whose occurrences are paged."atlas_navigate2 fields changedInput schema / properties / expected_revision / descriptionPrevious 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."Input schema / properties / view / descriptionPrevious 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."atlas_orient6 fields changedInput schema / properties / bound / descriptionPrevious value: -"Maximum candidates per page, 1-8 (default 3)."New value: +"Candidates per page, 1-8."Input schema / properties / cursor / descriptionPrevious 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."Input schema / properties / expected_revision / descriptionPrevious 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."Input schema / properties / kind / descriptionPrevious 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."Input schema / properties / query / descriptionPrevious 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."Input schema / properties / status / descriptionPrevious 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'."atlas_provenance2 fields changedInput schema / properties / addresses / descriptionPrevious 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'."Input schema / properties / expected_revision / descriptionPrevious 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."atlas_read2 fields changedInput schema / properties / address / descriptionPrevious 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>'."Input schema / properties / expected_revision / descriptionPrevious 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."atlas_decisions1 field changedInput schema / properties / query / descriptionPrevious value: -"Case-insensitive substring matched against each Decision's title and full body. Omit to list every admitted Decision."New 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."atlas_orient1 field changedInput schema / properties / query / descriptionPrevious 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; an empty string lists every subject in manifest order."New 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."atlas_provenance1 field changedInput schema / properties / addresses / descriptionPrevious value: -"Compact span addresses in 'node-id#section-slug' form, exactly as cited by a Card claim's 'sources' or a payload's 'derived' entries."New value: +"Compact span addresses in 'node-id#section-slug' form, exactly as cited by a Card claim's 'sources'."atlas_cards2 fields changedInput schema / properties / expected_revision / descriptionAdded 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."Input schema / properties / ids / descriptionAdded value: +"1 to 4 distinct canonical node ids, for example taken from atlas_orient candidates, atlas_links targets, or atlas_navigate tree entries."atlas_decisions2 fields changedInput schema / properties / expected_revision / descriptionAdded 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."Input schema / properties / query / descriptionAdded value: +"Case-insensitive substring matched against each Decision's title and full body. Omit to list every admitted Decision."atlas_define2 fields changedInput schema / properties / expected_revision / descriptionAdded 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."Input schema / properties / term / descriptionAdded value: +"The glossary term to define, matched case-insensitively; a substring is accepted when it names exactly one term."atlas_links4 fields changedInput schema / properties / bound / descriptionAdded value: +"Maximum occurrences per page, 1-50 (default 12)."Input schema / properties / cursor / descriptionAdded 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'."Input schema / properties / expected_revision / descriptionAdded 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."Input schema / properties / subject / descriptionAdded value: +"The one canonical node id whose relationship occurrences are paged."atlas_navigate2 fields changedInput schema / properties / expected_revision / descriptionAdded 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."Input schema / properties / view / descriptionAdded value: +"'tree' for the canonical ordered traversal of every published node; 'tour' for the publisher-curated first learning path."atlas_orient6 fields changedInput schema / properties / bound / descriptionAdded value: +"Maximum candidates per page, 1-8 (default 3)."Input schema / properties / cursor / descriptionAdded 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'."Input schema / properties / expected_revision / descriptionAdded 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."Input schema / properties / kind / descriptionAdded value: +"Restrict candidates to one node kind: 'pattern', 'concept', or 'example'. Roadmap entries carry no kind, so any kind filter excludes them."Input schema / properties / query / descriptionAdded 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; an empty string lists every subject in manifest order."Input schema / properties / status / descriptionAdded value: +"Restrict candidates to one maturity rung of the corpus status ladder; published subjects sit at 'fleshed' or 'stable'."atlas_provenance2 fields changedInput schema / properties / addresses / descriptionAdded value: +"Compact span addresses in 'node-id#section-slug' form, exactly as cited by a Card claim's 'sources' or a payload's 'derived' entries."Input schema / properties / expected_revision / descriptionAdded 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."atlas_read2 fields changedInput schema / properties / address / descriptionAdded 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."Input schema / properties / expected_revision / descriptionAdded 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."atlas_cardsatlas_decisionsatlas_defineatlas_linksatlas_navigateatlas_orientatlas_provenanceatlas_readPublic agentic AI doctrine tools plus authenticated architecture, design, and spec validators.
Agent-readiness scanner (0-5 score), robots.txt + llms.txt generators, managed agent enablement.
Read-only MCP server for turva.dev's published service catalog, pricing and contact details. Five tools return JSON, including dated agent-readiness and security evidence with verification links. Connect over Streamable HTTP without an API key. The server answers questions about turva.dev and does not scan other websites or run audits.
Free agent-service discovery, OpenAPI document checks, and receipt verification. No API key needed.
Add one secure layer between your agents and this server.
