List works kapoost owns but did NOT create. Public items always; members-only surface only after session activation.
| Name | Required | Description | Default |
|---|---|---|---|
| session_token | No | Optional. The SESSION_TOKEN emitted by bootstrap_session. Pass it here when your client cannot set a per-call Authorization: Bearer header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the access model (public always, members-only after session activation) which is a behavioral constraint. However, it does not explicitly state that the operation is read-only or non-destructive, and there is no mention of error conditions or rate limits. For a list operation, the absence of side-effect warnings is less critical, but the description could be more explicit about safety.
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?
Two concise sentences, with the core purpose front-loaded. The first sentence states exactly what is listed, and the second adds a critical access condition. No redundancy or filler. Padding is minimal and every word contributes to understanding.
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 simple tool with one optional parameter and no output schema, the description covers the essential context: what is listed, the ownership distinction, and the session-token requirement for restricted items. It does not specify the return format or pagination, but given the low complexity and that sibling tools likely share conventions, this is adequate. A more complete description might mention whether results are sorted or limited, but that is a minor gap.
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?
The only parameter, session_token, is fully described in the input schema (100% coverage). The description adds no additional meaning beyond the schema, so it meets the baseline for when schema covers everything. No extra value is provided, but none is needed.
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?
Description clearly states the tool lists works 'kapoost owns but did NOT create', which is a specific and distinctive purpose. It also mentions the public-vs-members-only visibility split, making it stand out from sibling list tools like list_content or list_blobs. The verb 'List' and the resource are unambiguous.
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 gives a clear condition for usage: it lists works not created by the owner, and notes that members-only items appear only after session activation. This implies when to use it (when you need such works) but does not explicitly name alternatives or state when not to use it. The session activation context is a useful prerequisite signal, so this is above average but not explicit about exclusions.
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.
Most tools have clearly distinct purposes with detailed descriptions, but a few boundaries are fuzzy: leave_message vs ask_human vs leave_comment, and list_content vs list_collection could confuse an agent at first glance. Overall, the descriptions are thorough enough to disambiguate.
The naming convention is predominantly snake_case with verb_noun structure (list_content, read_blob, upsert_skill). Minor deviations exist such as the mysloodsiewnia_* prefix and British spelling in synthesise_persona_patterns, but the pattern is highly recognizable and readable.
At 41 tools, the surface area is very large for a single MCP server and exceeds the 'heavy' threshold. While each tool serves a distinct purpose, the sheer number makes the server feel bloated and harder to navigate; many tools could be grouped or pruned without losing core functionality.
The server covers a broad domain: content read/list, personas, skills management, vault CRUD (except update/delete intentionally), provenance, licensing, memory, and async question/narada workflows. Minor gaps exist like no tool to cancel a narada job or update a memory, but these are workable and the core workflows are well supported.