Skip to main content
Glama

get_concept

Read-only

Fetch a single ontology node by slug or UID to get its definition, evidence, graph neighbors, and edges. Request full body when reading for answers, not just identification.

Instructions

Fetch one node by exactly one selector: slug (canonical slug or unique alias) or immutable uid. Successful responses always carry both the permanent uid and current canonical slug; graph relations and graph-operation inputs remain slug-based. Returns frontmatter, body, direct graph neighbors, outgoingEdges (each {to, via, rationale?}, the rationale being the stored relation_notes sentence when one exists), and mtime. By default you get excerpt — the first prose paragraph only. The node body is where the construction rules put definition, evidence, confidence, and in-scope/out-of-scope, so pass body: "full" whenever you are reading a node to answer a question rather than just to identify it. bodyInfo always reports totalChars / returnedChars / truncated, so a partial read is never silent. For K specific selectors in one call use get_concepts({slugs: [...]}) or get_concepts({uids: [...]}). When a slug does not resolve, structured growth guidance remains available.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidNoExact permanent node UID. Use instead of `slug`, never together with it.
bodyNo`excerpt` (default) returns the first prose paragraph as `excerpt`. `full` returns the entire markdown body as `body` and omits `excerpt`. Use `full` when the answer depends on what the node actually says — evidence paths, confidence, scope boundaries.
slugNoVault-relative slug (e.g. projects/auth-platform), unique tail slug, or frontmatter `slug` alias. Omit the .md extension.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYesPermanent immutable node identity.
bodyNoEntire markdown body. Present only when the caller passed `body: "full"`.
slugYes
mtimeYes
isNodeYes
reviewYes
excerptNoFirst prose paragraph. Present only when `body` is `excerpt` (the default).
bodyInfoYesHow much of the body this response carries — always present, so truncation is never silent.
warningsNo
neighborsYesDirect graph neighbor buckets.
frontmatterYesResolved markdown frontmatter.
outgoingEdgesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.0
    • changedOutput schema / properties / warnings / items / properties / code / enum
      Previous value: -[
      -  "unclosed-frontmatter",
      -  "parse-zero-keys",
      -  "malformed-frontmatter-line",
      -  "malformed-quoted-scalar",
      -  "missing-kind",
      -  "empty-kind",
      -  "unknown-kind",
      -  "missing-uid",
      -  "invalid-uid",
      -  "invalid-merged-uids",
      -  "non-canonical-merged-uids",
      -  "missing-expected-field",
      -  "non-canonical-graph-array",
      -  "dangling-graph-reference",
      -  "duplicate-slug",
      -  "duplicate-uid",
      -  "definition-missing",
      -  "boundary-missing",
      -  "epistemic-exclusion",
      -  "uncertainty-missing",
      -  "slug-outside-kind-folder",
      -  "folder-only-evidence",
      -  "dependency-unwitnessed",
      -  "starter-example-node"
      -]New value: +[
      +  "unclosed-frontmatter",
      +  "parse-zero-keys",
      +  "malformed-frontmatter-line",
      +  "malformed-quoted-scalar",
      +  "missing-kind",
      +  "empty-kind",
      +  "unknown-kind",
      +  "missing-uid",
      +  "invalid-uid",
      +  "invalid-merged-uids",
      +  "non-canonical-merged-uids",
      +  "missing-expected-field",
      +  "non-canonical-graph-array",
      +  "dangling-graph-reference",
      +  "duplicate-slug",
      +  "duplicate-uid",
      +  "definition-missing",
      +  "boundary-missing",
      +  "epistemic-exclusion",
      +  "uncertainty-missing",
      +  "slug-outside-kind-folder",
      +  "folder-only-evidence",
      +  "dependency-unwitnessed",
      +  "dependency-unjudged",
      +  "starter-example-node",
      +  "kind-under-sources"
      +]
  2. Changed1 schema field changedv1.3.0
    • changedOutput schema / properties / warnings / items / properties / code / enum
      Previous value: -[
      -  "unclosed-frontmatter",
      -  "parse-zero-keys",
      -  "malformed-frontmatter-line",
      -  "malformed-quoted-scalar",
      -  "missing-kind",
      -  "empty-kind",
      -  "unknown-kind",
      -  "missing-uid",
      -  "invalid-uid",
      -  "invalid-merged-uids",
      -  "non-canonical-merged-uids",
      -  "missing-expected-field",
      -  "non-canonical-graph-array",
      -  "dangling-graph-reference",
      -  "duplicate-slug",
      -  "duplicate-uid"
      -]New value: +[
      +  "unclosed-frontmatter",
      +  "parse-zero-keys",
      +  "malformed-frontmatter-line",
      +  "malformed-quoted-scalar",
      +  "missing-kind",
      +  "empty-kind",
      +  "unknown-kind",
      +  "missing-uid",
      +  "invalid-uid",
      +  "invalid-merged-uids",
      +  "non-canonical-merged-uids",
      +  "missing-expected-field",
      +  "non-canonical-graph-array",
      +  "dangling-graph-reference",
      +  "duplicate-slug",
      +  "duplicate-uid",
      +  "definition-missing",
      +  "boundary-missing",
      +  "epistemic-exclusion",
      +  "uncertainty-missing",
      +  "slug-outside-kind-folder",
      +  "folder-only-evidence",
      +  "dependency-unwitnessed",
      +  "starter-example-node"
      +]
  3. Changed3 schema fields changedv1.2.5
    • addedOutput schema / properties / isNode
      Added value: +{
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / review
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "agentGuidance": {
      +      "minLength": 1,
      +      "pattern": "^(?!\\s)(?!.*\\s$)(?!.*\\u0000).+$",
      +      "type": "string"
      +    },
      +    "currentness": {
      +      "enum": [
      +        "not-confirmed",
      +        "unknown",
      +        "current",
      +        "changed-since-review"
      +      ],
      +      "type": "string"
      +    },
      +    "note": {},
      +    "reviewedAt": {},
      +    "reviewedBy": {},
      +    "state": {}
      +  },
      +  "required": [
      +    "state",
      +    "currentness"
      +  ],
      +  "type": "object"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "uid",
      -  "slug",
      -  "frontmatter",
      -  "bodyInfo",
      -  "neighbors",
      -  "outgoingEdges",
      -  "mtime"
      -]New value: +[
      +  "uid",
      +  "slug",
      +  "isNode",
      +  "frontmatter",
      +  "bodyInfo",
      +  "neighbors",
      +  "outgoingEdges",
      +  "review",
      +  "mtime"
      +]
  4. First observedv0.13.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial context beyond them: default returns only the first prose paragraph, bodyInfo always reports totalChars/returnedChars/truncated so partial reads are never silent, and it explains that uid/slug are always both returned.

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

Conciseness4/5

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

Front-loaded with the core operation and selector rule, and every sentence carries distinct information. It is dense and heavily bolded, which costs a little readability, but little is wasted.

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 an output schema existing, the description still communicates the shape of the response (frontmatter, body, neighbors, outgoingEdges with rationale, mtime) and the truncation contract, so an agent has everything needed to call and interpret it.

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 adds real semantic value: the excerpt-vs-full tradeoff and that 'full' omits 'excerpt', plus the mutual exclusivity of slug and uid beyond what the schema's own text states.

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?

Specific verb+resource ('Fetch one node') with an explicit uniqueness constraint on selectors (exactly one of slug or uid). It clearly differentiates itself from the sibling get_concepts, which it names for the multi-selector case.

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?

Gives explicit when-to-use guidance: default excerpt for identification, pass body:'full' when reading to answer a question, and use get_concepts for K selectors in one call. It even notes fallback behavior when a slug fails to resolve.

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