Dropbox MCP Server

by OV-MapRoom

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity: copy, create_folder, create_shared_link, delete, get_metadata, get_space_usage, list_folder, list_shared_links, move, and search all target specific, non-overlapping operations in the Dropbox domain. An agent can easily distinguish between them based on their names and descriptions.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., create_folder, get_metadata, list_shared_links), with no deviations in style or convention. This predictability makes the tool set easy to navigate and understand at a glance.
Tool Count5/5
With 10 tools, the server is well-scoped for managing Dropbox files and folders. Each tool earns its place by covering essential operations like CRUD, metadata retrieval, space usage, listing, searching, and shared link management, without being overly sparse or bloated.
Completeness5/5
The tool set provides complete coverage for core Dropbox operations: create (create_folder), read (get_metadata, list_folder, search), update (copy, move), delete (delete), and additional utilities (space usage, shared links). There are no obvious gaps that would hinder an agent from performing typical file management tasks.
Average 3.2/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It fails to mention critical mutation behaviors: whether copies overwrite existing files, whether folder copies are recursive, preservation of metadata, or conflict resolution strategies.
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?
Single sentence is appropriately sized for a two-parameter tool. The action verb appears first. However, extreme brevity contributes to gaps in behavioral transparency and usage guidelines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for basic invocation but incomplete given zero annotations and no output schema. Missing essential context for a mutation tool: success/failure behaviors, idempotency characteristics, and response structure.
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 description coverage is 100% (both parameters have basic descriptions). The description does not add parameter-specific guidance (e.g., path format requirements, absolute vs relative paths) beyond the schema's 'Source path' and 'Destination path' labels. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (copy) and resource (file or folder) with location context (Dropbox). However, it does not explicitly differentiate from the sibling 'move' tool, which performs a similar path-based operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus the sibling 'move' tool or other alternatives. No mention of prerequisites such as path existence or permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to indicate whether this is read-only (likely yes, but unstated), what specific metadata fields are returned (size, modified time, sharing info), error behavior if the path is missing, or rate limiting considerations.
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?
Single sentence of seven words is appropriately front-loaded and wastes no words. However, the extreme brevity contributes to the completeness deficit given the lack of annotations and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations, no output schema, and a 'get' operation that likely returns rich structured data, the description is insufficient. It fails to enumerate what metadata is returned, whether it works on deleted files, or how to interpret the results.
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?
With 100% schema description coverage for the single 'path' parameter, the schema already documents the input adequately. The description mirrors the schema's 'file or folder' clarification but adds no additional semantic value regarding path format requirements (absolute vs relative, root prefix, case sensitivity).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get), resource (metadata), and target (file or folder in Dropbox). However, it does not distinguish from siblings like list_folder (which returns children/contents) or get_space_usage (which returns quota info), leaving the agent to infer this returns properties of the item itself rather than its contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus list_folder (which also takes a folder path) or search. Does not mention prerequisites like path existence requirements or permissions needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Fails to disclose critical behaviors: whether listing is shallow or recursive, pagination limits for large folders, error handling for invalid paths, or that this is a read-only operation.
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?
Single sentence of nine words is efficient and front-loaded with the action. No wasted words, though brevity leaves significant behavioral context undocumented given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic purpose adequately given the simple single-parameter input. However, with no output schema and no annotations, the omission of behavioral details (pagination, recursion depth, return structure) creates gaps that the description should have addressed.
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 has 100% coverage with clear description for 'path' parameter. The description implies the directory context but adds no syntax details, validation rules, or formatting requirements beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('List') and resource ('files and folders in a Dropbox directory') immediately conveys scope. However, it does not explicitly differentiate from the sibling 'search' tool or indicate this lists contents of a specific directory only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus 'search' (for querying across folders) or 'get_metadata' (for specific file details). No mention of prerequisites like path existence or permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Move' but omits critical behavioral traits: whether operation removes source file (implied but not explicit), overwrite behavior if destination exists, atomicity guarantees, or error conditions (e.g., destination folder missing).
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?
Single 9-word sentence is appropriately front-loaded with no redundancy, though extreme brevity leaves dangerous gaps for a destructive operation with zero behavioral annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Mutation tool with no annotations and no output schema requires description to disclose side effects (source deletion), conflict resolution, and return values. Current description is inadequate for safe invocation.
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 has 100% description coverage ('Current path', 'Destination path'). Description mentions 'new location' which aligns with to_path but adds no syntax details, path format requirements, or examples beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Move') and resource ('file or folder') with scope ('in Dropbox'), but does not explicitly differentiate from sibling 'copy' or indicate when to prefer copy over move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus alternatives (e.g., 'copy' if source should be preserved), prerequisites, or preconditions like write permissions on destination folder.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Fails to disclose critical mutation behaviors: idempotency (error vs success if exists), auto-create intermediate directories (mkdir -p behavior), or required permissions. Only states the action occurs, not how it behaves.
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?
Extremely concise six-word sentence with zero redundancy. Front-loaded action verb immediately communicates intent without superfluous language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for low complexity (single parameter, no output schema), but lacks behavioral context expected for a mutation operation. Missing error conditions and side-effects that would help an agent handle failure cases.
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% with path parameter fully documented. Description adds no additional semantics beyond schema (e.g., path normalization rules, trailing slash handling, case sensitivity), warranting baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Create), resource (folder), and scope (Dropbox) clearly. Distinguishes from siblings like delete, move, and list by operation type, though could better differentiate from create_shared_link beyond implied resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use versus alternatives (e.g., move/copy for existing folders), prerequisites like parent folder existence, or behavior if the folder already exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a write operation but fails to disclose idempotency, visibility settings (public/private), what gets returned (critical for a creation tool), or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence front-loaded with the action. No redundancy or tautology; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter tool with complete schema coverage, but gaps remain regarding mutation behavior and return values given the lack of output schema and annotations.
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% (path: "Path to share"), establishing baseline 3. Description adds domain context (Dropbox) and confirms the path targets files/folders, but does not elaborate on path format, leading slash requirements, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb (Create), resource (shared link), and scope (Dropbox file/folder). However, it does not explicitly differentiate from sibling tool list_shared_links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus listing existing links, prerequisites (file must exist), or handling idempotency (what happens if link already exists).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full behavioral disclosure burden but fails to mention read-only safety, result pagination behavior, case sensitivity rules, or partial vs exact matching behavior for the query parameter.
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?
Single sentence of nine words is efficiently structured with action front-loaded. However, extreme brevity leaves significant gaps in behavioral and usage guidance that should have been included given the lack of annotations or output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema or annotations, the description is incomplete. Missing critical context: result structure/format, whether results include metadata or just paths, behavior when query finds no matches, and how max_results pagination works.
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% with all three parameters documented. Description adds minimal context beyond schema—'by name' clarifies the query parameter's purpose slightly, but doesn't add syntax details, examples, or clarify the path parameter's format expectations beyond what the schema already states.
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?
Description provides specific verb ('Search'), specific resource ('files and folders in Dropbox'), and specific method ('by name'), clearly distinguishing it from siblings like list_folder (contents listing) and get_metadata (specific file info retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description lacks any guidance on when to use this tool versus alternatives like list_folder or get_metadata. No mention of search scope limitations, performance considerations, or when name-based search is preferred over browsing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States read operation but omits critical behavioral details: pagination behavior, whether results include expired links, ownership scope (user-only vs team), and error handling when no links exist.
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?
Single sentence, front-loaded with action. No redundancy, though brevity borders on underspecification given lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimally adequate for a single-parameter list operation. Covers core functionality and optional filter. Lacks output format details, but acceptable given no output schema and low complexity.
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% with path described as 'Optional path to filter shared links'. Description maps 'Dropbox file/folder' to the path parameter but adds no semantic detail beyond schema (format, examples, path requirements). Baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'List' with specific resource 'shared links' and scope (file/folder or all). Implicitly distinguishes from create_shared_link (create vs list) and list_folder (links vs contents). Missing explicit Dropbox context or differentiation from search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies optional filtering via 'or all shared links' but lacks explicit when-to-use guidance. No mention of when to prefer this over search/list_folder or prerequisites (e.g., needing file access permissions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It crucially discloses the soft-delete nature ('moves to trash'), which is vital safety information. However, it omits whether this requires specific permissions, if there's a recovery window, or what happens to shared links/permissions.
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?
Single 9-word sentence with zero waste. Every word earns its place: action (Delete), target (file or folder), scope (Dropbox), and critical behavioral detail (moves to trash). Perfectly front-loaded and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter deletion tool with no output schema, the description is sufficiently complete. It covers the operation, target, domain, and trash behavior. Could mention return value or error conditions (e.g., path not found), but adequate for complexity level.
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% (path is documented as 'Path to delete'), so the baseline is 3. The description adds minimal parameter-specific semantics beyond the schema, though it implies the path refers to files/folders in Dropbox context.
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?
Excellent clarity with specific verb 'Delete', resource 'file or folder', and scope 'in Dropbox'. The '(moves to trash)' parenthetical distinguishes the exact semantics from permanent deletion, clearly differentiating it from potential alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this versus the 'move' tool (which could theoretically be used to relocate to trash) or prerequisites like file existence. The trash note provides implicit behavioral guidance but lacks explicit when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Fails to disclose what 'usage' entails (used vs total vs available bytes), whether shared folders are counted, response format, or caching behavior. 'Current' implies real-time but doesn't confirm freshness guarantees.
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?
Single 7-word sentence with no redundancy. Appropriate length for a parameterless getter tool; every word earns its place by identifying action, scope, and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter tool, though no output schema exists to document return values. Description successfully identifies the entity being retrieved but omits details about what specific metrics are returned (bytes, percentages, limits).
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?
Zero parameters exist with 100% schema coverage (trivially empty schema). Baseline 4 applies as there are no parameters requiring semantic elaboration beyond the empty schema definition.
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?
Specific verb 'Get' and clear resource 'Dropbox account space usage' provided. Distinguished from file-operation siblings (copy, delete, list_folder, etc.) by specifying account-level metadata rather than file content operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives mentioned. Usage is implied by the specific functionality (retrieve space usage), but lacks guidance on when to prefer this over calculating sizes via list_folder or prerequisites like authentication scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dropbox-mcp-localserver MCP server](https://glama.ai/mcp/servers/OV-MapRoom/dropbox-mcp-localserver/badges/card.svg)](https://glama.ai/mcp/servers/OV-MapRoom/dropbox-mcp-localserver)

Score Badge

Copy to your README.md:

[![dropbox-mcp-localserver MCP server](https://glama.ai/mcp/servers/OV-MapRoom/dropbox-mcp-localserver/badges/score.svg)](https://glama.ai/mcp/servers/OV-MapRoom/dropbox-mcp-localserver)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OV-MapRoom/dropbox-mcp-localserver'

If you have feedback or need assistance with the MCP directory API, please join our Discord server