Skip to main content
Glama
Tiberriver256

Azure DevOps MCP Server

create_wiki_page

Create or update wiki pages in Azure DevOps to document processes, share knowledge, and maintain project documentation using markdown content.

Instructions

Create a new page in a wiki. If the page already exists at the specified path, it will be updated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
organizationIdNoThe ID or name of the organization (Default: mycompany)
projectIdNoThe ID or name of the project (Default: MyProject)
wikiIdYesThe ID or name of the wiki
pagePathNoPath of the wiki page to create. If the path does not exist, it will be created. Defaults to the wiki root (/). Example: /ParentPage/NewPage/
contentYesThe content for the new wiki page in markdown format
commentNoOptional comment for the creation or update

Implementation Reference

  • The core handler function that implements the logic to create or update a wiki page in Azure DevOps using the wiki client or direct API call.
    export const createWikiPage = async (
      params: z.infer<typeof CreateWikiPageSchema>,
      client?: {
        defaults?: { organizationId?: string; projectId?: string };
        put: (
          url: string,
          data: Record<string, unknown>,
        ) => Promise<{ data: unknown }>;
      }, // For testing purposes only
    ) => {
      try {
        const { organizationId, projectId, wikiId, pagePath, content, comment } =
          params;
    
        // For testing mode, use the client's defaults
        if (client && client.defaults) {
          const org = organizationId ?? client.defaults.organizationId;
          const project = projectId ?? client.defaults.projectId;
    
          if (!org) {
            throw new Error(
              'Organization ID is not defined. Please provide it or set a default.',
            );
          }
    
          // This branch is for testing only
          const apiUrl = `${org}/${
            project ? `${project}/` : ''
          }_apis/wiki/wikis/${wikiId}/pages?path=${encodeURIComponent(
            pagePath ?? '/',
          )}&api-version=7.1-preview.1`;
    
          // Prepare the request body
          const requestBody: Record<string, unknown> = { content };
          if (comment) {
            requestBody.comment = comment;
          }
    
          // Make the API request
          const response = await client.put(apiUrl, requestBody);
          return response.data;
        } else {
          // Use default organization and project if not provided
          const org = organizationId ?? defaultOrg;
          const project = projectId ?? defaultProject;
    
          if (!org) {
            throw new Error(
              'Organization ID is not defined. Please provide it or set a default.',
            );
          }
    
          // Create the client
          const wikiClient = await azureDevOpsClient.getWikiClient({
            organizationId: org,
          });
    
          // Prepare the wiki page content
          const wikiPageContent = {
            content,
          };
    
          // This is the real implementation
          return await wikiClient.updatePage(
            wikiPageContent,
            project,
            wikiId,
            pagePath ?? '/',
            {
              comment: comment ?? undefined,
            },
          );
        }
      } catch (error: unknown) {
        throw await handleRequestError(
          error,
          'Failed to create or update wiki page',
        );
      }
    };
  • Zod schema defining the input parameters and validation for the create_wiki_page tool.
    export const CreateWikiPageSchema = z.object({
      organizationId: z
        .string()
        .optional()
        .nullable()
        .describe(`The ID or name of the organization (Default: ${defaultOrg})`),
      projectId: z
        .string()
        .optional()
        .nullable()
        .describe(`The ID or name of the project (Default: ${defaultProject})`),
      wikiId: z.string().min(1).describe('The ID or name of the wiki'),
      pagePath: z
        .string()
        .optional()
        .nullable()
        .default('/')
        .describe(
          'Path of the wiki page to create. If the path does not exist, it will be created. Defaults to the wiki root (/). Example: /ParentPage/NewPage',
        ),
      content: z
        .string()
        .min(1)
        .describe('The content for the new wiki page in markdown format'),
      comment: z
        .string()
        .optional()
        .describe('Optional comment for the creation or update'),
    });
  • MCP tool definition registration specifying the name, description, and input schema for create_wiki_page.
    {
      name: 'create_wiki_page',
      description:
        'Create a new page in a wiki. If the page already exists at the specified path, it will be updated.',
      inputSchema: zodToJsonSchema(CreateWikiPageSchema),
    },
  • Dispatch/registration in the wikis request handler that parses arguments and calls the createWikiPage handler.
    case 'create_wiki_page': {
      const args = CreateWikiPageSchema.parse(request.params.arguments);
      const result = await createWikiPage({
        organizationId: args.organizationId ?? defaultOrg,
        projectId: args.projectId ?? defaultProject,
        wikiId: args.wikiId,
        pagePath: args.pagePath,
        content: args.content,
        comment: args.comment,
      });
      return {
        content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
      };
    }
Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses the key behavioral trait that existing pages at the same path will be updated (upsert behavior), which is valuable. However, it doesn't mention permissions needed, rate limits, whether changes are reversible, or what the response looks like, leaving gaps for a mutation tool.

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. The first states the core purpose, the second adds crucial behavioral context about update-on-conflict. Every word earns its place, and the most important information is front-loaded.

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 mutation tool with no annotations and no output schema, the description is adequate but incomplete. It covers the upsert behavior well but lacks information about permissions, response format, error conditions, or how it differs from sibling tools like 'update_wiki_page'. Given the complexity, more context would be helpful.

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%, so the schema already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema (like explaining path hierarchy or content format). Baseline 3 is appropriate when schema does the heavy lifting.

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 ('Create a new page in a wiki') and resource ('wiki page'), which is specific and unambiguous. However, it doesn't explicitly differentiate from its sibling 'update_wiki_page' or 'create_wiki', though the 'create or update' behavior mentioned provides some implicit distinction.

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 when to use it (for creating wiki pages) and mentions the update-on-conflict behavior, but doesn't provide explicit guidance on when to choose this over 'update_wiki_page' or 'create_wiki'. No prerequisites, exclusions, or alternatives are stated, leaving usage context somewhat implied.

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/Tiberriver256/mcp-server-azure-devops'

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