Research 7,400+ US doctors: search, semantic search, profiles, reviews & procedure pricing.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 9 of 9 tools scored.
Most tools have distinct purposes, but fetch and get_doctor both retrieve doctor profiles with different detail levels, and search and search_doctors overlap in search functionality. Descriptions help differentiate but some ambiguity remains.
Tool names mostly use snake_case, but the pattern is inconsistent: some start with 'get_', 'list_', 'search_', while 'fetch' stands out without a prefix. Mix of verbs and styles reduces predictability.
9 tools is well-scoped for a doctor directory server, covering search in multiple modes, profile retrieval, reviews, costs, and location/procedure listing. Each tool earns its place.
Core information retrieval functions are present: multiple search methods, detailed profiles, reviews, cost data, and location/procedure catalogs. Minor gaps like direct ID-based retrieval overlapping with slug-based are acceptable.
fetchFetch document (connector-compatible)ARetrieve a full doctor profile by id (the slug returned from search). Returns {id, title, text, url, metadata}. (OpenAI connector-compatible.)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Doctor slug returned by the search tool. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds no behavioral traits beyond output format and compatibility. Minimal additional value.
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?
Two sentences, no redundancy. Efficiently communicates purpose, input, output, and compatibility.
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 simple fetch tool with one parameter and no output schema, the description covers input source, return fields, and compatibility. Complete and self-contained.
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 description coverage is 100% and the parameter is simple. Description reiterates the schema's guidance but adds no new meaning beyond reinforcement.
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 uses specific verb 'retrieve' and resource 'full doctor profile by id', clarifying the id is a slug from search. It distinguishes itself from siblings by specifying the return format and connector compatibility.
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?
Clearly states input must come from 'search' tool, implying usage after search. However, no explicit when-not or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_local_specialistsCurated 'best {procedure} doctors in {city}' guideAReturn NavMDs' curated city guide for a procedure: the ranked specialists (the city's OWN doctors first, then the nearest within an adaptive radius), the typical local price range, the average rating, the share offering free consultations, and the canonical navmds.com page URL to cite. This is the best tool for 'who are the best doctors in ' questions — it mirrors NavMDs' editorial city pages. If no curated guide exists for that city+procedure, it says so; fall back to search_doctors with a nearby larger city.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name, e.g. 'Beverly Hills', 'Miami'. | |
| state | Yes | US state name, e.g. 'California', 'Florida'. | |
| procedure | Yes | Procedure/specialty, e.g. 'rhinoplasty', 'breast augmentation', 'botox'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context beyond annotations: it explains the ranking logic (city's own doctors first, then nearest within adaptive radius) and the fallback behavior. No contradictions with annotations.
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?
The description is a single paragraph that efficiently communicates the tool's value, output, use case, and fallback. While slightly verbose, every sentence adds necessary information. Structure is front-loaded with the key purpose.
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?
Despite no output schema, the description details the specific elements returned (ranked specialists, price range, rating, free consultation share, page URL). Combined with robust annotations and high schema coverage, the description provides sufficient context for an agent to understand the tool's functionality and make a correct invocation.
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?
The input schema provides 100% coverage with clear descriptions for all three parameters (city, state, procedure). The description links these parameters to the curated guide concept, adding value by explaining how they determine the guide's scope. This goes beyond the schema's basic field descriptions.
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 clearly states the tool returns 'NavMDs' curated city guide for a procedure' and enumerates specific outputs (ranked specialists, price range, rating, etc.). It distinguishes from siblings like search_doctors by specifying it mirrors editorial city pages.
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?
Explicitly states this tool is 'best for' 'who are the best <procedure> doctors in <city>' questions and provides a clear fallback: 'fall back to search_doctors with a nearby larger city'. This gives the agent clear guidance on when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_community_threadGet a full community discussionAFetch a complete NavMDs community thread by id (the id returned by search_community, or the trailing number of a community.navmds.com/t// URL) — the original question plus every reply, in order. Use after search_community when you need the actual answers rather than an excerpt. Community posts are patient discussion, not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community topic id, e.g. 117. | |
| limit | No | Max posts to return (default 30). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds behavioral context: it returns the original question and all replies in order, and explains the id format (from search_community or URL trailing number). This goes beyond annotations without contradicting them.
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?
The description is two sentences, no wasted words. It efficiently conveys the purpose, usage context, and a caveat. Each sentence adds value.
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 simple retrieval tool with two well-documented parameters, the description adequately covers what it does, when to use it, what it returns (question + replies), and a disclaimer. No output schema is provided, but the return structure is described clearly enough.
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%, but the description adds significant meaning for the 'id' parameter by explaining its source (search_community result or URL trailing number). For 'limit', the schema already describes it as 'Max posts to return (default 30)', and the description doesn't add much. Overall, the description enhances understanding of the key parameter.
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 clearly states the action ('Fetch'), the resource ('a complete NavMDs community thread'), and specifies it includes the original question plus every reply in order. It also distinguishes from sibling tools like search_community by mentioning excerpts.
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 explicitly says 'Use after search_community when you need the actual answers rather than an excerpt', providing clear when-to-use guidance. It also notes that community posts are patient discussion, not medical advice, implying caution, but does not explicitly list when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_doctorGet full doctor profileAFetch a doctor's complete NavMDs profile by slug (the id returned by the search tools, or the last path segment of a navmds.com/doctor/ URL). Returns specialty, locations, ratings, overview, procedures, pricing, consultation fee, FAQ and verification status.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Doctor slug, e.g. 'dr-jane-smith-md'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds context about the return content (specialty, ratings, etc.) and explains the slug format, which aids behavioral understanding beyond the annotations.
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?
Two sentences cover purpose, input source, and output contents. Every word earns its place; no redundancy.
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 simple tool with one parameter and no output schema, the description sufficiently covers what the tool does and returns. It could mention that it returns a single object or note pagination, but it is adequate given the sibling tools exist for more specific data.
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?
The only parameter 'slug' is described in the schema with an example. The description enriches it by explaining its source (search tools or URL), adding significant practical value. Schema coverage is 100%, so a baseline of 3 is increased.
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 specifies the exact action ('Fetch'), the resource ('a doctor's complete NavMDs profile'), and the identifier ('slug'). It distinguishes from sibling tools by clarifying the slug's origin, making the purpose unmistakable.
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 implies this tool is for the full profile, but does not explicitly guide when to use this versus more specific siblings like get_doctor_reviews or get_procedure_costs. An agent must infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_doctor_reviewsGet patient reviews for a doctorAReturn published (moderation-approved) patient reviews for a doctor by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Doctor slug. | |
| limit | No | Max reviews (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds value by specifying that results are only 'moderation-approved,' which is behavioral context beyond annotations. No contradictions.
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?
Single sentence, no wasted words. Front-loaded with the core action and result scope.
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?
Given low complexity and full schema coverage, the description sufficiently explains the tool's purpose and the moderation filter. No output schema exists, but the description does not need to detail return values. It could add pagination info, but not essential.
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 describes both parameters (slug and limit). The description adds no new parameter meaning beyond what is in the schema ('by slug' is redundant).
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 clearly states the tool returns published, moderation-approved patient reviews for a doctor by slug. The verb 'return' and resource 'reviews' are specific, and it distinguishes itself from sibling tools like get_doctor or search_doctors.
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 does not provide guidance on when to use this tool versus alternatives like get_doctor or search_community. No explicit context for usage or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_procedure_costsGet pricing for a procedureAAggregate what a procedure costs across NavMDs doctors — combining patient-reported costs and practice-website pricing. Optionally narrow to a state/city. Returns min/median/max/average plus sample practice quotes.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City filter. | |
| state | No | US state filter. | |
| procedure | Yes | Procedure name, e.g. 'rhinoplasty'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint; the description complements this by specifying data sources (patient-reported and practice-website) and output, without contradictions.
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?
Two concise sentences with no filler, front-loading the core action and key features.
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?
Despite no output schema, the description covers inputs, optional filters, and output statistics sufficiently for a read-only aggregate tool.
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% with brief descriptions; the tool description adds value by clarifying the optional nature of city/state, specifying 'procedure name, e.g. rhinoplasty', and stating the output aggregates.
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 clearly states the verb 'aggregate' and the resource 'procedure costs', details the data sources, and distinguishes from sibling tools like 'search_doctors' by focusing on pricing aggregation.
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 explains optional narrowing by state/city and the output statistics, but does not explicitly mention when to avoid this tool or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_locationsList covered locationsAList states/cities where NavMDs has doctors, with doctor counts. Useful for grounding a location filter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max locations (default 150, ordered by doctor count). | |
| state | No | Filter to a single state name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds transparency about the data returned (states/cities with doctor counts), providing context beyond the annotations without contradiction.
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?
Two sentences, direct and front-loaded with the action. No extraneous words; every sentence adds value.
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 simple list tool with two optional parameters and no output schema, the description sufficiently specifies the return content and purpose. It could be improved by detailing the output structure (e.g., whether city-level or state-level), but it's adequate.
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% with clear descriptions for both parameters (limit, state). The tool description adds no additional parameter semantics, so baseline 3 is appropriate.
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 clearly states 'List states/cities where NavMDs has doctors, with doctor counts,' which specifies the verb (list) and resource (covered locations with counts). It distinguishes from siblings like list_procedures as the only location-listing tool.
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 includes 'Useful for grounding a location filter,' implying usage context. While it does not explicitly state when not to use or mention alternatives, the sibling list makes it clear this is the intended tool for location filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_proceduresList available proceduresAList the procedures/specialties covered by NavMDs, with the number of doctors for each. Useful for grounding a search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max procedures (default 100, ordered by doctor count). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the tool returns doctor counts, which is useful but not critical. It does not elaborate on the open-world nature or any behavioral quirks beyond what annotations provide.
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?
The description is two sentences, concise and front-loaded. The first sentence states the core functionality, and the second adds context. No unnecessary words.
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?
Given no output schema, the description adequately mentions that the tool returns procedures/specialties and doctor counts. It is complete for a simple list tool, though additional details about response fields or ordering could be helpful but are not essential.
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% with a well-described 'limit' parameter. The description does not add information about the parameter beyond the schema, so it meets the baseline for high coverage without adding extra value.
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 clearly states the tool lists procedures/specialties with doctor counts, using a specific verb and resource. It distinguishes itself from sibling tools like fetch and search by specifying that it provides a summary with doctor counts, useful for grounding searches.
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 mentions the tool is 'useful for grounding a search', providing a general context. However, it does not explicitly state when to use this tool versus alternatives like search_doctors or find_local_specialists, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch (connector-compatible)ASearch NavMDs doctors by free-text query. Returns a list of {id, title, url} results. Pass an id to the fetch tool to retrieve the full profile. (OpenAI connector-compatible.)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text search query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that results are a list with specific fields and mentions connector compatibility, but it does not disclose any additional behavioral traits such as pagination, result limits, or rate limiting. The description adds modest value beyond annotations.
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?
The description is two sentences: first states purpose and output format, second provides actionable guidance and compatibility note. Every sentence adds value with no waste. Perfectly front-loaded and concise.
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 simple tool with one parameter, no output schema, and annotations covering read-only and open-world, the description is fairly complete. It specifies return fields and links to 'fetch'. However, it lacks details on result limits or pagination, and the open-world hint is not elaborated. Slight gaps prevent a 5.
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% with the single 'query' parameter described as 'Free-text search query.' The description adds 'free-text query' which is synonymous. No additional semantics or format details are provided. Baseline 3 is appropriate for high coverage.
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 clearly states the verb 'Search', the resource 'NavMDs doctors', and the method 'free-text query'. It also specifies the return format and suggests using the 'fetch' tool for full profiles, which differentiates it from 'fetch'. However, it does not explicitly distinguish itself from sibling tools like 'search_doctors' or 'semantic_search_doctors', leaving potential confusion.
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 provides guidance to use 'fetch' for detailed profiles after searching, but it does not explain when to use this tool over alternatives like 'search_doctors' or 'semantic_search_doctors'. There are no explicit when-not-to-use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_communitySearch NavMDs community discussionsASearch patient discussion threads on community.navmds.com — the NavMDs forum where people discuss recovery timelines, what procedures actually cost them, choosing a surgeon, and what to expect. Use this for lived-experience questions ('what is rhinoplasty recovery like', 'how much did people actually pay for a tummy tuck', 'how do I pick a surgeon') where the doctor-directory tools can't help. Returns thread titles, categories, excerpts and canonical URLs; pass an id to get_community_thread for the full discussion. Community posts are patient discussion, not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max threads (default 10). | |
| query | Yes | Free-text search, e.g. 'rhinoplasty recovery swelling' or 'tummy tuck cost'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds return format (titles, categories, excerpts, URLs) and a disclaimer that posts are patient discussion, not medical advice. Could mention rate limits or empty result behavior, but still good.
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?
Front-loaded with the core action, then use cases, return info, and disclaimer. All sentences are informative with no redundancy.
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 simple tool with 2 parameters and no output schema, the description covers purpose, input expectations, output shape, and even provides alternatives. It is complete enough for an agent to use 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 baseline is 3. Description adds value with examples of free-text queries and context for the limit parameter. This supplemental information justifies a 4.
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 clearly states the tool searches patient discussion threads on a specific forum (community.navmds.com). It distinguishes itself from doctor-directory siblings by specifying it's for lived-experience questions.
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?
Explicitly tells when to use (lived-experience questions) and when not (where doctor-directory tools can't help). Also references the sibling tool get_community_thread for full discussions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_doctorsSearch doctors by procedure & locationAFind doctors by procedure/specialty, optionally filtered by US state and city. Uses NavMDs' pre-computed search index (fast, ranked by rating + review volume). Use this when you have a concrete procedure (e.g. 'rhinoplasty', 'botox', 'tummy tuck'). For open-ended natural-language queries, use semantic_search_doctors instead.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name, e.g. 'Miami'. | |
| limit | No | Max results (default 20). | |
| state | No | US state name, e.g. 'California' or 'Florida'. | |
| procedure | Yes | Procedure or specialty, e.g. 'rhinoplasty', 'breast augmentation', 'botox'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds valuable behavioral context: it uses a pre-computed index, is fast, and results are ranked by rating and review volume. No contradictions.
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?
Two efficient sentences plus a usage note. No wasted words; main action is front-loaded. Highly concise and structured.
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?
Given 4 parameters, good annotations, and no output schema, the description explains the search mechanism and ranking. It could mention the default limit (20) or pagination, but overall adequately complete for agent use.
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 description coverage is 100%, so baseline is 3. The description restates parameters (procedure, city, state, limit) but adds no new semantic detail beyond highlighting optional filtering.
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 clearly states it finds doctors by procedure/specialty and optionally filters by US state and city. It specifies the use of NavMDs' pre-computed search index and ranking by rating + review volume, distinguishing it from semantic_search_doctors.
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?
Explicitly tells when to use this tool ('concrete procedure') and when to use semantic_search_doctors instead ('open-ended natural-language queries'), providing clear guidance vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
semantic_search_doctorsNatural-language doctor searchASearch NavMDs' 7,400+ doctor directory with a natural-language query, e.g. 'board-certified facelift surgeon in Los Angeles with great reviews and free consults'. Powered by Gemini embeddings + cosine similarity over full doctor profiles. Best tool for open-ended or multi-attribute questions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 15). | |
| query | Yes | Natural-language description of the doctor you're looking for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. Description adds meaningful context: 'Powered by Gemini embeddings + cosine similarity over full doctor profiles', explaining the search mechanism and scope. No contradictions with annotations.
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?
Only two sentences: first states purpose with an illustrative example, second explains the technology and optimal use case. No filler or redundancy.
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 search tool with simple parameters and no output schema, the description covers purpose, technology, usage guidance, and parameter hints. The annotations and sibling context are also available. The description is complete for an agent to decide when and how to invoke this tool.
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 baseline is 3. The description provides an example query (e.g., 'board-certified facelift surgeon in Los Angeles with great reviews and free consults') that clarifies the natural-language style, adding value beyond the schema description.
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?
States 'Search NavMDs' 7,400+ doctor directory with a natural-language query' – clear verb+resource. Cites example and explicitly distinguishes from siblings by calling it 'Best tool for open-ended or multi-attribute questions'.
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?
Begins with general purpose, then says 'Best tool for open-ended or multi-attribute questions' – provides context for when to use. Does not explicitly state when not to use or mention alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
