Skip to main content
Glama
useshortcut

Shortcut MCP Server

Official
by useshortcut

documents-search

Search for documents in Shortcut project management by title, archived status, or user association to locate specific project files.

Instructions

Find documents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nextPageTokenNoIf a next_page_token was returned from the search result, pass it in to get the next page of results. Should be combined with the original search parameters.
titleYesFind documents matching the specified name
archivedNoFind only documents matching the specified archived status
createdByCurrentUserNoFind only documents created by current user
followedByCurrentUserNoFind only documents followed by current user

Implementation Reference

  • The handler function that executes the core logic for the 'documents-search' tool. It calls the ShortcutClientWrapper's searchDocuments method, processes the response (including pagination), handles empty results and errors, and formats the output using toResult.
    private async searchDocuments(
    	params: {
    		title: string;
    		archived?: boolean;
    		createdByCurrentUser?: boolean;
    		followedByCurrentUser?: boolean;
    	},
    	nextPageToken?: string,
    ) {
    	try {
    		const { documents, total, next_page_token } = await this.client.searchDocuments({
    			...params,
    			nextPageToken,
    		});
    
    		if (!documents) throw new Error(`Failed to search for document matching your query.`);
    		if (!documents.length) return this.toResult(`Result: No documents found.`);
    
    		return this.toResult(
    			`Result (${documents.length} shown of ${total} total documents found):`,
    			documents,
    			next_page_token,
    		);
    	} catch (error) {
    		const errorMessage = error instanceof Error ? error.message : "Unknown error";
    		return this.toResult(`Failed to search documents: ${errorMessage}`);
    	}
    }
  • Registers the 'documents-search' tool using server.addToolWithReadAccess, specifying the tool name, description, input schema, and the inline handler that delegates to the searchDocuments method.
    server.addToolWithReadAccess(
    	"documents-search",
    	"Find documents.",
    	{
    		nextPageToken: z
    			.string()
    			.optional()
    			.describe(
    				"If a next_page_token was returned from the search result, pass it in to get the next page of results. Should be combined with the original search parameters.",
    			),
    		title: z.string().describe("Find documents matching the specified name"),
    		archived: z
    			.boolean()
    			.optional()
    			.describe("Find only documents matching the specified archived status"),
    		createdByCurrentUser: z
    			.boolean()
    			.optional()
    			.describe("Find only documents created by current user"),
    		followedByCurrentUser: z
    			.boolean()
    			.optional()
    			.describe("Find only documents followed by current user"),
    	},
    	async ({ nextPageToken, title, archived, createdByCurrentUser, followedByCurrentUser }) =>
    		await tools.searchDocuments(
    			{ title, archived, createdByCurrentUser, followedByCurrentUser },
    			nextPageToken,
    		),
    );
  • Zod-based input schema for the 'documents-search' tool, defining parameters like title (required), and optional fields for pagination, archived status, and user-specific filters.
    {
    	nextPageToken: z
    		.string()
    		.optional()
    		.describe(
    			"If a next_page_token was returned from the search result, pass it in to get the next page of results. Should be combined with the original search parameters.",
    		),
    	title: z.string().describe("Find documents matching the specified name"),
    	archived: z
    		.boolean()
    		.optional()
    		.describe("Find only documents matching the specified archived status"),
    	createdByCurrentUser: z
    		.boolean()
    		.optional()
    		.describe("Find only documents created by current user"),
    	followedByCurrentUser: z
    		.boolean()
    		.optional()
    		.describe("Find only documents followed by current user"),
    },
  • Supporting method in ShortcutClientWrapper that performs the actual API call to Shortcut's searchDocuments endpoint, maps parameters, handles feature access errors, extracts pagination token, and returns structured results.
    async searchDocuments({
    	title,
    	archived,
    	createdByCurrentUser,
    	followedByCurrentUser,
    	pageSize = 25,
    	nextPageToken,
    }: {
    	title: string;
    	archived?: boolean;
    	createdByCurrentUser?: boolean;
    	followedByCurrentUser?: boolean;
    	pageSize?: number;
    	nextPageToken?: string;
    }) {
    	const response = await this.client.searchDocuments({
    		title,
    		archived,
    		created_by_me: createdByCurrentUser,
    		followed_by_me: followedByCurrentUser,
    		page_size: pageSize,
    		next: nextPageToken,
    	});
    
    	if (response.status === 403) throw new Error("Docs feature disabled for this workspace.");
    
    	const documents = response?.data?.data;
    	const total = response?.data?.total;
    	const next = response?.data?.next;
    
    	if (!documents) return { documents: null, total: null, next_page_token: null };
    
    	return { documents, total, next_page_token: this.getNextPageToken(next) };
    }
  • Utility method from BaseTools used to format tool responses as MCP CallToolResult, embedding JSON data and pagination tokens in text content.
    protected toResult(
    	message: string,
    	data?: unknown,
    	paginationToken?: string | null | undefined,
    ): CallToolResult {
    	return {
    		content: [
    			{
    				type: "text",
    				text: `${message}${data !== undefined ? `\n\n<json>\n${JSON.stringify(data, null, 2)}\n</json>${paginationToken ? `\n\n<next-page-token>${paginationToken}</next-page-token>` : ""}` : ""}`,
    			},
    		],
    	};
    }
Behavior1/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Find documents' reveals nothing about whether this is a read-only operation, whether it has pagination (though the schema hints at it with nextPageToken), rate limits, authentication requirements, or what the response format looks like. For a search tool with 5 parameters and no output schema, this is critically inadequate.

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 maximally concise at just two words. While this represents severe under-specification, from a pure conciseness perspective it's efficient with zero wasted words. Every word in 'Find documents' serves a purpose, even if that purpose is insufficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (5 parameters, no annotations, no output schema) and the presence of multiple sibling tools, the description is completely inadequate. It doesn't explain what the tool returns, how results are structured, when to use it versus documents-list, or any behavioral characteristics. For a search tool in this context, the description fails to provide the necessary context for effective tool selection and invocation.

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?

The schema description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds absolutely no information about parameters beyond what's already in the schema. Since the schema does the heavy lifting, the baseline score of 3 is appropriate - the description neither helps nor hurts parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Find documents' is a tautology that essentially restates the tool name 'documents-search'. It provides no specific information about what kind of documents, what scope, or what distinguishes this search from the sibling 'documents-list' tool. While it uses a clear verb ('Find'), it lacks any meaningful elaboration on the resource or context.

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

Usage Guidelines1/5

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

The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple sibling tools that could be relevant (documents-list, stories-search, epics-search, etc.), but the description offers no context about when this specific search tool is appropriate versus a list operation or other search tools. This leaves the agent guessing about the tool's intended use case.

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/useshortcut/mcp-server-shortcut'

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