Search kapoost's pieces by words in title, tags, description and body. Every word must match (AND). Polish diacritics are folded, so "czlowieczenstwa" finds "człowieczeństwa". Use this BEFORE ask_human — most questions about which piece is which are answered here instantly, while ask_human waits for a human. Locked pieces are matched by title and tags only; their body is never searched or quoted.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "content": {
+ "items": {
+ "properties": {
+ "text": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains that all terms must match (AND), diacritics are folded, and locked pieces are handled differently (matched by title/tags only, body never searched). It doesn't explicitly state that the tool is read-only, but the search action implies non-destructive behavior, which is a minor gap since no annotations are present.
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 a single, compact paragraph that front-loads the key behavior (search scope and AND logic) and then adds usage guidance. It is efficient, but the mention of locked pieces could be moved to a separate section for clarity; still, it's not bloated.
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?
Given the tool's complexity (two simple parameters, no output schema), the description covers the essential aspects: what is searched, how matching works, when to use it, and the locked-piece caveat. It lacks explicit information about the return format, but since there is no output schema, that might be a minor gap. However, the tool is a search with likely a list of results, which is predictable.
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 0%, but the description provides meaningful context for the 'query' parameter, explaining how it is used (search terms, AND logic, diacritic folding). It does not mention the 'limit' parameter, but its name is self-explanatory as a limit on results. The description partially compensates for the lack of schema descriptions.
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 clearly states the tool searches pieces by words in title, tags, description, and body with an AND requirement. It differentiates from siblings like 'read_content' and 'list_content' by focusing on keyword search rather than listing or reading. However, it doesn't explicitly mention how it differs from 'mysloodsiewnia_search', which might also be a search tool.
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?
Explicitly instructs to use this tool BEFORE ask_human for questions about which piece is which, and mentions that it provides instant answers while ask_human waits for a human. It also clarifies how it handles locked pieces, which helps agents decide when to use it.
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.