Skip to main content
Glama

Get project.md (board type, template, statuses with colour, WIP limit and meaning — D102 —, custom fields and saved filters — D129 —, workflow) and your role

get_project
Read-onlyIdempotent

Get project.md (board type, template, statuses with colour, WIP limit and meaning — D102 —, custom fields and saved filters — D129 —, workflow) and your role.

Returns project.md: board type, sprint_control (scrum: admins default, or members = every member runs sprints), company_access (none default, member or viewer = every enabled seat of the company opens the project with that role unless a direct/team role is set), the statuses and workflow you must use in transition_issue, and your role. board_type: scrum (sprints; parallel_sprints: true means several sprints may run at once, missing/false means one at a time), kanban (continuous flow, no sprints) or pipeline (a delivery pipeline: no sprints; environments lists the delivery environments in order, and each has a testing_<id> "Testing (name)" and a passed_<id> "Passed (name)" status). Always take status ids from here — never guess them. docs is the project's documentation at a glance: count, open_handoffs_for_me (handoffs for you that you have not acknowledged yet) and read_first (the docs the team marked to read first — open each with get_doc using its kind and slug, or call get_docs_context for everything in one text). The company brief and the project docs may describe the team's own workflow and what its statuses mean. Board columns (spec D102): a status may carry meaning (what the team says the column means), color (display only) and source (default, custom = added by the team, environment = a pipeline environment column); wip_limits {status id: max issues} may be set on any board type — a warning, never a block: prefer finishing work in a full column before pulling more in. A status with removing: true is being deleted (its issues are moving to another column): never move or create an issue into it (409 column_removing). Columns are edited in the web app only (Premium) — there is no tool for it. releases: true (any board type, D113/D116) = the project plans releases: read them with list_releases / get_release; my_release_manager says whether your user manages them. Templates and custom fields (spec D129/D130): template is the workflow template the project was created from — scrum / kanban / pipeline (Software delivery, no fields; missing = the board type) or sales_billing (deals are task, installments are subtask with parent = the deal), service_desk (requests are task), budget_planning (budget lines are task), roadmap_goals, feedback_idea_box (eight templates in all). template_settings holds its values (currency — default THB —, awaiting_sign_days, due_soon_days, sla_days, spent_warn_pct). fields lists the project's custom fields: id (the key to use in an issue's fields), name, type (text · number · money · date YYYY-MM-DD · person = user id · select = one of options · url · customer = free text · formula = read-only, its value comes back in each issue's computed), types (issue types it applies to; missing = every type), required, card (shown on the board card), help, source (template | custom). saved_filters are the project's named queries (id, name, scope issues | children, query = search_issues parameters: flag, fields, status, type, assignee …): when the user names one, run search_issues with that query (pass fields as a JSON string). hide_subtasks_on_board: true (Sales & Billing) = installments are rows inside the deal, not cards; default_view = columns | list | timeline. Fields, saved filters and template settings are edited in the web app only (fields beyond the template: Premium) — there is no tool for them. Roadmap & Goals (spec D131, template: roadmap_goals): goals are task (Idea → Planned → In progress → Done, plus Dropped = done but not a success), key results are subtask; fields quarter (Q1–Q4), start + end (required dates), owner, reach / impact / confidence / effort (numbers), score (formula {fn: rice, of: [reach, impact, confidence, effort]} = reach × impact × confidence ÷ effort, 1 decimal), progress and linked (rollup). A field of type rollup is read-only like a formula — its value comes back in each issue's computed — and its rollup says how: from links (filtered by link_types) or children (subtasks), fn progress (mean of the targets' progress: issue in a done-category status = 100 else 0, release = % of its issues past the last gate, shipped = 100) · count (readable targets) · sum / min_date / max_date over field of the targets; targets the reader cannot open are skipped, depth 1. timeline: {start, end, progress} names the date fields (and the progress field) the Timeline layout draws bars from — any template can have it (Fields settings, Premium). saved_filters with value: current on quarter mean the current Bangkok quarter. Feedback / Idea box (spec D143, template: feedback_idea_box): a feed of ideas (task) and bugs (bug) people post; statuses New → Reviewing → Accepted → Shipped, plus Declined (done, but not a success; requires_comment: true). votes_enabled: true (any project can turn it on in settings) = issues carry votes and my_vote; list_sort (rank | created_desc | votes_desc) is the list view's first order; template_settings.area_options are the choices of the area field. Triage rule: Reviewing, Accepted and Declined are the team's call (lane Manager). Agents triage — set area, link duplicates (relates), summarise the top-voted (search_issues order=votes) — and move a post to Reviewing / Accepted / Declined only when the user asks. Moving a project onto this template is web only.

Input Schema

NameRequiredDescriptionDefault
project_keyYesProject key, e.g. `KJ`. 2–10 chars, uppercase letters and digits, starts with a letter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive safety. Beyond that the description discloses real behavior: a status with removing:true returns 409 column_removing if targeted, rollup/formula fields are read-only and surface in each issue's computed, targets the reader cannot open are skipped, depth 1, and that columns, fields, saved filters and template settings are web-app only with no tool for them. That is substantive context the annotations do not carry; it is only held to 4 by the sheer sprawl of the disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Roughly a thousand words for a one-parameter read tool. It is front-loaded with a one-line summary, but everything after is an undifferentiated dump of spec references (D102, D129, D130, D131, D143) and template-by-template workflows, most of which matter only after the call returns and only for specific templates.

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?

With no output schema, the description does need to explain the returned shape, and it does so thoroughly: board_type variants, statuses/meaning/color/wip_limits, fields with their types, saved_filters as search_issues parameters, releases, votes. An agent can interpret the response without a schema. It loses a point because some included material (roadmap RICE formula derivation, feedback triage detail) is not needed to interpret or invoke this tool.

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?

There is a single parameter and schema description coverage is 100% (pattern, length and example all documented in the schema). The description adds nothing about project_key itself, so the schema does all the work — baseline 3 is correct for this configuration.

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 first two lines state the specific verb and resource: fetch project.md with board type, workflow/statuses, custom fields, saved filters and the caller's own role. This is clearly distinct from siblings like get_doc, list_projects or get_issue_context. It stops short of 5 because the actual purpose statement is immediately swallowed by a wall of template-specific detail, so the agent must parse past a lot before it can act.

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?

There is genuine conditional guidance embedded — 'Always take status ids from here — never guess them', 'when the user names one [saved filter], run search_issues with that query', the triage rule that agents move posts to Reviewing/Accepted/Declined only when the user asks. But none of it is framed as when to call get_project versus list_projects or get_issue_context; the guidance is about downstream tools the data feeds, not about this tool's selection.

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