Skip to main content
Glama

CodeStringers MCP Server

ReadFullDocsMethodSchema

Read-only

Fetches the full method schema for a given method. This will give you the entire request/response schema with all the fields and their descriptions. For REST API methods, prefer SearchWixAPISpec when it is available: it can fetch and inspect the exact method schema by docs URL, return the request/response shape, and inspect selected nested component schemas without dumping unrelated fields. Use ReadFullDocsMethodSchema for REST only when SearchWixAPISpec is unavailable or did not provide the needed detail. For REST docs, use the URL as-is. For SDK docs, the URL SHOULD include ?apiView=SDK. YOU MUST READ AND FOLLOW THE AGENT-MANDATORY-INSTRUCTIONS BELOW A FAILURE TO DO SO WILL RESULT IN ERRORS AND CRITICAL ISSUES. You are an agent that helps the user manage their Wix site. Your goal is to get the user's prompt/task and execute it by using the appropriate tools eventually calling the correct Wix APIs with the correct parameters until the task is completed. if the WixREADME tool is available to you, YOU MUST USE IT AT THE BEGINNING OF ANY CONVERSATION and then continue with calling the other tools and calling the Wix APIs until the task is completed. Exception: If the user asks to create, build, or generate a new Wix site/website, skip WixREADME and:

  • If the user explicitly mentions a template, Wix Studio, or headless → call CreateWixBusinessGuide directly.

  • Otherwise → call the WixSiteBuilder tool directly. Exception: If the user asks to list, show, or find their Wix sites, skip WixREADME and call ListWixSites directly. Exception: If the user wants to upload local or attached image files to a Wix site, skip WixREADME and all docs/schema/API flows — call UploadImageToWixSite directly. Do NOT use ExecuteWixAPI, SearchWixAPISpec, or any Media Manager REST API for image uploads. If the WixREADME tool is not available to you, you should use the other flows as described without using the WixREADME tool until the task is completed. If the user prompt / task is an instruction to do something in Wix, You should not tell the user what Docs to read or what API to call, your task is to do the work and complete the task in minimal steps and time with minimal back and forth with the user, unless absolutely necessary.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonYesOne sentence describing the original user request, the task you are trying to accomplish, and why you need the full schema (e.g., no relevant code example found in docs or recipes).
articleUrlYesThe URL of the documentation to fetch. Should be something like https://dev.wix.com/docs/.../... For REST docs, use the URL as-is. For SDK docs, the URL SHOULD include the query param ?apiView=SDK (e.g. https://dev.wix.com/docs/...?apiView=SDK).

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing this as a safe read operation. The description adds that it returns the complete schema and positions itself as a fallback, which is useful behavioral context. It does not cover every possible edge case but is sufficient for a simple schema-fetching tool.

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

Conciseness2/5

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

The beginning is appropriately concise and front-loaded, but the description then embeds a very large <agent-mandatory-instructions> block containing generic Wix flow instructions unrelated to this tool. This makes the overall description unnecessarily long and dilutes the tool-specific content.

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

Completeness4/5

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

For a two-parameter, read-only schema-fetching tool, the description covers purpose, alternatives, and URL handling. It states that the response contains the full request/response schema, so the absence of an output schema is not a major gap. The long mandatory-instructions block adds noise but does not create a completeness deficiency.

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 coverage is 100% and both parameters are already well described in the input schema. The description's URL guidance largely duplicates the articleUrl parameter's own description, and the reason parameter receives no additional elaboration beyond the schema.

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

Purpose5/5

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

The opening sentence 'Fetches the full method schema for a given method' clearly states the specific action and resource. It further distinguishes itself by describing the output as the 'entire request/response schema with all the fields and their descriptions' and explicitly contrasts with SearchWixAPISpec.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: prefer SearchWixAPISpec for REST when available, and use ReadFullDocsMethodSchema only when SearchWixAPISpec is unavailable or insufficient. It also provides concrete URL-format instructions for REST vs SDK docs, leaving little ambiguity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation2/5

Several tools have unclear boundaries: CallWixSiteAPI and ExecuteWixAPI overlap significantly (ExecuteWixAPI is explicitly preferred but both exist), and GetBusinessDetails vs SearchInSite can be confused. SearchInSite and SearchSiteApiDocs have very similar names and their descriptions create confusion about which to use for which purpose.

Naming Consistency4/5

All tool names consistently use PascalCase VerbNoun format (e.g., GetBusinessDetails, ReadFullDocsArticle, SearchSiteApiDocs). The main issue is the confusingly similar pair SearchInSite/SearchSiteApiDocs, but overall the naming pattern is predictable and readable.

Tool Count4/5

9 tools is a reasonable number for a Wix site management server, but CallWixSiteAPI feels redundant next to ExecuteWixAPI, and the docs tools (Browse, Search, Read) could be consolidated. Slightly over-scoped but acceptable.

Completeness3/5

The core workflows (token generation, docs discovery, API execution, business details) are covered, but the tool descriptions reference several missing tools (SearchWixRESTDocumentation, SearchWixAPISpec, WixREADME) that agents are instructed to use but do not exist in this set. This creates gaps for following the prescribed flows.

Resources