Skip to main content
Glama

Dropbox

by io.github.pipeworx-io

Dropbox Get Metadata

dropbox_get_metadata
Read-onlyIdempotent

Get detailed metadata for a file or folder: size, modified date, ID, sharing status, and revision info. Use before downloading or modifying to inspect properties.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesFile or folder path

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoUnique file/folder ID
revNoCurrent revision identifier
nameNoFile or folder name
sizeNoFile size in bytes
errorNoError code if connection failed
is_dirNoWhether entry is a directory
messageNoError message if connection failed
modifiedNoLast modified timestamp
path_displayNoDisplay path
sharing_infoNoSharing details if shared

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "error": {
+      "description": "Error code if connection failed",
+      "type": "string"
+    },
+    "id": {
+      "description": "Unique file/folder ID",
+      "type": "string"
+    },
+    "is_dir": {
+      "description": "Whether entry is a directory",
+      "type": "boolean"
+    },
+    "message": {
+      "description": "Error message if connection failed",
+      "type": "string"
+    },
+    "modified": {
+      "description": "Last modified timestamp",
+      "type": "string"
+    },
+    "name": {
+      "description": "File or folder name",
+      "type": "string"
+    },
+    "path_display": {
+      "description": "Display path",
+      "type": "string"
+    },
+    "rev": {
+      "description": "Current revision identifier",
+      "type": "string"
+    },
+    "sharing_info": {
+      "description": "Sharing details if shared",
+      "properties": {
+        "share_id": {
+          "description": "Share ID if shared",
+          "type": "string"
+        },
+        "shared": {
+          "description": "Whether item is shared",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "size": {
+      "description": "File size in bytes",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "path": "/Documents/budget.xlsx"
+  }
+]
  3. First observed

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the metadata fields returned and the recommendation to use it before modifying, but this is more about output scope than behavioral caveats. No additional constraints, permissions, or failure modes are disclosed, so a 3 is appropriate given the annotation coverage.

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?

Two sentences, front-loaded with the action and resource, and every clause carries useful information. The metadata list is concise and the usage tip is brief. No filler or repetition.

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?

For a simple one-parameter tool with a rich output schema (metadata fields are already listed) and comprehensive annotations (safe read-only, idempotent), the description fully covers purpose, usage context, and return contents. No missing information that would impair an agent's ability to invoke the tool.

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?

The schema has 100% coverage: the only parameter 'path' is described as 'File or folder path'. The description reiterates that the tool works for files and folders but does not add extra meaning about path format, leading slashes, or special values. Baseline 3 is correct when the schema fully documents the parameter.

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?

The description uses the specific verb 'Get' with a clear resource ('detailed metadata for a file or folder') and enumerates the metadata fields (size, modified date, ID, sharing status, revision info). This distinguishes it from sibling tools like dropbox_download or dropbox_list_folder, which have different purposes.

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?

The description explicitly states when to use the tool: 'Use before downloading or modifying to inspect properties.' This provides clear usage context and implies it is a pre-action inspection step. It does not explicitly name alternative tools for other scenarios, but the guidance is sufficient for the intended use.

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

All Dropbox toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation2/5

The server name 'Dropbox' leads agents to expect file storage operations, but only 5 of 35 tools are Dropbox-specific. The majority are Pipeworx data lookup and prediction market tools, creating a confusing mismatch between server identity and toolset.

Naming Consistency2/5

Dropbox tools consistently use 'dropbox_verb_noun', but Pipeworx tools mix naming styles: some use 'verb_noun' like 'validate_claim', others use descriptive phrases like 'entity_profile' or 'recent_changes'. The overall set lacks a unified naming convention.

Tool Count2/5

35 tools is high, and the majority are unrelated to the server's name. The Dropbox subset alone is appropriately scoped with 5 tools, but the inclusion of 30 misc data tools makes the set feel bloated and unfocused for a server purportedly dedicated to Dropbox.

Completeness2/5

For the Dropbox domain, the tools cover only basic operations (create folder, download, list, search, metadata) missing update, delete, share. For the Pipeworx domain, the toolset is extensive, but the overall combination lacks completeness for any single coherent purpose.

Resources