Skip to main content
Glama
anythink-cloud

Anythink-MCP

Official

Import: directus

import_directus
Destructive

Copy collections, fields, and optional flows, files, roles, and records from a Directus instance into the active Anythink project. Preview with dry_run first, then apply with approval.

Instructions

Import collections, fields, flows, and data from a Directus instance. Writes into the active project: run with --dry-run first and add --yes only once the user has approved the plan. Copies a Directus instance's collections and fields into the active project as entities and fields; flows, files, roles and records come across only with include_flows, include_files, include_roles and include_data. Call it with dry_run first and show the user the plan, because a call without dry_run applies the import straight away. Returns JSON. It changes or deletes existing data, so check with the user before running it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoTarget Anythink project profile (defaults to the active profile)
urlNoDirectus instance base URL (e.g. https://cms.example.com)
tokenNoDirectus static or admin token. Prefer the DIRECTUS_TOKEN environment variable: a flag lands in shell history and the process list
dry_runNoPreview what would be imported without making any changes
include_dataNoAlso import records from each collection (schema must already match)
include_filesNoAlso download files from Directus and re-upload to Anythink (runs before --include-data)
include_flowsNoAlso import Directus flows as Anythink workflows
include_rolesNoAlso import Directus roles + permissions, and promote collections to is_public when the Public policy can read them
allow_insecureNoAllow a plain http:// Directus URL (localhost is always allowed)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.37

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare destructiveHint=true, readOnlyHint=false, and the description reinforces this by warning that a call without dry_run applies the import immediately and that it changes or deletes existing data. It adds context beyond annotations, though it does not detail auth requirements or rate limits.

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

Conciseness4/5

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

Front-loads the core purpose and destructive warning, but the description is somewhat repetitive, restating the dry-run advice multiple times and using both --dry-run and dry_run terminology.

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?

Covers purpose, destructive nature, required safety workflow, and the meaning of the optional include_* parameters. With no output schema, it also notes the tool returns JSON. Complete for a 9-parameter destructive import tool.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds semantic detail by explaining that flows/files/roles/records only come across with the corresponding include_* flags and that include_files runs before include_data, which is not captured in the schema.

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 (Import) and enumerated resources (collections, fields, flows, data) from a named source (Directus), and distinguishes itself from the sibling data_import by naming the source system.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicitly instructs to run with --dry-run first and add --yes only after user approval, and explains what is included only when include_flows/include_files/include_roles/include_data are set. This is exactly the when/when-not guidance an agent needs for a destructive tool.

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

Deploy Server

Other Tools