Search the mechoulam.de cannabis-medicine evidence register by free text (indication, condition, drug, study title, author). Returns indications and reviewed studies with citable URLs. Answer language follows the language of the query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description does not contradict them. It adds useful behavioral context beyond the schema: the result includes citable URLs and that the answer language follows the query language, which is non-obvious and relevant for invocation.
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?
Three sentences with no filler. The core purpose and scope are front-loaded, followed by return contents and a language behavior note. Every sentence 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 single-parameter read-only search tool with an output schema and clear annotations, the description covers what the tool searches, what it returns, and a language-specific behavior. Nothing critical is missing for an agent to invoke it correctly.
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 coverage is 100%, so the schema already documents the single query parameter. The description adds meaning by specifying what kinds of free text are valid (indication, condition, drug, study title, author), which is valuable beyond the bare 'Search query' schema text.
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 names a specific verb ('Search'), a specific resource (the mechoulam.de cannabis-medicine evidence register), and enumerates the searchable fields (indication, condition, drug, study title, author). It also states what it returns, clearly distinguishing it from the more targeted sibling tools get_indication, get_study, fetch, and list_indications.
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 clearly implies this is the free-text search entry point across the register, which sets expectations for when to use it versus direct lookup or listing tools. It does not explicitly name alternatives or exclusion conditions, but the 'by free text' qualifier gives enough context for an agent to route correctly.
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.
Search and list_indications are clearly distinct, but fetch overlaps with get_indication and get_study since it also retrieves a full record by ID. The descriptions help somewhat, but an agent could reasonably struggle to choose between the generic fetch and the more specific getters.
list_indications, get_indication, and get_study follow a consistent verb_noun pattern, but search and fetch are one-word verbs that break the convention. The mix is readable but not fully predictable.
Five tools is a well-scoped surface for a read-only evidence register. Each tool covers a necessary part of discovery and retrieval without unnecessary bloat.
The register's core workflow is covered: search across records, list indications, and retrieve detailed indication summaries or individual studies. A minor gap is the lack of an explicit list-studies endpoint, but search and fetch can fill that need in most cases.
