DNSFilter MCP integration for AI agents.
Connect AI agents to DNSFilter through 9 structured actions, including get category, get current user, and get my ip. Review authentication, inputs, workflow…
- ACTION CONTRACTS
- 9
- AUTHENTICATION
- API key
- SOURCE STATUS
- Provider-backed
CATALOG SOURCE REVIEWED AUGUST 23, 2026 / ACTION NAMES AND SCHEMAS DERIVED FROM WORKING MACHINES PROVIDER SOURCE
CAPABILITY PROFILE
What the DNSFilter integration exposes
The DNSFilter Agent App exposes 9 provider-backed actions for security work. Its current contract lets an authorized agent get one dnsfilter domain category by id, get the dnsfilter user associated with the api key, and get the public ip address observed by dnsfilter for the current request. These operations are called through Working Machines as typed capabilities rather than through browser navigation or copied UI steps.
A connection uses API key. Before execution, the agent can inspect the selected action, its required fields, declared scopes, and expected output contract. Provider credentials remain inside the Working Machines runtime; the calling agent receives the capability and its structured result, not the underlying secret.
For reliable operation, start with the narrowest action that satisfies the task, resolve stable provider identifiers before changing state, and validate the returned object or status after execution. Availability still depends on the connected DNSFilter account, granted provider permissions, workspace policy, region, plan, and upstream API behavior.
VERIFIED ACTION SAMPLE
Real DNSFilter capabilities.
Showing 9 of 9 actions. Risk labels are conservative signals based on operation names, not substitutes for provider documentation or runtime policy.
get_categoryREADGet one DNSFilter domain category by ID.
INPUTS: id
get_current_userREADGet the DNSFilter user associated with the API key.
get_my_ipREADGet the public IP address observed by DNSFilter for the current request.
list_application_categoriesREADList DNSFilter application categories with optional pagination.
INPUTS: page_number / page_size
list_applicationsREADList DNSFilter applications with optional category filtering and pagination.
INPUTS: category_ids / page_number / page_size
list_categoriesREADList DNSFilter domain categories with optional pagination.
INPUTS: page_number / page_size
list_ip_addressesREADList DNSFilter IP address records with optional search and pagination.
INPUTS: search / page_number / page_size
list_networksREADList DNSFilter networks with optional search and policy assignment filters.
INPUTS: basic_info / count_network_ips / force_truncate_ips / protected / search
list_policiesREADList DNSFilter policies with optional organization and global-policy filters.
INPUTS: include_global_policies / organization_id / page_number / page_size
INPUT CONTRACTS
Know what the action needs before it runs.
get_category
idOPTIONAL- The DNSFilter resource ID.
list_application_categories
page_numberOPTIONAL- The page number to request.
page_sizeOPTIONAL- The number of records to request per page.
list_applications
category_idsOPTIONAL- The DNSFilter application category IDs used to filter applications.
page_numberOPTIONAL- The page number to request.
page_sizeOPTIONAL- The number of records to request per page.
list_categories
page_numberOPTIONAL- The page number to request.
page_sizeOPTIONAL- The number of records to request per page.
PROVIDER-SPECIFIC WORKFLOWS
Jobs this Agent App can support
Inspect Get Category
Get one DNSFilter domain category by ID. Use this as a bounded discovery step, retain the returned identifier, and avoid expanding the read beyond the task's stated scope.
get_categoryVerify with Get Current User
Get the DNSFilter user associated with the API key. Compare the returned provider state with the intended outcome and preserve stable IDs or canonical links in the run record.
get_current_userSAFETY BOUNDARY
Operate DNSFilter with explicit limits
- Authorize DNSFilter with API key and grant only the provider access required by the selected actions.
- The current action names appear read-oriented, but returned DNSFilter data may still be sensitive and should be minimized before it enters model context.
- Do not infer permission from catalog visibility. Workspace policy, connection identity, and upstream authorization still govern execution.
- No provider scope string is declared on the sampled actions. Verify the connected account's actual permissions in DNSFilter rather than assuming unrestricted access.
- After a call, inspect the structured result and execution record before reporting that the DNSFilter task completed successfully.
CONNECTION MODEL
API key
DNSFilter API token sent directly in the Authorization header. Create or view API tokens in the DNSFilter dashboard under Account Settings: https://help.dnsfilter.com/hc/en-us/articles/21169189058323-API-Tokens.
Working Machines stores provider credentials behind the execution boundary. An agent can use an authorized connection identity, but catalog discovery alone does not reveal OAuth tokens, API keys, or provider secrets.
- READ SIGNALS
- 9
- WRITE SIGNALS
- 0
- HIGH IMPACT
- 0
- REVIEW SIGNALS
- 0
EVIDENCE AND AVAILABILITY
Provider reference
Action names, input fields, authentication types, and counts on this page are generated from the Working Machines provider catalog. Provider behavior, quotas, object semantics, account eligibility, and regional availability remain governed by DNSFilter.