Skip to main content
Glama

List Issue Notes

list_notes
Read-onlyIdempotent

Retrieve comments attached to a MantisBT issue without fetching the full issue data. Use to access notes independently when you only need comment information.

Instructions

List all notes (comments) attached to a MantisBT issue. Note: get_issue already includes notes in its response — use list_notes only when you need notes without fetching the full issue.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
issue_idYesNumeric issue ID

Implementation Reference

  • The handler logic for the 'list_notes' tool, which fetches notes from a specific MantisBT issue.
    async ({ issue_id }) => {
      try {
        const result = await client.get<{ issues: Array<{ notes?: MantisNote[] }> }>(`issues/${issue_id}`);
        const notes = result.issues?.[0]?.notes ?? [];
        return {
          content: [{ type: 'text', text: JSON.stringify(notes, null, 2) }],
        };
      } catch (error) {
        const msg = error instanceof Error ? error.message : String(error);
        return { content: [{ type: 'text', text: errorText(msg) }], isError: true };
      }
    }
  • The input schema for the 'list_notes' tool.
    inputSchema: z.object({
      issue_id: z.coerce.number().int().positive().describe('Numeric issue ID'),
    }),
  • The registration of the 'list_notes' tool in the McpServer.
    server.registerTool(
      'list_notes',
      {
        title: 'List Issue Notes',
        description: 'List all notes (comments) attached to a MantisBT issue. Note: get_issue already includes notes in its response — use list_notes only when you need notes without fetching the full issue.',
        inputSchema: z.object({
          issue_id: z.coerce.number().int().positive().describe('Numeric issue ID'),
        }),
        annotations: {
          readOnlyHint: true,
          destructiveHint: false,
          idempotentHint: true,
        },
      },
      async ({ issue_id }) => {
        try {
          const result = await client.get<{ issues: Array<{ notes?: MantisNote[] }> }>(`issues/${issue_id}`);
          const notes = result.issues?.[0]?.notes ?? [];
          return {
            content: [{ type: 'text', text: JSON.stringify(notes, null, 2) }],
          };
        } catch (error) {
          const msg = error instanceof Error ? error.message : String(error);
          return { content: [{ type: 'text', text: errorText(msg) }], isError: true };
        }
      }
    );
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about data overlap with get_issue (behavioral relationship), but does not disclose additional execution details like error handling for invalid issue_ids, return format, or ordering of results.

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?

Two sentences with zero waste. First sentence establishes purpose; second sentence provides critical usage guidance. Perfectly front-loaded with no redundant information.

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?

Given the simple single-parameter read-only operation and comprehensive annotations, the description is nearly complete. Minor gap: does not specify behavior when issue_id is not found (empty array vs error), but this is acceptable for a lightweight list operation.

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?

With 100% schema description coverage ('Numeric issue ID'), the schema fully documents the single parameter. The description does not add semantic details beyond the schema, meeting the baseline for high-coverage schemas.

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 clearly states the specific verb (List), resource (notes/comments), and scope (attached to a MantisBT issue). It effectively distinguishes itself from sibling tools by clarifying its specific focus on notes retrieval.

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?

Excellent guidance provided: explicitly names the alternative tool (get_issue) and states exactly when to use list_notes instead ('only when you need notes without fetching the full issue'). This prevents redundant API calls.

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/dpesch/mantisbt-mcp-server'

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