List the knowledge bases you own (and any organization KBs you belong to), each with its embedding model, whether an embedding key is bound, document count, and how many agents/departments it is attached to. READ-ONLY.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| knowledge_bases | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already communicates the safety profile, and the description reinforces it with 'READ-ONLY.' It adds useful context about visibility (own KBs plus organization KBs) and the data returned, but it does not disclose behaviors such as pagination, auth requirements, or response size limits. This matches the level of a simple list tool whose annotations already cover side effects.
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?
A single front-loaded sentence states the action, scope, and returned fields with no filler. The 'READ-ONLY' flag is appended as a clear safety signal, and every clause earns its place.
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 parameterless read-only list operation with an output schema available, the description covers everything needed: what is listed, whose KBs are included, and what attributes are returned. There are no parameters to document and no hidden invocation requirements to infer.
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 tool has zero parameters, so the baseline is 4; there is nothing for the description to add about argument semantics. The schema already records an empty parameter set with 100% coverage.
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 ('List'), names the resource ('knowledge bases'), and sharply defines scope: KBs you own plus organization KBs you belong to. It also enumerates the returned fields, which distinguishes it from sibling tools like findagent_list_kb_documents and findagent_list_kb_attachments.
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 makes the applicability clear by stating the ownership/membership scope, so an agent knows exactly what set of knowledge bases this tool covers. It does not explicitly name alternatives or state when-not-to-use it, but for a read-only listing tool with distinctive scope this is sufficient.
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.
Every tool targets a clearly scoped resource+action combination, and the versioning variants (bump_version vs repull vs reintrospect_mcp) are explicitly disambiguated by agent kind. Even with 52 tools, the descriptions make each purpose distinct enough to avoid misselection.
Nearly all tools follow the findagent_<verb>_<object> snake_case pattern, and families share predictable verbs like list, create, delete, edit, and submit. Minor exceptions such as findagent_preflight, findagent_whoami, and findagent_earnings keep it from perfect consistency.
At 52 tools, this far exceeds the 25-tool threshold for a coherent MCP surface. The count may reflect a broad platform, but as a single toolset it is heavy and likely to strain agent selection and context.
The surface covers publishing, versioning, knowledge bases, org management, GitHub import, purchases, and the demand board in impressive depth. However, there are notable dead ends: no unpublish/delete for a live agent, no request-fulfillment/linking action, and no org deletion or KB document update.
