Skip to main content
Glama
Sign In
Agentic Backlog MCP Server

Agentic Backlog MCP Server

by hakenshi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Get project

backlog.get_project

Retrieve project metadata and board summary from the backlog API by providing the project ID.

Instructions

Returns project metadata and board summary from the running backlog API.

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": "backlog.get_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

B3.1/5.0
Behavior3/5

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

Since no annotations are provided, the description carries the full behavioral disclosure burden. It appropriately frames the operation as read-only ('Returns') and states what is returned, but it does not mention error behavior, required project identification, or any API constraints. For a simple getter this is minimally transparent but lacks depth.

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. It front-loads the action and the returned content, making it easy to scan.

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?

For a simple one-parameter retrieval with no output schema, the description states the main return content but omits input semantics and sibling-tool differentiation. It is adequate for basic invocation but leaves meaningful gaps.

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?

Schema description coverage is 0%, and the description never mentions project_id or how it maps to the returned project metadata. With only an integer parameter and no explanatory text, the agent must infer the parameter's meaning from the tool title and schema alone.

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 names the resource ('project metadata and board summary') and the action ('Returns'), so the purpose is evident. However, it does not distinguish this from siblings like get_board or identify_project, which may overlap in scope.

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 gives no explicit guidance on when to use this tool versus alternatives such as list_projects, identify_project, or get_board. The only contextual hint is 'from the running backlog API,' which does not help an agent choose between these related tools.

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

Deploy Server

Other Tools