Retrieve details of wikis in an Azure DevOps project by providing organization and project identifiers, enabling you to inspect available wikis and their information.
Get details of wikis in a project
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | The ID or name of the project (Default: no default project) | |
| organizationId | No | The ID or name of the organization (Default: example-org) |
Changes observed during successful MCP inspections.
v0.1.54Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about read-only safety, pagination, result size, or return shape. Only the word 'Get' weakly implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no wasted wording, and the scope constraint ('in a project') is present up front. Its brevity is appropriate, though it comes at the cost of specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what 'details' are returned and whether the result is a collection or a single wiki, but it does neither. For a tool with two optional parameters and no annotations, this leaves real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents both parameters at 100% coverage, including defaults for organizationId and the 'ID or name' accepted format, so the description need not compensate. However, it adds no meaning beyond the schema and doesn't clarify that both parameters are optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource ('Get details of wikis in a project'), but 'wikis' plural leaves it ambiguous whether this lists all wikis in a project or returns details of a single wiki. It does not distinguish itself from siblings such as list_wiki_pages, get_wiki_page, or search_wiki.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus list_wiki_pages, get_wiki_page, or search_wiki. The only contextual hint is 'in a project', which is implied by the projectId parameter in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.