Root Data Public Directory
Server Details
Public Root Data dental analytics directory for DSOs, dental practices, blog, and FAQ tools.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3.4/5 across 8 of 8 tools scored. Lowest: 2.4/5.
Each tool has a clearly distinct purpose: compare two DSOs, get a single DSO, get a practice, list top DSOs, answer FAQs, search blogs, search DSOs, search practices. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., compare_dsos, get_dso_profile, search_practices). No deviations or mixed conventions.
With 8 tools, the set is well-scoped for the server's purpose of providing public directory data, search, FAQ, and blog access. Not too few or too many.
The tool surface covers all necessary querying operations for the domain: retrieval by slug, comparison, listing with ranking, search with filters, and informational FAQ/blog. No obvious gaps for a read-only public directory server.
Available Tools
8 toolscompare_dsosCompare DSOsBInspect
Compare two Root Data public DSO directory profiles by slug using public profile summaries, regions, websites, and public signal counts.
| Name | Required | Description | Default |
|---|---|---|---|
| dso_slug1 | Yes | ||
| dso_slug2 | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention idempotency, side effects, rate limits, error behavior, or authorization. It only hints at the return content but no behavioral context.
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 sentence of 15 words with no fluff. It is front-loaded with the verb and directly states the 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?
The tool has two simple string parameters and no output schema. The description mentions what is compared but lacks details on output format, error cases, and prerequisites. It is minimally complete but has gaps.
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 0%, so the description must add meaning. It mentions 'by slug' but does not explain what a slug is, its format, or how to obtain valid slugs. The description adds minimal value beyond the parameter names.
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 (compare), the resource (two DSO directory profiles by slug), and specifies what is compared (profile summaries, regions, websites, public signal counts). It distinguishes from siblings like get_dso_profile, which returns a single profile, and search_dsos, which 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 implies the tool is for comparing two specific profiles, but it does not explicitly state when to use it versus alternatives like calling get_dso_profile twice. No guidance on required prerequisites or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dso_profileGet DSO ProfileAInspect
Get one public Root Data DSO directory profile by slug. Returns public website, region, profile URL, summary, and public signals.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions returns are public and lists fields, but lacks details on authentication, error handling (e.g., missing slug), rate limits, or idempotency. It adds some context beyond schema but not comprehensive.
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 sentence of 21 words, concise and front-loaded. It communicates the core purpose efficiently, though it could be slightly more 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?
For a simple retrieval tool, the description covers the returned fields. However, it lacks output schema, error behavior, and usage context among 8 sibling tools. It is adequate but not fully complete.
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 has 0% description coverage for the single parameter 'slug'. The description only says 'by slug' without explaining what a slug is, its format, or how to obtain it. The description fails to compensate for the missing parameter documentation.
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 retrieves a specific DSO profile by slug and lists the returned fields (website, region, profile URL, summary, signals). It uses a specific verb and resource, and the verb 'Get' combined with 'by slug' differentiates it from sibling tools like search_dsos.
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 usage when a slug is known, but it does not explicitly compare to siblings or state when to use this tool instead of search_dsos or compare_dsos. No guidance on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_practice_profileGet Practice ProfileAInspect
Get one published public dental practice directory profile by slug. Returns public website, locations, services, rating summary, and profile URL.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions returned data but lacks details on side effects, error handling, rate limits, or auth. Incomplete behavioral disclosure.
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, front-loaded with purpose and return fields. No filler.
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?
Simple tool with 1 param, no output schema; description covers basic purpose and returns. Lacks error scenarios and cross-tool context given 7 siblings.
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 has 0% description coverage; description explains slug identifies profile but adds no format or example. Adequate but does not fully compensate for missing schema 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?
Description clearly states it gets one published public dental practice directory profile by slug, listing return fields. Distinguishes from siblings like search_practices.
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?
Implies use when slug is known, but no explicit guidance on when to use vs. alternatives or when not to use. Sibling tool search_practices exists for broader search but not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_top_dsosList Top DSOsAInspect
List public DSO directory profiles ranked by public size, locations, or growth signals inferred from public profile text. Results are directional, not a private operating benchmark.
| Name | Required | Description | Default |
|---|---|---|---|
| by | Yes | ||
| limit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that rankings are based on public data and are directional, but does not mention data freshness, authentication needs, or limitations of the inference method. This provides basic transparency but leaves gaps.
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 wasted words. Information is front-loaded and easy to parse.
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 should clarify return format (e.g., list of profiles with what fields). It mentions ranked profiles but not the structure. This lack of detail reduces completeness, though the tool is relatively simple.
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 has 2 parameters (by, limit) with 0% description coverage. The description explains the 'by' enum (size, locations, growth) but does not mention 'limit' at all. This adds partial meaning but fails to cover the second 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?
Description clearly states the tool lists DSO directory profiles ranked by specific criteria (size, locations, growth) from public data. This distinguishes it from siblings like search_dsos (search) and compare_dsos (compare).
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 indicates results are directional and not a private benchmark, implying use for rough estimates. However, it does not explicitly state when to prefer this tool over alternatives like search_dsos or compare_dsos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
root_data_faqRoot Data FAQCInspect
Answer common public questions about Root Data services, DSO directories, dental practice benchmarks, AI Coach, integrations, privacy, demos, and pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It states the tool answers questions but does not explain how it retrieves answers (static list, AI-generated, etc.), output format, or any limitations. Behavior is opaque.
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?
Description is a single sentence, making it concise, but it lacks structure or prioritization of key information. It front-loads topics but does not separate purpose from usage details.
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 and no annotations, the description fails to convey return format, behavior for empty queries, or how the FAQ is structured. Incomplete for making an informed tool selection.
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 0%, but description does not explain the parameters at all. No mention of what 'query' should contain or how 'limit' affects results. The agent has no guidance on how to construct valid inputs.
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?
Description clearly states tool answers common public questions about Root Data services, DSO directories, and related topics. This distinguishes it from sibling tools that focus on profiles and comparisons, but it could be more specific about what kind of answers it provides.
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?
No guidance on when to use this tool versus alternatives. Missing context on scope (e.g., is it only for public questions? what about private questions?) and no mention of 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.
search_blog_articlesSearch Blog ArticlesAInspect
Search published Root Data blog articles by title, slug, excerpt, category, tag, or SEO summary. Supports DSO-only, practice-only, both-audience, or all articles.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| audience | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Search published' implying read-only, but lacks additional behavioral context such as rate limits, authentication, or pagination. It is not misleading but minimal.
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 long with no wasted words. It front-loads the core action ('Search published Root Data blog articles') and immediately provides searchable fields and filter options.
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?
The tool is simple with three parameters and no output schema. The description covers the basic purpose and audience filtering but omits details on 'query' and 'limit' parameters. It is adequate but not thorough for a tool with no annotations.
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 0%, so the description must compensate. It only adds meaning for the 'audience' parameter (enum values). It does not explain what 'query' searches across (though implied by fields like title, slug) or the 'limit' parameter. Two of three parameters lack explanation.
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 searches published blog articles by title, slug, excerpt, category, tag, or SEO summary, and specifies audience filtering. This distinguishes it clearly from sibling tools like search_dsos or get_dso_profile.
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 communicates the purpose and audience filter options effectively. While it doesn't explicitly state when not to use it, the sibling tool list makes it clear that this is for blog search, and alternatives are distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_dsosSearch DSOsBInspect
Search Root Data's public DSO directory by organization name, slug, website, summary, or public website signals. Returns public directory data only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It states it returns public data only, but fails to disclose whether the search is case-sensitive, supports wildcards, or how results are ordered. It also does not mention pagination, rate limits, or authentication requirements, leaving critical traits unspecified.
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 long with no redundant words. The first sentence conveys the core action and scope, and the second sentence clarifies a key constraint (public data). It is front-loaded and efficient.
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 two parameters, no output schema, and no annotations, the description is adequately complete for a simple search tool. It specifies search fields and scope, but lacks details about the limit parameter's effect, return format, and potential error states. These gaps prevent the description from being fully 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?
The schema has 0% description coverage, so the description must compensate. It explains that the 'query' parameter can be an organization name, slug, etc., providing limited semantic context. However, the 'limit' parameter is not explained (function, behavior), and the description does not clarify the exact search behavior (e.g., partial match).
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 specifies a search action over Root Data's public DSO directory and lists the fields by which search is possible (name, slug, website, summary, public website signals). It effectively distinguishes the tool from siblings like get_dso_profile (single DSO retrieval) and list_top_dsos (top listings).
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 no explicit guidance on when to use this tool versus alternatives. It does not mention that get_dso_profile is for specific DSO details or that list_top_dsos is for rankings. The only hint is 'Returns public directory data only,' which implicitly excludes private data but does not direct the agent to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_practicesSearch Dental PracticesAInspect
Search Root Data's public dental practice directory. Supports query, service, location, city, state, minimum Google reviews, minimum star rating, and sorting by Google review count or rating. Returns published public listings only. All parameters are optional.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No | ||
| query | No | ||
| stars | No | ||
| state | No | ||
| sortBy | No | ||
| reviews | No | ||
| service | No | ||
| location | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only notes that results are limited to published public listings, but does not disclose read-only nature, authorization needs, rate limits, or pagination behavior.
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 extremely concise with two sentences that efficiently state the tool's purpose and capabilities without 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?
While it covers core functionality and parameter list, it omits return structure, pagination behavior, default sorting, and interpretation of the 'location' parameter, especially given no output schema.
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 description lists several parameters (query, service, location, city, state, reviews, stars, sortBy), partially compensating for zero schema descriptions, but does not explain parameter formats or constraints like what 'location' expects or the meaning of sortBy enum values.
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 'Root Data's public dental practice directory' and lists supported filters, making it distinct from sibling tools like 'search_dsos' or 'get_practice_profile'.
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 a clear use case (searching public dental practices) but does not explicitly state when not to use it or mention alternative tools for more specific tasks like getting a single practice profile.
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.
Discussions
No comments yet. Be the first to start the discussion!