Default Privacy
Server Details
Search vetted privacy tools, read guides & glossary, and run free privacy diagnostics.
- 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 4.1/5 across 11 of 11 tools scored.
Each tool targets a distinct resource and action: domain checks (breaches, email security, password pwned, WHOIS privacy), CRUD-like operations on glossary/guides/tools (search vs get), and listing categories. No two tools have overlapping purposes.
All tools follow a consistent dp_verb_noun pattern in snake_case (e.g., dp_check_domain_breaches, dp_get_glossary_term, dp_list_categories). Verbs are clear (check, get, list, search) and nouns are descriptive.
With 11 tools, the server is well-scoped: four privacy check operations, three 'get' tools for full content, three 'search' tools for listing, and one categorization tool. This covers the domain without excess.
The tool set covers the full lifecycle of the privacy domain: checking domain-related privacy issues (breaches, email security, password, WHOIS), exploring the glossary and guides, and searching/referencing tools. No obvious gaps are present.
Available Tools
11 toolsdp_check_domain_breachesCheck domain data breachesARead-onlyInspect
Check whether a domain appears in known public data breaches (via the Have I Been Pwned breach catalog). Returns matching breaches with dates, exposed data classes, and account counts. Domain-level only — no personal email is queried.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. 'example.com'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and external dependency (readOnlyHint, openWorldHint). Description adds value by naming the external source (Have I Been Pwned) and specifying returned data, but does not go beyond what annotations imply for safety.
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; first sentence states action and source, second clarifies scope. Every sentence adds value, 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, single-parameter tool with good annotations and clear purpose, the description is complete: it specifies input, output content, source, and exclusions. No output schema needed given clarity.
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 100% coverage with one parameter 'domain' described as 'Domain to check, e.g. 'example.com'.' Description adds a minimal example but no deeper semantics beyond schema.
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?
Clearly states the tool checks if a domain appears in known public data breaches via Have I Been Pwned, lists what data is returned (breaches, dates, data classes, account counts), and distinguishes from sibling tools by emphasizing domain-level only.
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 says 'domain-level only — no personal email is queried,' clarifying scope and providing a key exclusion. Does not explicitly name sibling alternatives, but context differentiates from email/password checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dp_check_email_securityCheck email security (SPF/DKIM/DMARC)ARead-onlyInspect
Check a domain's email authentication posture — SPF, DKIM, and DMARC DNS records — and return an A–F grade with explanations. Read-only DNS lookups; no email is sent or stored.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. 'example.com'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that it performs DNS lookups, sends no email, and returns an A-F grade with explanations. This goes beyond annotations and provides useful 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?
Two sentences, front-loaded with purpose, no redundant information. 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?
Given the tool's simplicity (one parameter, no output schema), the description covers the essential information: what it checks, what it returns, and its read-only nature. It is complete for an agent to decide to invoke it.
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 describes 'domain' with an example. Description doesn't add further meaning beyond what the schema provides. With 100% schema coverage, 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 it checks SPF, DKIM, and DMARC DNS records and returns an A-F grade. It distinguishes from siblings like dp_check_domain_breaches or dp_search_tools. Specific verb+resource with clear scope.
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?
It specifies the tool is for checking email authentication posture and that it's read-only, implicitly indicating when to use it. However, it does not explicitly state when not to use it or contrast with alternatives. Sibling tools are very different, so confusion is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dp_check_password_pwnedCheck if a password is breachedARead-onlyInspect
Check whether a password has appeared in known breaches using HIBP k-anonymity. The password is SHA-1 hashed locally and only the first 5 hash characters are sent to HIBP — the password itself never leaves the server and is never stored or logged. Returns whether it was found and how many times.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | Password to check. Handled via k-anonymity; never transmitted in full or stored. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral details: the password is SHA-1 hashed locally, only the first 5 hash chars are sent, and the password never leaves the server or is stored/logged. This goes beyond annotations but doesn't cover all potential behaviors (e.g., error handling).
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 filler. The purpose is front-loaded, and every sentence provides essential information about what the tool does, how it works securely, and what it returns.
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 is complete: it explains the action, security mechanism, and return value (found and count). No gaps for typical 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 coverage is 100%, and the schema already describes the password as handled via k-anonymity. The description adds context about SHA-1 hashing and the 5-character truncation, but these are minor beyond the schema. 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 the verb 'check' and the resource 'password', specifying it checks against known breaches using HIBP k-anonymity. This effectively distinguishes it from sibling tools like dp_check_domain_breaches and dp_check_email_security.
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 for securely checking password breaches but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. Context from sibling names suggests differentiation, but the description lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dp_check_whois_privacyCheck WHOIS / domain privacyARead-onlyInspect
Look up a domain's public WHOIS/RDAP registration record and flag exposed personal identity fields (registrant name, email, phone, address). Read-only RDAP lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. 'example.com'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by specifying that it flags exposed personal identity fields, which is additional behavioral context 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 concise sentences. The first sentence front-loads the primary action and outcome; the second reinforces the read-only nature. No wasted 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?
The description explains what the tool does and that it flags exposed fields, but it lacks any indication of the output format or structure. Given no output schema, this omission makes the description less complete for an agent.
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% and the single parameter 'domain' has a clear description. The tool description mentions 'domain' in context, adding no new meaning beyond the schema. 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 specifies the action ('Look up a domain's public WHOIS/RDAP registration record and flag exposed personal identity fields'), the resource (domain), and the scope (registrant name, email, phone, address). This clearly distinguishes it from sibling tools like dp_check_domain_breaches or dp_check_email_security.
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 states it is a 'Read-only RDAP lookup' and implies use for checking privacy exposure. However, it does not explicitly state when not to use or list alternative tools for related checks, though sibling tool names offer implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dp_get_glossary_termGet one glossary termARead-onlyInspect
Fetch a single glossary term's full definition and content by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Glossary term slug, e.g. 'end-to-end-encryption'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description's 'fetch' aligns with that. However, the description adds no additional behavioral context beyond what annotations already provide, such as what the response contains or any side effects.
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, concise sentence that is front-loaded with the key verb and resource. 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 the tool's simplicity (one param, no output schema), the description is adequate but minimal. It lacks details about the return format or error conditions, which could help an agent better understand the tool's behavior.
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 clear parameter description. The tool description only repeats 'by slug', adding no new meaning beyond the schema.
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), resource (glossary term), and identifier (slug). It is specific and distinguishes from sibling 'dp_search_glossary' which searches multiple terms.
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 the slug is known, but it does not explicitly state when to use this tool versus alternatives like dp_search_glossary. No prerequisites or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dp_get_guideGet one guideARead-onlyInspect
Fetch a single guide's full markdown content and metadata by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Guide slug, e.g. 'anonymous-llc-wyoming'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds that it returns full markdown content and metadata, providing some context beyond annotations but not rich behavioral details like auth or rate limits. No 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?
The description is a single, front-loaded sentence of 12 words with no unnecessary words. Every part 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 simple fetch tool with one parameter, read-only annotations, and no output schema, the description completely covers what it does, the input, and the output.
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%, with the parameter 'slug' already described with an example. The tool description only says 'by slug', adding no new meaning beyond the schema.
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 (fetch), resource (single guide), what is returned (full markdown content and metadata), and the identifier (slug). It distinguishes from sibling tools like dp_search_guides and dp_get_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 implies usage when you need a specific guide's full content by slug, but does not explicitly state when to use this tool versus alternatives like dp_search_guides. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dp_get_toolGet one privacy toolARead-onlyInspect
Fetch a single privacy tool's full Privacy Protocol record by slug — description, ADO score, jurisdiction, encryption, PII requirements, red flags, platforms, and audit status.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tool slug, e.g. 'proton-mail', 'signal', 'mullvad'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds transparency by listing the returned fields (description, ADO score, etc.), though it does not specify error behavior for missing slugs.
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, well-front-loaded sentence. It is concise but could be broken into two sentences for clarity.
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 1-parameter tool with no output schema, the description fully lists the output fields, making it complete for agent decision-making.
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 clear description for 'slug'; the description adds examples but doesn't provide significant new meaning beyond what the schema already offers.
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 a specific verb 'Fetch' and resource 'privacy tool's full Privacy Protocol record' and lists key fields, clearly distinguishing it from sibling tools like dp_search_tools.
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 specific slug is known, but provides no explicit guidance on when to use this tool vs siblings like dp_search_tools or dp_get_glossary_term.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dp_list_categoriesList directory categoriesARead-onlyInspect
List the privacy tool directory's category groups and subcategories with tool counts. Use the returned slugs to filter dp_search_tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Read-only operation (supported by readOnlyHint annotation) with straightforward behavior; description adds context about tool counts without hiding any traits.
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: first states purpose, second gives actionable guidance; no wasted 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?
For a simple list tool with no output schema, description sufficiently describes output (categories with tool counts) and linkage to search, though could mention output format.
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?
No parameters, schema fully covered; description compensates by explaining output contents (categories, subcategories, tool counts) and usage, exceeding baseline 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?
Clearly states it lists category groups and subcategories with tool counts, distinguishing from sibling dp_search_tools by explicitly mentioning its use.
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?
Provides clear context for when to use (to get category structure) and gives explicit instruction to use returned slugs with dp_search_tools, though no exclusions for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dp_search_glossarySearch glossaryARead-onlyInspect
Search the privacy & security glossary for defined terms. Returns term, definition, and link; use dp_get_glossary_term for the full entry.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25). | |
| query | No | Term or keyword to search for, e.g. 'metadata', 'tor'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no contradiction. The description adds that it returns term, definition, and link, but offers no additional behavioral context beyond what annotations provide. With annotations present, this is adequate but not exceptional.
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?
Extremely concise: one sentence for the main purpose and a brief note about the sibling tool. No wasted words; front-loaded with essential information.
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 search tool with two parameters and no output schema, the description adequately covers what the tool returns and directs users to the sibling tool for full entries. No missing contextual elements.
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 fully describes both parameters. The description adds example values for query (e.g., 'metadata', 'tor') but does not provide substantial new meaning beyond the schema's 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 'Search the privacy & security glossary for defined terms' with a specific verb and resource, and distinguishes from the sibling tool dp_get_glossary_term by noting its use for full entries.
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 advises using dp_get_glossary_term for the full entry, providing clear guidance on when to use this tool vs the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dp_search_guidesSearch guidesARead-onlyInspect
Search Default Privacy's long-form guides and playbooks (self-hosting, hardening, privacy how-tos). Returns metadata and links; use dp_get_guide for full content.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20). | |
| query | No | Free-text search over guide title, description, and tags. | |
| category | No | Filter by guide category. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds context that tool returns metadata and links, implying a safe read operation, and mentions the companion tool for full content, but could further clarify pagination or sorting 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?
Two sentences, each adding value: first defines purpose and scope, second gives usage guidance. No filler 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?
Adequately covers the tool's function and suggests the companion tool for full content, but lacks explicit differentiation from other search tools in the sibling list.
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 parameter descriptions; the tool description provides high-level context but does not add significant new meaning beyond what the schema already conveys.
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 'Search Default Privacy's long-form guides and playbooks' with specific verb and resource scope, and explicitly distinguishes from sibling dp_get_guide by noting it returns only metadata and links.
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 advises using dp_get_guide for full content, but does not provide guidance on when to use this tool vs. other sibling search tools like dp_search_glossary or dp_search_tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dp_search_toolsSearch privacy toolsARead-onlyInspect
Search the Default Privacy directory of vetted privacy tools (VPNs, email, browsers, messengers, password managers, etc.). Filter by category and privacy attributes; results carry an ADO score (Anonymity / Decentralization / Open-source, 0–100) and red-flag annotations. Prefer higher ADO and zero unresolved red flags when recommending.
| Name | Required | Description | Default |
|---|---|---|---|
| e2ee | No | Only end-to-end encrypted tools. | |
| sort | No | Sort order. Defaults to highest ADO score first. | |
| limit | No | Max results (1–50, default 10). | |
| query | No | Free-text search over tool name and tagline, e.g. 'vpn', 'email', 'notes'. | |
| no_kyc | No | Only tools that require no KYC to purchase/use. | |
| offset | No | Pagination offset (default 0). | |
| category | No | Category slug or name to filter by (see dp_list_categories). | |
| open_source | No | Only open-source tools. | |
| has_free_tier | No | Only tools with a free tier. | |
| min_ado_score | No | Minimum ADO composite score (0–100). | |
| accepts_crypto | No | Only tools that accept cryptocurrency. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true) are consistent with a search operation. Description adds value by disclosing result structure (ADO score, red-flag annotations) and a decision rule for recommendations, going 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?
Three sentences front-loaded with the primary purpose, no filler, every sentence contributes meaning. Highly concise and well-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 11 parameters, no output schema, and no required fields, the description explains result contents and a recommendation rule. It omits pagination details and default sort order, but those are covered in the schema. Fairly complete for a search 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 clear parameter descriptions. The description only summarizes filtering capability without adding new details about parameters, so it does not enhance semantics beyond what the schema provides.
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 uses a specific verb ('Search') and resource ('Default Privacy directory of vetted privacy tools'), and distinguishes from sibling tools like dp_get_tool and dp_search_glossary by clearly stating the scope and result details.
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?
Description gives clear context for when to use (searching tools by category/attributes) and provides a recommendation guideline ('Prefer higher ADO and zero unresolved red flags'). It implicitly differentiates from siblings by naming the directory but lacks explicit when-not-to-use or alternatives.
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!