Skip to main content
Glama
Lead Routing MCP Server

Lead Routing MCP Server

by meerkatsai

preview_route_with_country_hint

Read-onlyIdempotent

Preview a lead’s route using a country code inferred from notes when the country is missing; validates the hint, runs normal policy, and flags the result for human review without writing data.

Instructions

Preview a route for a lead whose country is missing, using a country you inferred from its notes.

country_code must be a two-letter code; evidence must quote the text that supports it. The hint is validated, the normal policy runs on it, and the result is always marked for human review. Does not write anywhere.

Input Schema

NameRequiredDescriptionDefault
lead_idYes
evidenceYes
country_codeYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description adds real value by disclosing that the hint is validated, normal policy runs on it, and results are always marked for human review. The 'does not write anywhere' line is redundant with annotations but harmless.

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?

Front-loads the purpose, then gives the two constraint sentences, then the safety note. No wasted sentences; every line adds information.

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 values needn't be explained, and the description covers usage scope, param constraints, and validation/review behavior. Only lead_id's role is left implicit, a minor gap.

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

Parameters4/5

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

With 0% schema description coverage, the description must carry the burden, and it does for the two non-obvious params: country_code must be a two-letter code and evidence must quote the supporting text. lead_id is left implied as the target lead, kept from a 5.

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?

States a specific verb (preview), resource (route), and the discriminating condition (a lead whose country is missing, using an inferred country hint). This clearly separates it from the sibling preview_route, which presumably assumes a known country.

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

Usage Guidelines4/5

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

Explicitly scopes usage to leads with a missing country, implying preview_route handles the normal case. It does not name the alternative tool outright or state when-not to use it, so it stops short of a full routing directive.

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