Skip to main content
Glama
Sign In
twincat-mcp

twincat-mcp

by Disectron
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

infosys_search

Read-only

Full-text search over the local Help Viewer index (FTS5, bm25-ranked, excerpt with [hits]); "quoted phrases" stay together, limit 1..50.

Instructions

Full-text search over the local Help Viewer index (FTS5, bm25-ranked, excerpt with [hits]); "quoted phrases" stay together, limit 1..50. Offline — no web search (web_fallback is ignored and said so); results carry the page's doc version and the package date.

Input Schema

NameRequiredDescriptionDefault
limitNohits per page, 1-50; a larger limit is used as 50 (clamped: true)
queryYes
offsetNoskipped first: the next page is offset=<next_offset>
libraryNo
web_fallbackNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.8.18
    • addedInput schema / properties / limit / description
      Added value: +"hits per page, 1-50; a larger limit is used as 50 (clamped: true)"
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "description": "skipped first: the next page is offset=<next_offset>",
+  "minimum": 0,
+  "title": "Offset",
+  "type": "integer"
+}
  2. First observedv0.6.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the read-only, non-destructive profile, and the description adds real value beyond them: bm25 ranking, excerpt format with [hits], quoted-phrase matching, limit clamping, web_fallback being silently ignored, and result metadata (doc version, package date). That is a materially richer behavioral picture than the annotations alone.

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

Conciseness5/5

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

A single dense but well-structured sentence: purpose first, then query syntax, then the offline caveat, then return metadata. No filler, and the most decision-relevant fact (offline) is not buried.

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?

An output schema exists, so the description does not need to explain return values — yet it usefully notes results carry doc version and package date. The main gap is the unexplained library parameter for a 5-parameter tool; otherwise an agent has enough to call it correctly.

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

Parameters3/5

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

Schema coverage is only 40%, so the description has to compensate. It does explain query semantics ('"quoted phrases" stay together'), the limit range, and the disposal of web_fallback, but it says nothing about library or offset, leaving those parameters documented only partially (or not at all, in library's case). Partial compensation warrants a middle score.

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 specific verb and resource: 'Full-text search over the local Help Viewer index', with implementation detail (FTS5, bm25-ranked) that makes it concrete. It implicitly separates itself from web/project search siblings by saying 'local Help Viewer index', though it never names kb_search, proj_search, or infosys_search_code explicitly.

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?

Establishes a strong usage boundary in one direction — 'Offline — no web search (web_fallback is ignored and said so)' tells the agent this tool will not reach the web. However, it gives no guidance on when to pick this over the many other search siblings (kb_search, proj_search, infosys_search_code, infosys_search_symbols), which is the main routing ambiguity an agent faces.

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