Skip to main content
Glama
javerthl

ServiceNow MCP Server

by javerthl

publish_article

Publish a knowledge article in ServiceNow by setting its workflow state to published, making the content available to users according to specified workflow version requirements.

Instructions

Publish a knowledge article

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
article_idYesID of the article to publish
workflow_stateNoThe workflow state to setpublished
workflow_versionNoThe workflow version to use

Implementation Reference

  • The core handler function implementing the publish_article tool. It updates the workflow_state of a knowledge article via a PATCH request to the ServiceNow API.
    def publish_article(
        config: ServerConfig,
        auth_manager: AuthManager,
        params: PublishArticleParams,
    ) -> ArticleResponse:
        """
        Publish a knowledge article.
    
        Args:
            config: Server configuration.
            auth_manager: Authentication manager.
            params: Parameters for publishing the article.
    
        Returns:
            Response with the published article details.
        """
        api_url = f"{config.api_url}/table/kb_knowledge/{params.article_id}"
    
        # Build request data
        data = {
            "workflow_state": params.workflow_state,
        }
    
        if params.workflow_version:
            data["workflow_version"] = params.workflow_version
    
        # Make request
        try:
            response = requests.patch(
                api_url,
                json=data,
                headers=auth_manager.get_headers(),
                timeout=config.timeout,
            )
            response.raise_for_status()
    
            result = response.json().get("result", {})
    
            return ArticleResponse(
                success=True,
                message="Article published successfully",
                article_id=params.article_id,
                article_title=result.get("short_description"),
                workflow_state=result.get("workflow_state"),
            )
    
        except requests.RequestException as e:
            logger.error(f"Failed to publish article: {e}")
            return ArticleResponse(
                success=False,
                message=f"Failed to publish article: {str(e)}",
            )
  • Pydantic BaseModel defining the input schema/parameters for the publish_article tool.
    class PublishArticleParams(BaseModel):
        """Parameters for publishing a knowledge article."""
    
        article_id: str = Field(..., description="ID of the article to publish")
        workflow_state: Optional[str] = Field("published", description="The workflow state to set")
        workflow_version: Optional[str] = Field(None, description="The workflow version to use")
  • Tool registration in the central get_tool_definitions() function, associating the tool name with its handler, schema, description, and serialization method.
    "publish_article": (
        publish_article_tool,
        PublishArticleParams,
        str,  # Expects JSON string
        "Publish a knowledge article",
        "json_dict",  # Tool returns Pydantic model
    ),
  • Import of the publish_article handler aliased as publish_article_tool for use in tool registration.
        publish_article as publish_article_tool,
    )
  • Re-export of publish_article from knowledge_base module in tools __init__ for easy access.
    from servicenow_mcp.tools.knowledge_base import (
        create_article,
        create_category,
        create_knowledge_base,
        get_article,
        list_articles,
        list_knowledge_bases,
        publish_article,
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. 'Publish' implies a state change operation, but the description doesn't specify whether this is reversible, what permissions are required, whether it triggers notifications or workflows, or what happens to the article's visibility. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise - a single 4-word phrase. While this is efficient, it's arguably too brief given the tool's complexity (a mutation operation with 3 parameters). Every word earns its place, but more context would be helpful for such an operation.

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?

For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'publishing' means in this context, what the expected outcome is, whether there are side effects, or how this differs from related article operations. The combination of mutation behavior, multiple parameters, and lack of structured metadata demands more descriptive context.

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 three parameters (article_id, workflow_state, workflow_version) with their descriptions. The tool description adds no additional parameter information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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

Purpose3/5

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

The description 'Publish a knowledge article' clearly states the verb ('publish') and resource ('knowledge article'), which is better than a tautology. However, it doesn't distinguish this tool from sibling tools like 'update_article' or 'create_article' - it's unclear what makes publishing different from updating or creating an article in this system.

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. There are multiple article-related tools (create_article, update_article, get_article, list_articles) but no indication of when publishing is appropriate versus updating, or what prerequisites might exist for publishing an article.

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/javerthl/servicenow-mcp'

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