Skip to main content
Glama

kb_search

Read-only

Search the code of the project folders the user added ("alarm handler", "FB_Valve", "CONCAT"): unit, kind, file and the matching declaration/code excerpts, best first. Names and identifiers count as their words (FB_AlarmList: alarm, list).

Instructions

Search the code of the project folders the user added ("alarm handler", "FB_Valve", "CONCAT"): unit, kind, file and the matching declaration/code excerpts, best first. Names and identifiers count as their words (FB_AlarmList: alarm, list). Units with EVERY word first, then every word as a prefix ('CounterMod' finds FB_CounterModule); a unit whose code holds the words before one that has them only in comments (match_in='comments'); only when none has them all, units with some words (match='some words', with the words each unit holds; words on no unit or on most units are not used and are listed). A unit that declares the name (variable, constant, member, enum value, its own name) comes first (declares). Stop words ('how', 'to', 'the') and, in a query of several words, single characters are not searched; a query of stop words only is refused. There are no query operators: OR / AND / NOT / NEAR, '-', '^', '*' are not read as such (operators_note). A copy name (PRG_X_9) that no unit has falls back to the name it was copied from. "quoted text" is a phrase; tokens joined by punctuation ('STRING(40)', 'fbTimer(IN:=') are searched as one sequence (searched_as_sequence), a qualified name ('GVL_X.nY') as its names. A unit whose own name holds the words comes before its members. kinds (checked): PROGRAM, FUNCTION_BLOCK/FB, FUNCTION, POU (= those three), METHOD, PROPERTY, ACTION, INTERFACE, STRUCT, ENUM, GVL, DUT (= every data type) …; with kinds, a member is answered as its owner of those kinds (via_member: 'Execute' kinds=[INTERFACE] → I_Module); no hit names the units of other kinds that have the words. words_not_in_code: the words a hit has only in comments / string literals. project = the folder (any spelling) or its label; limit 1–200. stale: folders changed, renamed or deleted since they were indexed — their hits are those of the last indexing (kb_reindex); changed_files / added_files / removed_files name them. An error message — a code in a notation that says so (ADSError 1861, pyads' 'ADSError: … (1861)', ADS error 1861, error 1861, nErrId := 1861, 0x98110745, ADSERR_CLIENT_SYNCTIMEOUT), a compiler message (C0046: …), or a 0x number alone; not the word 'error', a decimal / 16# literal alone, a hex number anywhere or an ERR_… identifier of the code — gets the plugin's note in known_error (ADS return codes 6, 7, 1793, 1796, 1797, 1799, 1808, 1861 with code and symbol, license, XAE busy / dialog / disconnected, logged in, compiler: identifier not defined, cannot convert type, unknown type; null + known_errors_covered when it has none) and is searched only for the names of the code it holds (quoted, or identifiers such as fbCounter, FB_Valve, MAIN.fbX). Beckhoff documentation is not here: the twincat-docs skill.

Input Schema

NameRequiredDescriptionDefault
kindsNo
limitNo
queryYes
projectNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.12

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare a safe read; the description goes far beyond them, disclosing ranking order, prefix fallback, comment-vs-code priority, stop-word and operator handling, kinds coercion (via_member), stale-index behavior with kb_reindex and changed/added/removed file names, and the error-code note mechanism with known_error. It also reveals a refusal condition (stop-words-only query), which is exactly the kind of behavior an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and almost every clause carries real information, but the body is a dense run-on of nested parentheticals and backticked response-field names that is hard to scan. Necessary content is present; its packaging costs readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter search tool with an output schema, the description covers everything needed to call it correctly – matching rules, filtering, result ordering, index staleness, and edge cases like copied PRG names. Nothing an agent must know before invoking it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry all four parameters – and it does: query syntax (phrases, sequences, qualified names, operators not honored, stop words), kinds with an enumerated value list and POU/DUT aliases, project as folder spelling or label, and the limit range 1–200. No parameter is left ambiguous.

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?

The opening sentence gives a specific verb and resource – search the code of user-added project folders – and states what each hit contains (unit, kind, file, matching excerpts, best first). It draws one boundary by excluding Beckhoff documentation (routing to twincat-docs), but never distinguishes itself from the closest siblings such as proj_search or infosys_search_code.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the query semantics and by the explicit note that documentation is not here, which sends the agent elsewhere. However, there is no statement of when to prefer kb_search over proj_search (live project) or infosys_search_code (installed-library symbols), which are the most likely confusions for an agent.

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

Deploy Server

Other Tools