Skip to main content
Glama

pylon_list_issues

Retrieve a compact list of support issues within a 30-day time range. Get key details quickly and use the issue ID to fetch full information.

Instructions

List issues within a time range (max 30 days). Returns compact table. Use pylon_get_issue for details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
start_timeYesStart time in RFC3339 format (e.g., 2024-01-01T00:00:00Z)
end_timeYesEnd time in RFC3339 format (e.g., 2024-01-31T00:00:00Z)
limitNoNumber of issues to return (1-100, default 25)
cursorNoPagination cursor for next page

Implementation Reference

  • src/index.ts:574-612 (registration)
    Registration of the pylon_list_issues MCP tool with Zod schema for inputs (start_time, end_time, optional limit/cursor) and handler that calls client.listIssues, transforms results via toIssueMinimal, and formats as a markdown table.
    server.tool(
    	'pylon_list_issues',
    	'List issues within a time range (max 30 days). Returns compact table. Use pylon_get_issue for details.',
    	{
    		start_time: z
    			.string()
    			.describe('Start time in RFC3339 format (e.g., 2024-01-01T00:00:00Z)'),
    		end_time: z
    			.string()
    			.describe('End time in RFC3339 format (e.g., 2024-01-31T00:00:00Z)'),
    		limit: z
    			.number()
    			.min(1)
    			.max(100)
    			.optional()
    			.describe(`Number of issues to return (1-100, default ${DEFAULT_ISSUE_LIMIT})`),
    		cursor: z.string().optional().describe('Pagination cursor for next page'),
    	},
    	async ({ start_time, end_time, limit, cursor }) => {
    		const result = await client.listIssues(start_time, end_time, {
    			limit: limit ?? DEFAULT_ISSUE_LIMIT,
    			cursor,
    		});
    
    		// Transform to minimal format to reduce context size
    		const issues = (result.data || []).map((raw) =>
    			toIssueMinimal(raw as unknown as Record<string, unknown>),
    		);
    
    		const table = formatIssuesAsTable(issues);
    		const pagination = result.pagination?.has_next_page
    			? `\n\nMore results available. Use cursor: "${result.pagination.cursor}"`
    			: '';
    
    		return {
    			content: [{ type: 'text', text: table + pagination }],
    		};
    	},
    );
  • Handler function for pylon_list_issues: calls client.listIssues with time range and pagination, maps raw data to minimal issue format using toIssueMinimal, and returns a formatted markdown table with optional pagination cursor.
    async ({ start_time, end_time, limit, cursor }) => {
    	const result = await client.listIssues(start_time, end_time, {
    		limit: limit ?? DEFAULT_ISSUE_LIMIT,
    		cursor,
    	});
    
    	// Transform to minimal format to reduce context size
    	const issues = (result.data || []).map((raw) =>
    		toIssueMinimal(raw as unknown as Record<string, unknown>),
    	);
    
    	const table = formatIssuesAsTable(issues);
    	const pagination = result.pagination?.has_next_page
    		? `\n\nMore results available. Use cursor: "${result.pagination.cursor}"`
    		: '';
    
    	return {
    		content: [{ type: 'text', text: table + pagination }],
    	};
    },
  • Helper function that formats an array of IssueMinimal objects into a compact markdown table with columns: #, Title, State, Created, Link.
    function formatIssuesAsTable(issues: IssueMinimal[]): string {
    	if (issues.length === 0) {
    		return 'No issues found.';
    	}
    
    	const headers = ['#', 'Title', 'State', 'Created', 'Link'];
    	const rows = issues.map((issue) => [
    		escapeCell(String(issue.number ?? '')),
    		escapeCell(truncate(issue.title, MAX_TITLE_LENGTH)),
    		escapeCell(issue.state),
    		escapeCell(issue.created_at?.split('T')[0] || '-'),
    		issue.link || '-',
    	]);
    
    	const headerRow = `| ${headers.join(' | ')} |`;
    	const separatorRow = `|${headers.map(() => '---').join('|')}|`;
    	const dataRows = rows.map((row) => `| ${row.join(' | ')} |`).join('\n');
    
    	return `${headerRow}\n${separatorRow}\n${dataRows}`;
    }
  • Transforms raw API issue response to a minimal IssueMinimal object containing only essential fields (id, number, title, state, link, created_at, assignee_id, account_id, tags) to reduce context size.
    export function toIssueMinimal(raw: Record<string, unknown>): IssueMinimal {
    	return {
    		id: raw['id'] as string,
    		number: raw['number'] as number | undefined,
    		title: raw['title'] as string,
    		state: raw['state'] as string,
    		link: raw['link'] as string | undefined,
    		created_at: raw['created_at'] as string | undefined,
    		assignee_id: extractAssigneeId(raw),
    		account_id: extractAccountId(raw),
    		tags: raw['tags'] as string[] | null | undefined,
    	};
    }
  • PylonClient.listIssues method: validates the time range (max 30 days), builds query params with start_time, end_time, limit, and cursor, then makes a GET request to /issues endpoint.
    async listIssues(
    	startTime: string,
    	endTime: string,
    	params?: PaginationParams,
    ): Promise<PaginatedResponse<Issue>> {
    	validateTimeRange(startTime, endTime);
    	const searchParams = new URLSearchParams();
    	searchParams.set('start_time', startTime);
    	searchParams.set('end_time', endTime);
    	if (params?.limit) searchParams.set('limit', params.limit.toString());
    	if (params?.cursor) searchParams.set('cursor', params.cursor);
    	return this.request<PaginatedResponse<Issue>>(
    		'GET',
    		`/issues?${searchParams.toString()}`,
    	);
    }
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It states the 30-day max constraint and returns a compact table, but omits details on pagination (cursor), error handling for out-of-range dates, rate limits, or permissions. This leaves significant behavioral gaps.

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: the first states purpose and constraint, the second directs to a sibling for details. No wasted words, front-loaded with key information. Highly concise and structured.

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?

The tool lacks an output schema, so the description should clarify the return format (fields, pagination). 'Compact table' is vague; cursor-based pagination is not explained. Compared to sibling list tools, more detail on output structure would improve completeness. Score reflects adequate but incomplete coverage.

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

Parameters4/5

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

The input schema has 100% coverage with descriptions for each parameter. The description adds value by imposing the 30-day time range constraint not present in schema, providing context beyond parameter names. No syntax or format details are added, but the extra constraint justifies a 4.

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 tool lists issues within a time range with a 30-day max, and differentiates from pylon_get_issue by noting it returns a compact table for details. This specificity and sibling distinction earns a 5.

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

Usage Guidelines4/5

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

The description tells when to use (list issues in a time range) and recommends pylon_get_issue for details. However, it does not compare with pylon_search_issues or specify when not to use, so it is clear but not exhaustive.

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/JustinBeckwith/pylon-mcp'

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