Skip to main content
Glama

get_project

Read-onlyIdempotent
Returns details for a specific project: its members, documents, context items, and — when one is set — the project's **brief**.

**Read the brief before doing substantive work in this project.** The `project_brief` block is the project's authoritative statement of premise, scope and the structural decisions already taken. Its `content_intro` is an excerpt (the full body when the brief is short, otherwise the opening ~400 words with `truncated: true`); call `get_content` with its `content_id` for the full text. The other documents and context items in this project may be older than the brief, or may contradict it — the brief wins. Work produced without reading it is likely to contradict decisions already made. The matching entry in `documents` is flagged `is_project_brief: true` and sorted first.

Use `list_projects` to discover available projects and find the `project_id`.

`project_brief.content_id` also doubles as the shortcut for EDITING the brief via `update_content`.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>"
    },
    "name": "get_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idYesThe project's UUID, exactly as returned in the `project_id` field of list_projects or create_project. A numeric id or a project name will not resolve. You must be a member of the project's team, and if the project is private you must also be one of its members, or the call is rejected.

Output Schema

NameRequiredDescriptionDefault
idYesProject UUID.
nameYesProject name.
statusNoProject status (e.g. active, archived).
membersNo
documentsNo
created_atNoUnix timestamp of creation.
visibilityNoVisibility (e.g. team, private).
context_itemsNoContext items associated with this project.
project_briefNoThe project's brief, if one is set — the authoritative statement of the project's premise, scope and structural decisions. READ IT FIRST: other documents and context items in this project may be older than it or contradict it. content_intro is an excerpt (the full body when the brief is short, otherwise the opening ~400 words with truncated: true); pass content_id to get_content for the full text, or to update_content to edit it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: brief precedence over other documents, the ~400-word truncation with a `truncated: true` flag, the `is_project_brief` flag with sort-first ordering, and that content_id doubles as the handle for editing via update_content.

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?

Front-loaded with the return contents and then the brief-reading rule, which is the highest-value guidance. Slightly redundant where the precedence of the brief is asserted twice ('the brief wins' and 'likely to contradict decisions already made'), but no sentence is wasted.

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?

An output schema exists, yet the description still characterizes the notable structures (project_brief block, documents flags, truncation) that an agent must interpret. For a single-parameter read tool with full schema coverage, nothing needed to call or interpret it is missing.

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% and the schema already documents the UUID format, the source of the value (list_projects/create_project), and the membership/private-project requirement. The description only restates the discovery route, so it adds little beyond the schema and the baseline 3 applies.

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?

Opens with a specific verb and resource: 'Returns details for a specific project', and enumerates the payload (members, documents, context items, brief). This clearly distinguishes it from list_projects and get_content, which appear as siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use list_projects to discover projects and obtain project_id, and call get_content with content_id when the brief excerpt is truncated. It also states a strong when-to-use rule ('Read the brief before doing substantive work in this project').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources