Skip to main content
Glama

Get one privacy tool

dp_get_tool
Read-onlyIdempotent

Fetch one directory tool's full record by slug: description, DP pick (if any), jurisdiction, encryption, PII requirements, platforms, and its Default Privacy page (dp_url). Also returns sources (links, keyed by the field they back, with the date checked) and caveats (things to know before choosing). A null field means Default Privacy has not checked it (never read null as no); quote the caveats and cite the sources. Slugs come from dp_search_tools.

Input Schema

NameRequiredDescriptionDefault
slugYesTool slug, e.g. 'proton', 'signal', 'mullvad'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / slug / description
      Previous value: -"Tool slug, e.g. 'proton-mail', 'signal', 'mullvad'."New value: +"Tool slug, e.g. 'proton', 'signal', 'mullvad'."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Adds important behavioral context beyond annotations: null means 'not checked' and must never be read as 'no'; caveats should be quoted and sources cited. It also describes the shape of sources (links keyed by field with date checked), which is valuable since no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and returned fields, then adds essential null and citation guidance. Every sentence earns its place with no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description thoroughly explains what is returned, including sources and caveats, and clarifies critical null semantics. An agent has everything needed to call and interpret the tool correctly.

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

Parameters3/5

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

Schema coverage is 100% and the slug parameter is fully documented in the schema. The description adds that slugs come from dp_search_tools but no additional format or validation details beyond the schema examples.

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

Purpose5/5

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

States a specific verb and resource ('Fetch one directory tool's full record by slug') and enumerates the returned fields, including sources, caveats, and dp_url. This clearly distinguishes it from sibling search/list 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.

Usage Guidelines4/5

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

Explicitly tells the agent where slugs come from ('Slugs come from dp_search_tools'), establishing the prerequisite and implied sequence. It does not spell out when-not-to-use or compare against siblings such as dp_compare_tools, but the usage context is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources