ObjectLens MCP Server

Official

by objectlens

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.9/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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?
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

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:

[![mcp-server MCP server](https://glama.ai/mcp/servers/objectlens/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/objectlens/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/objectlens/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/objectlens/mcp-server)

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/objectlens/mcp-server'

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