Skip to main content
Glama
Sign In

brainkb

by org.brainkb
OverviewDiscussionsAdmin

brainkb_list_spaces

List spaces the user can see (their own/member spaces + public ones), each annotated with THIS caller's permission so you know what they may do: - your_role: 'owner' | 'editor' | 'viewer' | null (their space membership, including a role inherited from a parent space) - role_inherited: the role comes from a parent space, not this one - parent_slug: the parent space, when this is a subspace the caller can see the parent of (build the tree from it) - is_owner: they own the space - access: 'owner' | 'member' | 'public' (how it's available to them) - can_write: their space role permits ingest (owner/editor) — a real ingest also needs the 'ingest' capability + any per-space access rules. Use this to tell the user which spaces they can read vs. write vs. only see as public.

No login needed: an unauthenticated caller gets the public spaces only
(read-only). Log in to also see your own/member spaces.

`owner` is shown only for spaces the caller is a member of; a public space
read by a non-member never exposes its owner's email.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/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 auth requirement, the read-only degradation for anonymous callers, the meaning of can_write (role permits ingest, but ingest also needs the capability plus per-space rules), and a privacy behavior (owner email never exposed for public spaces read by non-members). It omits pagination/result-size behavior, keeping it from a 5.

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?

The purpose is front-loaded and the field-by-field enumeration is largely justified because there is no output schema. It runs long for a zero-parameter read tool, with mild redundancy (is_owner overlaps your_role 'owner'), but each bullet adds usable meaning rather than 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?

For a low-complexity, no-param list tool with no output schema and no annotations, the description supplies the two things an agent actually needs: the auth model and the meaning of each returned field. Only minor gaps remain (ordering, pagination, or result limits are unstated).

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Nothing in the text misleads about inputs.

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?

States a clear verb and resource with explicit scope: 'List spaces the user can see (their own/member spaces + public ones)'. The scope definition implicitly separates it from the close sibling brainkb_list_writable_spaces, but neither that sibling nor brainkb_space_tree is named, so an agent must infer the boundary.

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?

Gives a concrete use case ('tell the user which spaces they can read vs. write vs. only see as public') and explains the unauthenticated case (public spaces only, read-only; log in for own/member spaces). It stops short of naming alternative tools or stating exclusions, so it is clear context without routing.

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

All brainkb toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources