Enhanciar: AI company brain

get_page

Read the full text of one wiki page.

Use it after search_wiki or list_pages when you need the whole page, or to open a page query cited. Pass category and name from those results, or one path like "concepts/billing-flow". Returns {category, name, content}, where content is the page's Markdown including its YAML header (title, sources, dates). A missing or hidden page returns {error} saying what to pass instead; it costs no AI tokens.

Input Schema

Name	Required	Description
`name`	No	String. The page's ``name`` from ``list_pages`` or ``search_wiki``, without ".md", e.g. "billing-flow". Default ""; give this or ``path``.
`page`	No	String. Same as ``name``; accepted for clients that send it. Default "".
`path`	No	String. Category and name in one, e.g. "concepts/billing-flow"; use instead of ``category`` + ``name``. Default "".
`slug`	No	String. Same as ``name``; accepted for clients that send it. Default "".
`title`	No	String. Same as ``name`` (the page's name, not its display title); accepted for clients that send it. Default "".
`category`	No	String. The page's folder, from a ``list_pages`` or ``search_wiki`` result, e.g. "concepts". One of: entities, concepts, people, decisions, sources, flows, infrastructure, tickets, chats, mail, docs, conversations, schemas, skills. Default "": found from ``name``.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 17, 2026

addedInput schema / properties / category / description

Added value: +"String. The page's folder, from a ``list_pages`` or ``search_wiki`` result, e.g. \"concepts\". One of: entities, concepts, people, decisions, sources, flows, infrastructure, tickets, chats, mail, docs, conversations, schemas, skills. Default \"\": found from ``name``."

addedInput schema / properties / name / description

Added value: +"String. The page's ``name`` from ``list_pages`` or ``search_wiki``, without \".md\", e.g. \"billing-flow\". Default \"\"; give this or ``path``."

addedInput schema / properties / page / description

Added value: +"String. Same as ``name``; accepted for clients that send it. Default \"\"."

addedInput schema / properties / path / description

Added value: +"String. Category and name in one, e.g. \"concepts/billing-flow\"; use instead of ``category`` + ``name``. Default \"\"."

addedInput schema / properties / slug / description

Added value: +"String. Same as ``name``; accepted for clients that send it. Default \"\"."

addedInput schema / properties / title / description

Added value: +"String. Same as ``name`` (the page's name, not its display title); accepted for clients that send it. Default \"\"."

Changed9 schema fields changedSep 30, 2026
- addedInput schema / properties / category / default
```
Added value: +""
```
- removedInput schema / properties / category / type
```
Removed value: -"string"
```
- addedInput schema / properties / name / default
```
Added value: +""
```
- removedInput schema / properties / name / type
```
Removed value: -"string"
```
- addedInput schema / properties / page
```
Added value: +{
+  "default": "",
+  "title": "Page"
+}
```
- addedInput schema / properties / path
```
Added value: +{
+  "default": "",
+  "title": "Path"
+}
```
- addedInput schema / properties / slug
```
Added value: +{
+  "default": "",
+  "title": "Slug"
+}
```
- addedInput schema / properties / title
```
Added value: +{
+  "default": "",
+  "title": "Title"
+}
```
- removedInput schema / required
```
Removed value: -[
-  "category",
-  "name"
-]
```
First observedSep 20, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the return shape ({category, name, content}), that content is Markdown including the YAML header, and the error behavior for missing/hidden pages with a note that failures cost no tokens. It doesn't cover pagination or permissions, but for a read tool this is solid behavioral disclosure.

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-loads the core purpose in the first sentence, then covers usage, inputs, and return/error behavior in a few tight sentences with no filler. Slightly dense with inline literals, but every sentence 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?

An output schema exists, so return values needn't be explained, yet the description still adds the error case and the Markdown-with-frontmatter nature of content. Combined with the sibling routing and alias handling, an agent has everything needed to call it 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%, so the schema already documents all six parameters and their aliases. The description adds only routing context ('Pass category and name from those results, or one path'), so baseline 3 is correct.

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

Purpose5/5

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

States a specific verb and resource ('Read the full text of one wiki page') and immediately distinguishes itself from siblings by saying it is used after search_wiki or list_pages. An agent can tell exactly what it retrieves without opening the schema.

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?

Names the alternatives (search_wiki, list_pages, query) and the condition that selects this tool: when you 'need the whole page' or want to open a page that query cited. Explicit when-to-use routing, nothing left to inference.

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

All Enhanciar: AI company brain tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?