Skip to main content
Glama

getObjectUrl

Generate signed download URLs for files stored in cloud storage buckets to enable secure access and sharing.

Instructions

获取存储桶内的文件的带签名的下载链接

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
objectKeyYes文件的路径

Implementation Reference

  • src/server.ts:251-269 (registration)
    Registration of the MCP tool 'getObjectUrl' with description, Zod input schema, and inline handler function that invokes the COS service and returns formatted response.
    server.tool(
      'getObjectUrl',
      '获取存储桶内的文件的带签名的下载链接',
      {
        objectKey: z.string().describe('文件的路径'),
      },
      async ({ objectKey = '/' }) => {
        const res = await COSInstance.getObjectUrl(objectKey);
          return {
            content: [
              {
                type: 'text',
                text: JSON.stringify(res.data, null, 2),
              },
            ],
            isError: !res.isSuccess,
          };
      },
    );
  • Core implementation of getObjectUrl in COSService class, using Tencent COS SDK to generate signed download URL for the object.
    async getObjectUrl(ObjectKey: string) {
      try {
        const result = await new Promise((resolve, reject) => {
          this.cos.getObjectUrl(
            {
              Bucket: this.bucket,
              Region: this.region,
              Key: ObjectKey,
            },
            (error, data) => (error ? reject(error) : resolve(data)),
          );
        });
    
        return {
          isSuccess: true,
          message: '获取带签名 ObjectUrl 成功',
          data: result,
        };
      } catch (error) {
        return {
          isSuccess: false,
          message: '获取带签名 ObjectUrl 失败',
          data: error,
        };
      }
    }
  • Zod input schema for the getObjectUrl tool, defining the objectKey parameter.
    {
      objectKey: z.string().describe('文件的路径'),
    },
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 mentions the output is a 'signed download link', implying authentication and temporary access, but doesn't detail key behaviors: whether the URL has an expiration time, what permissions are required, if it's idempotent, or if there are rate limits. For a tool that generates access-controlled URLs, this lack of operational context is a significant gap.

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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource. However, it could be slightly more structured by explicitly separating the action from the output type, but this is minor.

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 the complexity (generating signed URLs often involves security and expiration details), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the signed URL looks like, how long it's valid, or any error conditions. For a tool with potential behavioral nuances, this leaves critical gaps for an agent to use it effectively.

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

Parameters3/5

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

The input schema has 100% description coverage, with 'objectKey' documented as '文件的路径' (file path). The description doesn't add any parameter-specific information beyond what's in the schema, such as format examples (e.g., path syntax) or constraints (e.g., allowed characters). Since the schema already fully describes the single parameter, the baseline score of 3 is appropriate, as no additional value is provided.

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 action ('获取' meaning 'get') and the resource ('存储桶内的文件的带签名的下载链接' meaning 'signed download URL for a file in a storage bucket'). It specifies the output is a signed URL rather than the file content itself, which distinguishes it from sibling tools like 'getObject'. However, it doesn't explicitly differentiate from all siblings, such as 'getBucket' or 'getCosConfig', which also retrieve information about storage resources.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid bucket or authentication), compare it to similar tools like 'getObject' (which might retrieve the file directly), or specify use cases (e.g., for sharing files securely). Without this context, an agent might struggle to choose between this and other retrieval tools.

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

Install Server

Other Tools

Latest Blog Posts

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/xiaomizhoubaobei/MCP'

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