Skip to main content
Glama

get_page_by_path

Retrieve a specific WikiJS page by providing its path and locale, enabling precise content access within WikiJS knowledge bases.

Instructions

Get a WikiJS page by its path and locale

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
localeYesThe locale of the page (e.g., "en")
pathYesThe path of the page to retrieve

Implementation Reference

  • Factory function createGetPageByPathTool that returns the tool handler executing the get_page_by_path logic: extracts path/locale, calls wikiClient.getPageByPath, returns JSON content or error.
    export const createTool = (wikiClient: WikiJSClient): ToolCallback<typeof PARAMETERS> => {
    	return 	async (request) => {
    		try {
    			const { path, locale } = request;
    
    			const result = await wikiClient.getPageByPath(path, locale);
    
    			return {
    				content: [
    					{
    						type: 'text',
    						text: JSON.stringify(result, null, 2)
    					}
    				]
    			};
    		} catch (error) {
    			const errorMessage = error instanceof Error ? error.message : String(error);
    			return {
    				content: [
    					{
    						type: 'text',
    						text: `Error getting page by path: ${errorMessage}`
    					}
    				],
    				isError: true
    			};
    		}
    	}
    }
  • Zod schema defining input parameters for the get_page_by_path tool: path (string) and locale (string with format validation).
    export const PARAMETERS = {
    	path: z.string().describe('The path of the page to retrieve'),
    	locale: z.string().regex(/^[a-z]{2}(-[A-Z]{2})?$/, 'Invalid locale format').describe('The locale of the page (e.g., "en")')
    }
  • src/mcp/index.ts:54-59 (registration)
    Registration of the get_page_by_path tool on the MCP server using server.tool, providing name, description, parameters schema, and handler factory.
    server.tool(   
        'get_page_by_path',
        'Get a WikiJS page by its path and locale',
        GET_PAGE_BY_PATH_TOOL_PARAMETERS,
        createGetPageByPathTool(this.wikiClient)
    );
  • WikiJSClient helper method getPageByPath that invokes the GraphQL SDK to fetch the page by path and locale, used by the tool handler.
    async getPageByPath(path: string, locale: string) {
      const result = await this.sdk.GetPageByPath({ path, locale });
      return result.pages?.singleByPath || null;
    }
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a page but lacks details on permissions required, error handling (e.g., if page not found), response format, or any rate limits. This is a significant gap for a tool with no annotation coverage.

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, efficient sentence with zero waste—it directly states the tool's purpose and key parameters. It's appropriately sized and front-loaded, making it easy to understand at a glance.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., page content, metadata), error conditions, or behavioral traits. For a retrieval tool with two required parameters, this leaves critical gaps in understanding how to use it effectively.

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?

Schema description coverage is 100%, with clear descriptions for both parameters (path and locale). The description adds minimal value beyond the schema by mentioning these parameters but doesn't provide additional context like examples or constraints beyond what's already documented in the schema.

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 verb ('Get') and resource ('a WikiJS page'), specifying retrieval by path and locale. It distinguishes from sibling tools like get_page_by_id (retrieves by ID) and get_all_pages (lists all pages), but doesn't explicitly differentiate from search_pages, which might also retrieve pages based on criteria.

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

Usage Guidelines3/5

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

The description implies usage when you know the exact path and locale of a page, but provides no explicit guidance on when to use this tool versus alternatives like get_page_by_id or search_pages. No prerequisites, exclusions, or comparative context are mentioned.

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

Related 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/RicardoCenci/wikijs-mcp'

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