Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ObjectLens MCP Server list buckets for my default provider"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that connects Large Language Models (LLMs) to the ObjectLens REST API. This allows AI assistants to browse S3-compatible buckets, search indexed S3 object metadata, and preview object contents directly.
The server is configured using environment variables:
Environment Variable | Description | Default |
| Base URL of the ObjectLens REST API |
|
| Username for HTTP Basic Authentication | None |
| Password for HTTP Basic Authentication | None |
Related MCP server: S3 MCP Server
The server exposes the following tools to the LLM:
list_providers: List configured S3 storage providers.
get_default_provider: Get connection details of the default/active provider.
list_buckets: List S3 buckets for a specific provider.
list_bucket_objects: List or search objects in a specific bucket with prefix and pagination.
get_object_metadata: Retrieve detailed metadata (size, content-type, ETag, etc.) of an object.
get_object_preview: Read the content/preview of an object (supports text, JSON, CSV, code, etc.).
search_objects: Query indexed metadata globally or scoped to a bucket.
scan_bucket: Trigger S3 bucket metadata scanning to sync metadata into ObjectLens database.
list_activities: Fetch recent activity logs/operations from ObjectLens.
You can run the server directly using uv:
# From this directory
uv run python server.pyOr run it remotely:
uv run --path /path/to/objectlens/mcp-server/server.pyBuild the Docker image:
docker build -t objectlens-mcp-server .Run the container:
docker run -i --rm \
-e OBJECTLENS_API_URL="http://host.docker.internal:8000" \
objectlens-mcp-serverThe image is automatically built and published to GitHub Container Registry (GHCR) on every push to the main branch or when a release tag (e.g., v1.0.0) is published.
To pull and run the pre-built image directly from GHCR:
docker run -i --rm \
-e OBJECTLENS_API_URL="http://host.docker.internal:8000" \
ghcr.io/<github-owner-or-org>/mcp-server:latest(The -i flag is required because the MCP server communicates over standard input/output).
To integrate this server with Claude Desktop, add it to your configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"objectlens": {
"command": "uv",
"args": [
"run",
"--path",
"/path/to/objectlens/mcp-server/server.py"
],
"env": {
"OBJECTLENS_API_URL": "http://localhost:8000"
}
}
}
}Get connection details of the default/active storage provider.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Get') and resource, but does not mention potential error cases (e.g., no default provider), authentication requirements, or any side effects. The tool is a simple getter, but the description offers no transparency beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, containing no fluff or repetition. It is front-loaded with the action and resource, making it highly concise and well-structured for an AI agent to quickly parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (zero parameters, output schema present), the description lacks context about when to use it versus alternatives and provides no behavioral details such as error conditions or return value semantics. The output schema covers return values, but the absence of usage guidance and behavioral transparency makes the description only minimally complete for a zero-parameter getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to explain. According to the rubric, a baseline of 4 is appropriate for 0-parameter tools, as the description does not need to compensate for missing parameter documentation. The description adds no parameter-specific information but does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving connection details for the default/active storage provider. It uses a specific verb ('Get') and resource, making it distinct from sibling list_providers, which lists all providers rather than the active one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the default/active provider's connection details are needed, but it provides no explicit guidance on when to use this tool over alternatives like list_providers. The sibling list provides context, but the description itself lacks explicit usage instructions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed metadata for a specific object in a bucket.
:param bucket: Name of the bucket. :param key: Unique key/path of the object. :param provider_id: Optional provider connection ID.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| bucket | Yes | ||
| provider_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It does not disclose that the operation is read-only, whether authentication is required, or any side effects. The description is too minimal to inform the agent about behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: a single purpose sentence followed by structured parameter docs. It is front-loaded with the core action and contains no unnecessary words. The format is clean and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values need not be explained. However, the description lacks usage context and behavioral guarantees, and without annotations the agent is left to infer when to use this tool and whether it is safe. It is minimally complete but leaves important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates with explicit param docs for all three parameters. It clarifies that bucket is the name, key is the unique path, and provider_id is an optional connection ID, adding meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed metadata') and the resource ('a specific object in a bucket'), using a specific verb and resource. This distinguishes it from siblings like get_object_preview (preview content) and list_bucket_objects (list objects).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_object_preview or scan_bucket. There is no mention of exclusions, prerequisites, or scenarios where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents or preview of an S3 object. Useful for text, JSON, CSV, or code files.
:param bucket: Name of the bucket. :param key: Unique key/path of the object. :param max_bytes: Maximum number of bytes to retrieve (default is 1MB). :param provider_id: Optional provider connection ID.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| bucket | Yes | ||
| max_bytes | No | ||
| provider_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the read-only nature and the max_bytes limit, but it does not explain what happens when max_bytes is exceeded (e.g., truncation) or how binary/non-text files are handled. This leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The parameter list is structured and each line adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and four parameters, but with no annotations, the description needs to provide more context. It covers the basics but omits details about output truncation, error cases, or behavior with unsupported file types. For an agent, it's adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (0% coverage), so the description must compensate. It explains each parameter: bucket name, key path, max_bytes with a default, and provider_id as optional. This adds meaningful semantics beyond the raw schema, though it could be more detailed (e.g., provider_id format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read the contents or preview of an S3 object.' This is a specific verb+resource statement. It also distinguishes from sibling tools like get_object_metadata by focusing on content preview rather than metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context by noting it's 'Useful for text, JSON, CSV, or code files,' which helps an agent decide when to use it. However, it doesn't explicitly name alternative tools or state when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent S3 activities/logs indexed in ObjectLens.
:param limit: Maximum activities to list (default is 10). :param offset: Offset for pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses that the tool returns indexed activities/logs rather than raw S3 data, which is helpful. However, it does not explicitly state that it is a read-only operation, define 'recent', or mention any permission requirements 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with purpose. The param docs are structured clearly with no filler or redundant repetition of the schema. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool with an output schema present, the description covers the essential purpose and parameter behavior. It could mention the time window for 'recent' or sorting order, but these are minor gaps given the output schema likely defines the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains both parameters: 'limit' as maximum activities to list (with default 10) and 'offset' for pagination. This adds meaningful semantics beyond the bare schema, which only provides types and defaults. Since schema description coverage is 0%, the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('List'), the resource ('recent S3 activities/logs'), and the scope ('indexed in ObjectLens'). This distinguishes it from siblings like list_buckets and list_bucket_objects, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource and tool name, but there is no explicit guidance on when to use this tool versus alternatives or any exclusions. The description does not mention that it only handles indexed activities, which could be a useful clarifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search objects inside a specific bucket, with prefix filtering and pagination.
:param bucket: The bucket name to query. :param prefix: Optional prefix/folder path (e.g. 'data/'). :param search: Optional search pattern or glob string (e.g. '*.json'). :param limit: Maximum items to return (default is 50). :param offset: Offset for pagination (default is 0). :param delimiter: Path separator (default is '/'). :param provider_id: Optional provider connection ID.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| bucket | Yes | ||
| offset | No | ||
| prefix | No | ||
| search | No | ||
| delimiter | No | / | |
| provider_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains pagination, defaults, and search patterns, but does not explicitly state that the operation is read-only or describe the shape of results beyond the output schema. The absence of side effects is implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary followed by a compact, informative parameter list. Every line adds value without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no annotations, the description covers all parameters and provides meaningful context like defaults and examples. It does not discuss sorting, return value details, or edge cases, but the presence of an output schema mitigates the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully compensates by explaining every parameter: bucket, prefix with example, search glob pattern, limit, offset, delimiter, and provider_id. This adds substantive meaning beyond the bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists or searches objects inside a specific bucket with prefix filtering and pagination, identifying the resource and action. However, it does not explicitly differentiate from sibling tools like search_objects or scan_bucket, leaving potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bucket object listing/searching through its phrasing and parameter explanations, but it lacks explicit guidance on when to use this tool versus alternatives such as search_objects. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all S3 buckets for a specific provider, or the default provider if not specified.
:param provider_id: Optional connection ID of the provider.
| Name | Required | Description | Default |
|---|---|---|---|
| provider_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It clearly states the default provider behavior when provider_id is omitted, which is a meaningful side effect not captured in the schema. The read-only nature is implied by 'List', but details like pagination or error handling are not disclosed, preventing a score of 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences with no redundancy. The main action is front-loaded, and the parameter documentation is concise, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter and an output schema, the description covers the essential behavior and parameter semantics. The output schema handles return value details, so the concise description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds essential meaning to the single parameter provider_id, calling it an 'Optional connection ID of the provider' and explaining its role in deciding which provider to use. This goes well beyond the schema, which only indicates type and default without any semantic explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all S3 buckets' with an optional provider scope, which is specific and actionable. It distinguishes from sibling tools like list_bucket_objects (objects within a bucket) and list_providers (providers themselves).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the optional provider_id ('for a specific provider, or the default provider if not specified'), which gives some usage context. However, it does not explicitly mention when to prefer this tool over alternatives like list_bucket_objects, leaving the comparison to implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List S3-compatible storage providers configured in ObjectLens.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavior. It only uses the verb 'List', implying a read-only operation, but omits any details about permissions, return format, or side effects, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler, front-loading the action and resource clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (no parameters, output schema exists), the description is sufficiently complete. It could specify whether all providers are returned or pagination behavior, but overall it covers the essential purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has nothing to add beyond the schema. Baseline for zero parameters is 4, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'S3-compatible storage providers configured in ObjectLens', making it specific and distinguishable from sibling tools that list buckets or objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing configured providers but does not explicitly state when to use this tool over alternatives like 'get_default_provider' or 'list_buckets', nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a S3 bucket metadata scan to index object records into ObjectLens database.
:param bucket: The S3 bucket to index. :param provider_id: Optional provider connection ID.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket | Yes | ||
| provider_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It explains that the tool triggers a scan and indexes records, which is useful behavioral context. However, it does not mention whether the scan is asynchronous, whether it is idempotent, or any required permissions or side effects, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The param docstrings add needed detail without fluff. Every sentence contributes, and there is no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the description covers the purpose and parameter semantics adequately. The output schema exists, so return values are handled elsewhere. However, it lacks usage guidelines and deeper behavioral details (e.g., asynchronous behavior, error conditions), making it slightly incomplete but not critically so.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining both parameters: 'bucket' is the S3 bucket to index, and 'provider_id' is an optional provider connection ID. This adds meaning beyond the schema's bare field titles, though it doesn't provide formats, defaults, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: trigger a metadata scan to index object records into the ObjectLens database. It uses a specific verb ('scan') and resource ('S3 bucket'), and the outcome (indexing into a database) distinguishes it from sibling tools like list_bucket_objects or get_object_metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you want to index a bucket's object records into ObjectLens. However, it does not explicitly mention alternatives, prerequisites, or when not to use it. The context is clear but lacks exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search indexed object metadata in ObjectLens using a query pattern.
:param search: Broad search query (e.g. partial file name or type). :param bucket: Optional bucket name to scope the search. :param prefix: Optional prefix to scope the search. :param limit: Maximum search results (default 100). :param offset: Offset for pagination. :param provider_id: Optional provider connection ID.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| bucket | No | ||
| offset | No | ||
| prefix | No | ||
| search | Yes | ||
| provider_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full behavioral disclosure, but it only states that it searches indexed object metadata. It does not mention whether the operation is read-only, any permissions required, pagination behavior beyond offset/limit, or potential 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence followed by a structured parameter list. Every sentence earns its place, and the format front-loads the purpose before compact parameter definitions, with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The parameter semantics are well covered and an output schema exists, so return values are not needed. However, it lacks usage context relative to sibling tools and does not describe search behavior such as query syntax, wildcards, or result ordering, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful explanations for all six parameters despite the schema having 0% description coverage. Each parameter gets a concrete definition (e.g., 'search: Broad search query (e.g. partial file name or type)'), which adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search indexed object metadata in ObjectLens using a query pattern,' specifying both the action (search) and the resource (indexed object metadata). It is clear and distinguishes from list-style sibling tools like list_bucket_objects, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance or mention of alternatives such as scan_bucket or list_bucket_objects. The param descriptions imply a general search use case, but the description does not clarify when this tool is preferable over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_default_providerget_object_metadataget_object_previewlist_activitieslist_bucket_objectslist_bucketslist_providersscan_bucketsearch_objectsMost tools have clear distinct purposes: listing providers, getting default provider, listing buckets, listing objects, getting metadata, scanning, previewing, searching, and listing activities. The only slight overlap is between list_bucket_objects and search_objects, but the descriptions clarify one is a direct S3 listing while the other searches the indexed metadata.
All tool names follow a consistent verb_noun pattern with lowercase and underscores: list_providers, get_default_provider, list_buckets, list_bucket_objects, get_object_metadata, scan_bucket, get_object_preview, search_objects, list_activities. This makes the set very predictable.
With 9 tools, the server is well-scoped for S3 provider and object metadata management. Each tool covers a distinct aspect of listing, retrieval, scanning, and searching, and the count feels appropriate for the domain.
The tool set covers the core workflows of listing providers, buckets, objects, retrieving metadata and content, triggering scans, searching the index, and viewing activities. Minor gaps exist such as provider CRUD or object deletion, but these are likely outside the server's focus on indexing and browsing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Connects AI assistants to CloudQuell multi-cloud and AI cost, savings, anomaly, and budget data.
Connect AI clients to biomedical data and tools.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/objectlens/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
