Skip to main content
Glama

get_file_contents

Retrieve file or directory contents from a GitLab project using a file path, project ID, and optional ref.

Instructions

Get the contents of a file or directory from a GitLab project

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNo
file_pathNo
project_idNo
Behavior2/5

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

No annotations are present, so the description is solely responsible for behavioral disclosure. It only states that contents are retrieved, but does not explain output format, size limits, authentication needs, or whether it returns raw content or metadata. The behavior for directories versus files is also unclear.

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 sentence with no unnecessary words, achieving high conciseness. However, it lacks structure like bullet points or separate sections that could improve readability for more complex details.

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 tool has 3 parameters with no documentation and no output schema, the description is too sparse. It does not explain return values, error handling, or how this tool differs from other read operations like get_project_wiki_page. The agent has insufficient information to use it correctly.

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

Parameters2/5

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

The input schema has 0% description coverage for parameters, and the description adds no information about what ref, file_path, or project_id mean. Without this, an agent cannot correctly determine how to supply values for these parameters.

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 'Get the contents of a file or directory from a GitLab project' clearly states the verb (Get) and the resource (file/directory). It distinguishes this tool from siblings that create or modify resources, making its purpose unambiguous.

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 such as list_commits or get_project_wiki_page. It lacks information on prerequisites, limitations, or conditions for appropriate use.

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/yoda-digital/mcp-gitlab-server'

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