Skip to main content
Glama
Sign In
MedOrqis MCP Server

MedOrqis MCP Server

by seotarek
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Regional Brand to INN Medical Terminology Normalizer

normalize_terminology
Read-onlyIdempotent

Maps regional pharmaceutical trade names to standardized INN, resolves primary drug classes, and retrieves WHO ATC codes for prescribing audits and formulary reconciliation.

Instructions

Maps regional pharmaceutical trade brand names to standardized International Nonproprietary Names (INN), resolves primary pharmacological drug classes, and retrieves WHO Anatomical Therapeutic Chemical (ATC) codes.

When to use:

  • Resolving commercial pharmaceutical trade brand names into canonical INN entities for prescribing audits, formulary reconciliation, or clinical reasoning.

When NOT to use:

  • Multi-drug interaction or pharmacological contraindication screening (use check_drug_interactions instead).

  • Clinical consultation emergency triage or red-flag evaluation (use check_red_flags instead).

  • Mathematical clinical risk score calculations (use calculate_clinical_score instead).

Parameter constraints & formats:

  • 'brand_name': Commercial trade name string with optional formulation or dosage strength. Evaluated clinically by:

    • Resolving active salt formulations (e.g. 'Bisoprolol fumarate' from 'Concor Cor', 'Amoxicillin-clavulanate' from 'Augmentin').

    • Stripping pharmaceutical dosage forms ('tablet', 'syrup', 'vial') and numeric metric strengths ('mg', 'mcg', 'IU').

    • Normalizing trade names across Egyptian (EDA), Saudi (SFDA), European (EMA), and US (FDA) regional pharmaceutical markets.

Behavioral guarantees & return states:

  • Non-LLM deterministic dictionary lookup: Grounded in offline curated WHO INN and ATC indices with zero external network calls, credentials, or rate limits.

  • Idempotent & non-destructive: Resolving the same brand name repeatedly returns identical mappings without modifying state.

  • Bounded response & error handling: Returns a single bounded JSON object without pagination; unrecognized brand names safely return matched=false and null entity fields without throwing uncaught exceptions.

Input Schema

NameRequiredDescriptionDefault
brand_nameYesCommercial pharmaceutical brand name (e.g. 'Concor', 'Augmentin', 'Voltaren', 'Plavix') to normalize.

Output Schema

NameRequiredDescriptionDefault
atc_codeYesAnatomical Therapeutic Chemical (ATC) classification code.
brand_nameYesOriginal brand name submitted for normalization.
drug_classYesPrimary pharmacological or therapeutic class (e.g. 'Beta-blocker', 'NSAID').
inn_generic_nameYesStandardized International Nonproprietary Name (INN), or null if unmatched.
regional_availabilityYesList of geographical markets where this brand name is actively distributed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.1.2
    • changedInput schema / properties / brand_name / description
      Previous value: -"Commercial pharmaceutical brand name to normalize (e.g., 'Concor', 'Augmentin', 'Plavix', 'Voltaren', 'Lantus')."New value: +"Commercial pharmaceutical brand name (e.g. 'Concor', 'Augmentin', 'Voltaren', 'Plavix') to normalize."
    • addedInput schema / properties / brand_name / examples
      Added value: +[
+  "Concor 5mg",
+  "Augmentin 1g",
+  "Voltaren 75"
+]
    • addedInput schema / properties / brand_name / maxLength
      Added value: +200
    • addedInput schema / properties / brand_name / minLength
      Added value: +1
    • changedOutput schema / properties / atc_code / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / properties / drug_class / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / properties / inn_generic_name / description
      Previous value: -"Standardized International Nonproprietary Name (INN)."New value: +"Standardized International Nonproprietary Name (INN), or null if unmatched."
    • changedOutput schema / properties / inn_generic_name / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • addedOutput schema / required
      Added value: +[
+  "brand_name",
+  "inn_generic_name",
+  "drug_class",
+  "atc_code",
+  "regional_availability"
+]
  2. Changed2 schema fields changedv0.1.1
    • addedInput schema / properties / brand_name / description
      Added value: +"Commercial pharmaceutical brand name to normalize (e.g., 'Concor', 'Augmentin', 'Plavix', 'Voltaren', 'Lantus')."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "description": "Standardized pharmacological entity payload including INN generic name, therapeutic class, ATC code, and regional market distribution.",
+  "properties": {
+    "atc_code": {
+      "description": "Anatomical Therapeutic Chemical (ATC) classification code.",
+      "type": "string"
+    },
+    "brand_name": {
+      "description": "Original brand name submitted for normalization.",
+      "type": "string"
+    },
+    "drug_class": {
+      "description": "Primary pharmacological or therapeutic class (e.g. 'Beta-blocker', 'NSAID').",
+      "type": "string"
+    },
+    "inn_generic_name": {
+      "description": "Standardized International Nonproprietary Name (INN).",
+      "type": "string"
+    },
+    "regional_availability": {
+      "description": "List of geographical markets where this brand name is actively distributed.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  3. First observedv0.1.0

TDQS

A4.3/5.0
Behavior3/5

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so determinism, safety and offline operation are known before reading the description. The genuinely additive content is the failure mode: unrecognized names return matched=false with null fields rather than throwing, and the lookup is a bounded dictionary rather than a network call with credentials or rate limits. However, the 'idempotent & non-destructive' bullet largely restates the annotations, and the quality of partial matches (e.g. ambiguous or unknown salts) is not clarified.

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?

The description is long but fully front-loaded and segmented into purpose, when-to-use, when-not-to-use, parameter formats, and guarantees, each with a clear header. Every bullet either routes the agent to a sibling, explains name parsing, or discloses failure behavior; the only near-redundancy is the idempotency guarantee already in annotations.

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 single-parameter, read-only lookup tool this covers everything an agent needs: what it maps, which markets it covers, how messy input is parsed, and what an unmatched result looks like. An output schema exists, so the description is not obligated to document the returned entity fields, and it appropriately stops at stating the shape (single bounded JSON object, no pagination).

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 description coverage is 100% and the single parameter already carries a description plus three examples, so the baseline is 3. The description does add real meaning beyond the schema by spelling out the normalization pipeline: resolving salt formulations ('Concor Cor' -> Bisoprolol fumarate), stripping dosage forms and metric strengths, and accepting EDA/SFDA/EMA/FDA regional trade names. The 200-character cap and the behavior for non-pharmaceutical input remain undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names three specific operations on a specific resource: brand-to-INN mapping, drug class resolution, and ATC code retrieval. It is immediately distinguishable from siblings like check_drug_interactions or calculate_clinical_score, which are explicitly named as out of scope.

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

Usage Guidelines5/5

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

There is an explicit 'When to use' block with concrete scenarios (prescribing audits, formulary reconciliation) and a 'When NOT to use' block naming three sibling tools and the exact conditions that select them. Nothing about tool selection is left to inference.

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