A
licenseNot graded
qualityC
maintenanceMonetizable AI agent tools - document parsing, text analysis, code generation, security scanning, format conversion, and more. 8 tools with HTTP API and MCP protocol support.
MIT
atlas
Server Details
Agent-design pattern guidance via 8 hosted read-only tools; Streamable HTTP, no auth, one Release.
Ownership verified
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
8 toolsatlas_cardsRead Atlas CardsARead-onlyIdempotentInspect
Read 1-4 canonical ids as one ordered Card per id: identity, Hook, and sealed claims with source addresses. Atomic batch. Use atlas_read for Section wording or a complete Node.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | 1-4 distinct canonical node ids. | |
| 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral details beyond annotations: the batch is atomic, results are ordered, and cards contain identity, Hook, and sealed claims with source addresses. This gives the agent useful expectations about execution and return content.
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?
Two dense sentences with no filler. The core behavior is front-loaded, and the alternative-tool routing is compressed into the final clause. Every word earns its place.
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 the rich annotations, 100% schema coverage, and existing output schema, the description covers everything an agent needs to select and invoke the tool correctly. It specifies scope, cardinality, ordering, atomicity, and the key alternative, leaving no critical 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 documents both parameters. The description reinforces the 1-4 id constraint and adds that the batch is atomic and ordered, which helps interpret the ids parameter, but it does not significantly extend the parameter-level meaning 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 precise verb ('Read') and resource ('1-4 canonical ids as one ordered Card per id'), and enumerates the card contents: identity, Hook, and sealed claims with source addresses. It also explicitly distinguishes itself from atlas_read, so an agent can tell them apart immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use atlas_read instead: 'Use atlas_read for Section wording or a complete Node.' It also implies the intended use case for atlas_cards (reading card-shaped data for multiple canonical ids atomically). This is clear routing guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas_decisionsRead Atlas DecisionsARead-onlyIdempotentInspect
List or search the admitted Decision summaries — id, title, Hook, in manifest order. Use atlas_read at 'decision:' for the complete record.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Substring matched against canonical id, title, and body; omit to list every Decision. | |
| 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.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read profile. The description adds that results are summaries rather than full records, are restricted to 'admitted' Decisions, and appear in manifest order, which is useful behavioral context beyond the 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?
Two sentences with no filler: the core action, output contents, ordering, and the key sibling alternative are all included. Every clause carries information relevant to selecting or invoking the tool.
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 the output schema is present and parameter docs are complete, the description only needs to add selection guidance and result-shape cues; it provides both. The explicit atlas_read pointer also closes the main 'what if I need the full Decision?' gap, so an agent has enough to invoke correctly.
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%, with both query and expected_revision fully documented in the input schema. The tool description adds no additional parameter meaning, so it meets the baseline but does not elevate it.
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 action ('List or search'), a clear resource ('admitted Decision summaries'), and the returned fields ('id, title, Hook') plus ordering ('manifest order'). It also distinguishes itself from atlas_read by pointing to that sibling for complete records, so an agent can tell them apart.
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?
The description explicitly routes complete-record needs to atlas_read with the address pattern 'decision:<id>', giving a clear alternative. It does not spell out exclusions relative to the other siblings, but the summary-vs-complete-record split covers the main selection decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas_defineDefine an Atlas TermARead-onlyIdempotentInspect
Define one admitted glossary term. 'match' states the outcome: 'exact' carries the definition, 'ambiguous' lists the narrowing terms, 'none' is a successful miss.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The term to define; a substring naming exactly one term is accepted. | |
| 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
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide the safety profile: read-only, idempotent, non-destructive, and closed-world. The description adds meaningful behavioral detail beyond those annotations: the match state machine with 'exact', 'ambiguous', and 'none', including the fact that 'none' is a successful miss rather than an error.
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 short, front-loaded with the primary action, and every sentence contributes useful information. The match-outcome explanation is compact and avoids 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?
Given the low complexity, strong annotations, and an output schema, the description is largely complete: it conveys the non-obvious matching behavior and confirms that all outcomes are valid. It loses one point because it provides no context for when to use this tool versus its siblings.
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 both parameters, including the substring matching behavior of 'term' and the meaning of 'expected_revision'. The description adds context about the match outcome, but it does not independently explain parameter semantics. A baseline of 3 is therefore 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 states a clear action on a specific resource: 'Define one admitted glossary term.' It also clarifies the core match outcomes, which is useful for an agent. It does not explicitly distinguish itself from sibling tools such as atlas_read or atlas_navigate, so it misses the extra point for sibling differentiation.
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 about when to prefer atlas_define over the sibling tools, nor any mention of exclusions or alternatives. The description implies this is the tool for glossary definitions, but it never states the conditions or contexts that should drive selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas_linksRead Atlas LinksARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| scope | Yes | |
| coherence | Yes | |
| projection | Yes | |
| payload_class | Yes |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, idempotentHint, and non-destructive annotations, the description discloses meaningful behavior: results are ordered outbound-then-inbound, each occurrence includes direction, reference class, source Section, and the far end's Hook, and identity is omitted for 'undisclosed' classes. This is rich behavioral context that annotations alone do not provide.
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?
Two dense sentences with no filler: the first states the operation, scope, ordering, and output fields; the second routes to the closest alternative. The most important constraints are front-loaded.
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 the rich input schema, output schema, and annotations, the description covers everything an agent needs: what the tool returns, the ordering, the field set, the undisclosed-class exception, and the sibling to use when full Node data is required. Nothing significant is missing.
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 baseline is 3 even without extra parameter detail in the tool description. The description does add some semantic context for 'subject' by framing it as the node whose relationship occurrences are paged, but it does not improve on the schema's already clear parameter documentation.
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 opens with a specific verb ('Page') and a clear resource ('one subject's relationship occurrences'), adding ordering and field details. It also distinguishes itself from atlas_read by telling the agent to use that sibling for the full Node. This is a clear, non-tautological statement of what the tool does.
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?
The description explicitly prescribes when to use the sibling atlas_read ('Use atlas_read for the full Node'), which gives an actionable exclusion. It also makes the paging use-case evident through 'Page ... occurrences,' though it does not contrast with other siblings like atlas_navigate or atlas_orient.
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 AtlasARead-onlyIdempotentInspect
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. Candidates carry id, status, Hook, and disclosure class; results are paged. A miss is a successful empty payload.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Restrict to 'pattern', 'concept', or 'example'; excludes Roadmap entries. | |
| 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. Empty lists every subject. | |
| 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
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing the ranking order, the role of identity fields versus Section text, candidate payload fields, paging behavior, and the fact that a miss returns an empty payload. This gives the agent a strong behavioral model before invoking the tool.
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 compact yet information-dense, with the primary purpose front-loaded and every sentence contributing behavioral or selection context. The ranking rules are compressed without losing clarity.
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?
Despite the tool having 6 parameters and a rich output schema, the description covers the core decision logic, candidate field shape, paging, and failure behavior. The output schema covers return details, and the annotations cover safety, so nothing essential is missing for correct invocation.
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 coverage is 100%, so the baseline is 3, but the description meaningfully adds semantics beyond the property descriptions: it explains the query ranking philosophy, how identity fields and sealed claims affect candidacy, and how Section text only matters when no identity match exists. This enriches the otherwise structural parameter documentation.
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 opens with a specific verb and resource: 'Discover canonical identity from an ordinary-language query.' It further distinguishes itself from sibling tools by positioning itself as 'the entry point when no canonical id is held,' making its unique role clear.
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?
It explicitly states when to use the tool: as the entry point when no canonical id is held. It does not explicitly name alternatives or give when-not-to-use conditions, but the stated usage condition is sufficient and clearly differentiates it from ID-based access tools like atlas_read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas_provenanceRead Atlas ProvenanceARead-onlyIdempotentInspect
Expand cited span addresses into audit facts: dependency digest, attestations, and the Release's expanded identity. Atomic batch; only for auditing how a claim is sourced.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| addresses | Yes | Span addresses ('node-id#section-slug') exactly as cited by Card claim '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
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds a meaningful behavioral trait beyond those: 'Atomic batch,' which tells an agent that all requested spans are processed as a unit. It also clarifies that the result is an audit-focused expansion rather than raw data, which is useful contextual behavior.
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?
Two short sentences carry the full purpose, output nature, scoping constraint, and batch behavior without any filler. The core action is front-loaded, and all content earns its place.
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?
With only two parameters, a 100%-described schema, an output schema present, and annotations covering safety semantics, the description supplies the missing behavioral pieces: atomic batch execution and the audit-only use case. Nothing an agent needs to decide whether to call this tool is absent.
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%, and the schema already explains both parameters precisely: addresses use the exact 'node-id#section-slug' format and expected_revision gates on 'revision_changed.' The tool description itself adds little parameter-level meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pairing: 'Expand cited span addresses into audit facts,' and enumerates the exact kind of facts returned (dependency digest, attestations, Release identity). The closing 'only for auditing how a claim is sourced' distinguishes it from general-purpose 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'only for auditing how a claim is sourced' gives a clear context for when to invoke the tool and implicitly rules out general browsing or editing use. It does not name sibling alternatives explicitly, so it stops short of full when/when-not routing.
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 SectionARead-onlyIdempotentInspect
Read a complete Node (bare id: identity, hierarchy, Hook, and every Section — relationships are recovered through atlas_links), one Section ('node-id#section-slug'), or one Decision record ('decision:'). A Card from atlas_cards is usually cheaper than a whole Node.
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>'. | |
| 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 declare read-only, idempotent, and non-destructive behavior. The description adds genuine context beyond those annotations by specifying the payload contents of a Node, the exclusion of relationships, and the multi-address behavior.
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?
Two compact sentences front-load the main purpose and avoid restating the title. Each clause either defines the address modes or provides routing context, with no wasted words.
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?
For a multi-mode read tool with strong annotations, a full output schema, and fully documented parameters, the description covers address variants, payload scope, and relationship behavior. Nothing an agent needs to decide whether and how to call the tool is missing.
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 fully documents both 'address' and 'expected_revision'. The description repeats the address shapes but adds no meaning beyond what the schema provides, so it stays at the baseline.
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 uses a specific verb ('Read') and names exactly what can be read: a complete Node, one Section, or one Decision record. It also distinguishes itself from atlas_cards and atlas_links by stating what they provide, so an agent can tell this tool apart from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete routing guidance: relationships are recovered through atlas_links rather than included here, and atlas_cards is usually cheaper when a Card is the target. This is a clear when-to-use-alternative signal, and the address forms themselves define the boundaries of the tool.
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. Dates show when Glama detected each change.
1 tool update
- Changed
atlas_orient1 field changed- changed
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; 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 update
- Changed
atlas_read1 field changed- changed
Input 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>'."
8 tool updates
- Changed
atlas_cards1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"
- Changed
atlas_decisions1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"
- Changed
atlas_define1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"
- Changed
atlas_links1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"
- Changed
atlas_navigate1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"
- Changed
atlas_orient2 fields changed- changed
Input 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." - changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"
- Changed
atlas_provenance1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"
- Changed
atlas_read1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v4"New value: +"agent-projection/v5"
8 tool updates
- Changed
atlas_cards1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"
- Changed
atlas_decisions1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"
- Changed
atlas_define1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"
- Changed
atlas_links1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"
- Changed
atlas_navigate1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"
- Changed
atlas_orient1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"
- Changed
atlas_provenance1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"
- Changed
atlas_read1 field changed- changed
Output schema / properties / projection / constPrevious value: -"agent-projection/v3"New value: +"agent-projection/v4"
8 tool updates
- Changed
atlas_cards1 field changed- changed
Output 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" +}
- Changed
atlas_decisions1 field changed- changed
Output 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" +}
- Changed
atlas_define1 field changed- changed
Output 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" +}
- Changed
atlas_links1 field changed- changed
Output 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" +}
- Changed
atlas_navigate1 field changed- changed
Output 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" +}
- Changed
atlas_orient1 field changed- changed
Output 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" +}
- Changed
atlas_provenance1 field changed- changed
Output 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" +}
- Changed
atlas_read1 field changed- changed
Output 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 updates
- Changed
atlas_cards2 fields changed- changed
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." - changed
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."
- Changed
atlas_decisions2 fields changed- changed
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." - changed
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."
- Changed
atlas_define2 fields changed- changed
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." - changed
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."
- Changed
atlas_links4 fields changed- changed
Input schema / properties / bound / descriptionPrevious value: -"Maximum occurrences per page, 1-50 (default 12)."New value: +"Occurrences per page, 1-50." - changed
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." - changed
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." - changed
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."
- Changed
atlas_navigate2 fields changed- changed
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." - changed
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."
- Changed
atlas_orient6 fields changed- changed
Input schema / properties / bound / descriptionPrevious value: -"Maximum candidates per page, 1-8 (default 3)."New value: +"Candidates per page, 1-8." - changed
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." - changed
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." - changed
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." - changed
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." - changed
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'."
- Changed
atlas_provenance2 fields changed- changed
Input 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'." - changed
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."
- Changed
atlas_read2 fields changed- changed
Input 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>'." - changed
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."
3 tool updates
- Changed
atlas_decisions1 field changed- changed
Input 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."
- Changed
atlas_orient1 field changed- changed
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; 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."
- Changed
atlas_provenance1 field changed- changed
Input 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'."
8 tool updates
- Changed
atlas_cards2 fields changed- added
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." - added
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."
- Changed
atlas_decisions2 fields changed- added
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." - added
Input schema / properties / query / descriptionAdded value: +"Case-insensitive substring matched against each Decision's title and full body. Omit to list every admitted Decision."
- Changed
atlas_define2 fields changed- added
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." - added
Input schema / properties / term / descriptionAdded value: +"The glossary term to define, matched case-insensitively; a substring is accepted when it names exactly one term."
- Changed
atlas_links4 fields changed- added
Input schema / properties / bound / descriptionAdded value: +"Maximum occurrences per page, 1-50 (default 12)." - added
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'." - added
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." - added
Input schema / properties / subject / descriptionAdded value: +"The one canonical node id whose relationship occurrences are paged."
- Changed
atlas_navigate2 fields changed- added
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." - added
Input schema / properties / view / descriptionAdded value: +"'tree' for the canonical ordered traversal of every published node; 'tour' for the publisher-curated first learning path."
- Changed
atlas_orient6 fields changed- added
Input schema / properties / bound / descriptionAdded value: +"Maximum candidates per page, 1-8 (default 3)." - added
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'." - added
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." - added
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." - added
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." - added
Input schema / properties / status / descriptionAdded value: +"Restrict candidates to one maturity rung of the corpus status ladder; published subjects sit at 'fleshed' or 'stable'."
- Changed
atlas_provenance2 fields changed- added
Input 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." - added
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."
- Changed
atlas_read2 fields changed- added
Input 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." - added
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."
8 tool updates
- First observed
atlas_cards - First observed
atlas_decisions - First observed
atlas_define - First observed
atlas_links - First observed
atlas_navigate - First observed
atlas_orient - First observed
atlas_provenance - First observed
atlas_read
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Public agentic AI doctrine tools plus authenticated architecture, design, and spec validators.
Read-only tools over the Safer Agentic AI framework: 238 patterns + 14 heuristics.
Agent microtools: secret scanning, preflight, receipts, JSON checks and Zero Point analysis.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to query a curated, cited knowledge graph on testing, benchmarking, and auditing autonomous agents, returning claims with sources, confidence values, and evidence tiers through eight read-only tools over a remote streamable-HTTP endpoint with no authentication required.CC BY-4.0
agent-taskofficial
FlicenseNot gradedqualityBmaintenanceAgentTask is a governed work platform where human teams and AI agents share one backlog. Hosted remote MCP server (streamable HTTP, OAuth 2.1 or org API keys) with 60+ tools for tasks, subtasks, projects, groups, labels, notes, comments, attachments, search, crews, and agent runs.-- AlicenseAqualityAmaintenancehe industry standard reference for safe, observable, and steerable AI agent UX. Browse and search 10 Blueprint principles, clusters, curated implementation examples, and application guides. 13 public tools require no credentials.293MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.1/5.0
Disambiguation5/5
Each tool targets a distinct operation: discovery, navigation, reading, relationship paging, auditing, decisions, and glossary lookup. Descriptions explicitly cross-reference alternatives like atlas_cards vs atlas_read, so an agent can reliably choose the right tool.
Naming Consistency3/5
All names share the atlas_ prefix and are short, but conventions are mixed: cards, decisions, links, and provenance are noun resources while define, navigate, orient, and read are imperative verbs. The set is readable but does not follow a single verb_noun pattern.
Tool Count5/5
Eight tools is well-scoped for a canonical read-only atlas covering discovery, structured reading, navigation, relationships, decisions, glossary, and provenance. Each tool earns its place without feeling bloated or thin.
Completeness5/5
The surface covers the natural read-only workflow: discover identity, navigate structure, read nodes and sections, inspect relationships, look up definitions, check decisions, and audit provenance. Write operations are not an obvious gap given the corpus appears intentionally immutable.