Skip to main content
Glama
hemanthkandru

taiga-delegate

taiga_update_wiki_page

Update or create a wiki page by slug and replace its Markdown content for a given Taiga project.

Instructions

Update the content of an existing wiki page by slug. Creates it if it doesn't exist.

Input Schema

NameRequiredDescriptionDefault
slugYes
contentYesNew Markdown content.
project_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
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 adds one important trait—it creates the page if it does not exist—but omits permission requirements, whether existing content is fully overwritten, what happens to other page metadata, and what the response looks like.

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 definition is two short sentences with no wasted text. The core action is front-loaded, and the creation fallback follows immediately.

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?

This is a mutation tool with no annotations, no output schema, three required parameters, and incomplete schema coverage. The description discloses the upsert behavior but leaves out consequential details such as permission needs, overwrite behavior, and the undocumented project_id parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%, with only the content parameter documented in the schema. The description mentions updating content by slug, but it does not explain project_id at all and adds little parameter meaning beyond the schema. With low coverage, the description should compensate more than it does.

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 states a specific verb and resource: update the content of an existing wiki page by slug. It also discloses the upsert behavior, which distinguishes it somewhat from a pure update. It does not explicitly contrast with taiga_create_wiki_page, so it is clear but not fully differentiated from its closest sibling.

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?

Usage is implied by 'update the content of an existing wiki page by slug,' and the fallback creation behavior gives some context. However, it does not say when to use this tool versus taiga_create_wiki_page or when an explicit create is preferred. No prerequisites or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.