Skip to main content
Glama

search_knowledge

Search the Lumis knowledge base for life sciences CRM migration intelligence, including readiness assessment and module mapping. Filter by value chain phase, area, and knowledge category.

Instructions

Search the Lumis knowledge base across the life sciences value chain.

Foundation knowledge (org strategy, regulatory, terminology) is always included. Use phase and area to narrow scope.

Args: query: Natural language search query phase: Value chain phase — 'discovery', 'clinical', 'commercialization', 'foundation', or 'all' area: Area within phase — e.g. 'crm', 'safety-pv', 'regulated-content', 'market-access', or 'all' category: Knowledge category — 'modules', 'decision-trees', 'gotchas', 'country-rules', 'validation-rules', 'terminology', 'org-strategy', or 'all' limit: Maximum results to return (default 5)

Input Schema

NameRequiredDescriptionDefault
areaNoall
limitNo
phaseNoall
queryYes
categoryNoall

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose one meaningful behavior — foundation knowledge is unconditionally included in every result set — which an agent could not otherwise know. It says nothing about ranking, whether results are paginated, or whether the search is read-only (implied but unstated), leaving real behavioral gaps.

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

Conciseness4/5

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

Front-loaded with the purpose and the scoping hint before the parameter list, and every line is informative. The Args block is somewhat verbose relative to a normal description, but it is justified because the schema itself has no per-field documentation.

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 return-shape explanation is unnecessary, and the parameters — the real gap in the structured data — are fully covered. What remains missing is the relationship to sibling retrieval tools, which matters given twelve siblings that overlap in domain.

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 compensate entirely, and it does: each of the five parameters is explained, with the allowed values for phase, area, and category spelled out and example area tokens ('crm', 'safety-pv') provided. The default for limit is restated as a semantic meaning, not just a schema value.

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 concrete verb and resource: 'Search the Lumis knowledge base across the life sciences value chain.' The added note that foundation knowledge is always included helps an agent understand what a result set contains. It does not, however, explicitly contrast itself with specific-fetch siblings like get_country_rules or get_terminology.

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?

'Use phase and area to narrow scope' is the only usage guidance, and it addresses parameter tuning rather than tool selection. There is no statement of when to use this broad search versus the many targeted getters in the sibling list, forcing the agent to infer that choice.

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