brain_getRead one Brain file by name (e.g. coding-conventions.md), across your brains and brains shared with you. Needs your agent bearer token.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | File name including .md | |
| brain | No | Optional brain to read from (owner-handle/name for shared brains). Omit to search all your brains. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the operation type ('Read'), the scope ('across your brains and brains shared with you'), and the auth requirement ('Needs your agent bearer token'). It does not mention potential ambiguity when the same file name exists in multiple brains, but for a simple read it is fairly transparent.
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 with no filler. The action and example are front-loaded, and the auth note is one short clause. Every sentence contributes a distinct piece of information.
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?
For a two-parameter read tool with no output schema and no annotations, the description covers what it does, the scope, and required auth. It lacks details on return format or error behavior, but these are not essential to selecting and invoking the tool correctly.
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%, so the schema already documents both 'name' and 'brain'. The description adds a concrete file-name example and clarifies scope across shared brains, but this is modest added value beyond the structured schema.
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 uses a specific verb ('Read'), a clear resource ('one Brain file by name'), and a concrete example ('coding-conventions.md'). It differentiates from siblings by emphasizing exact-name lookup rather than listing or searching, so an agent can tell it apart from brain_list and brain_search.
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?
The description implies the tool is for reading a known file name across all accessible brains, and mentions the auth requirement. However, it does not explicitly state when to prefer this over brain_search or brain_list, nor does it describe exclusions or prerequisites beyond the token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: brain_get/brain_list/brain_search/brain_write cover memory operations, while get_collection/get_skill/install_skill/search_skills/submit_skill handle skill discovery, retrieval, installation, and submission. No two tools overlap in function; even the search vs get pairs are distinct.
The brain_* prefix provides a consistent pattern for memory tools, but the skill tools use mixed conventions: get_collection, get_skill, install_skill, search_skills, submit_skill — no shared prefix or uniform verb_noun structure. This inconsistency is noticeable but each name is still readable.
With 9 tools covering two domains (memory and skills), the count is well-scoped. Each tool earns its place, and the number is within the ideal range for a focused server.
The brain tools cover list, get, search, and write, but lack an explicit delete operation. The skill tools cover search, get, install, submit, and collection listing, but no uninstall. These are minor gaps that agents can work around; the core workflows are complete.