Skip to main content
Glama
ProfessionalWiki

mediawiki-mcp-server

search-page-by-prefix

Read-only

Find MediaWiki pages by title prefix to locate specific content or explore related articles efficiently.

Instructions

Performs a prefix search for page titles.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
prefixYesSearch prefix
limitNoMaximum number of results to return
namespaceNoNamespace to search

Implementation Reference

  • Main handler function `handleSearchPageByPrefixTool` that performs the prefix search using `mwn.getPagesByPrefix`, handles errors, empty results, and formats output using helper.
    async function handleSearchPageByPrefixTool(
    	prefix: string, limit?: number, namespace?: number
    ): Promise< CallToolResult > {
    	let data: string[];
    	try {
    		const mwn = await getMwn();
    		const options: ApiQueryAllPagesParams = {};
    
    		if ( limit ) {
    			options.aplimit = limit;
    		}
    		if ( namespace ) {
    			options.apnamespace = namespace;
    		}
    
    		data = await mwn.getPagesByPrefix( prefix, options );
    	} catch ( error ) {
    		return {
    			content: [
    				{ type: 'text', text: `Failed to retrieve search data: ${ ( error as Error ).message }` } as TextContent
    			],
    			isError: true
    		};
    	}
    
    	if ( data.length === 0 ) {
    		return {
    			content: [
    				{ type: 'text', text: `No pages found with the prefix "${ prefix }"` } as TextContent
    			]
    		};
    	}
    
    	return {
    		content: data.map( getSearchPageByPrefixToolResult )
    	};
    }
  • Zod input schema for tool parameters: `prefix` (string), `limit` (optional number 1-500), `namespace` (optional nonnegative integer).
    prefix: z.string().describe( 'Search prefix' ),
    limit: z.number().int().min( 1 ).max( 500 ).optional().describe( 'Maximum number of results to return' ),
    namespace: z.number().int().nonnegative().optional().describe( 'Namespace to search' )
  • Tool registrar function `searchPageByPrefixTool` calling `server.tool('search-page-by-prefix', ...)` with description, schema, annotations, and handler reference.
    export function searchPageByPrefixTool( server: McpServer ): RegisteredTool {
    	return server.tool(
    		'search-page-by-prefix',
    		'Performs a prefix search for page titles.',
    		{
    			prefix: z.string().describe( 'Search prefix' ),
    			limit: z.number().int().min( 1 ).max( 500 ).optional().describe( 'Maximum number of results to return' ),
    			namespace: z.number().int().nonnegative().optional().describe( 'Namespace to search' )
    		},
    		{
    			title: 'Search page by prefix',
    			readOnlyHint: true,
    			destructiveHint: false
    		} as ToolAnnotations,
    		async (
    			{ prefix, limit, namespace }
    		) => handleSearchPageByPrefixTool( prefix, limit, namespace )
    	);
    }
  • Helper `getSearchPageByPrefixToolResult` to format page title as `TextContent`.
    function getSearchPageByPrefixToolResult( title: string ): TextContent {
    	return {
    		type: 'text',
    		text: title
    	};
    }
  • Import of registrar and addition to `toolRegistrars` array for bulk registration via `registerAllTools`.
    import { searchPageByPrefixTool } from './search-page-by-prefix.js';
    
    const toolRegistrars = [
    	getPageTool,
    	getPageHistoryTool,
    	searchPageTool,
    	setWikiTool,
    	addWikiTool,
    	removeWikiTool,
    	updatePageTool,
    	getFileTool,
    	createPageTool,
    	uploadFileTool,
    	uploadFileFromUrlTool,
    	deletePageTool,
    	getRevisionTool,
    	undeletePageTool,
    	getCategoryMembersTool,
    	searchPageByPrefixTool
    ];
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it's a 'prefix search' which provides useful context about the search behavior, but doesn't elaborate on what that means operationally (e.g., case sensitivity, partial matching rules). No contradiction with annotations exists, but the description could provide more behavioral context beyond what annotations cover.

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 extremely concise - a single sentence that directly states the tool's function. There's no wasted language or unnecessary elaboration. It's front-loaded with the core purpose and doesn't include any extraneous information. This is an excellent example of efficient communication.

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 search tool with good annotations (read-only, non-destructive) and complete parameter documentation in the schema, the description provides the basic purpose but lacks important context. Without an output schema, the description doesn't indicate what results look like (e.g., format, fields returned). It also doesn't address performance considerations, error conditions, or how it differs from the sibling 'search-page' tool, leaving gaps in understanding when this specific tool should be used.

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, all parameters are already documented in the input schema. The description mentions 'prefix search for page titles' which aligns with the 'prefix' parameter but doesn't add meaningful semantic context beyond what the schema provides. The description doesn't explain how the three parameters interact or provide usage examples, so it meets the baseline for good schema coverage.

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 states the action ('performs a prefix search') and resource ('page titles'), making the purpose understandable. However, it doesn't explicitly differentiate from the sibling 'search-page' tool, which appears to be a more general search function. The description is specific about the search type (prefix-based) but doesn't clarify how it differs from the sibling tool.

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 provides no guidance on when to use this tool versus alternatives. With a sibling tool named 'search-page' that likely offers different search capabilities, the description should indicate when prefix search is appropriate versus other search methods. There's no mention of prerequisites, limitations, or comparison with the similar-sounding sibling tool.

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/ProfessionalWiki/MediaWiki-MCP-Server'

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