Retrieve exact API documentation for any Marvelous Designer Python function, including overloads, parameter meanings, returns, and source. Get precise reference details without modifying the scene.
Exact API/type documentation, overloads, parameter meanings, returns and source. Does not mutate the MD scene. Requires local index: md-mcp update-docs. Documentation can lag the runtime.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states that the tool is non-mutating, requires a local index, and may return stale information because documentation can lag the runtime. These are valuable and specific behavioral traits. It could go further with error conditions or output size, but it is already strong.
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?
The description is four short sentences with no filler. The first sentence front-loads the core purpose, and the subsequent sentences add essential prerequisites and caveats. Every sentence earns its place.
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?
For a one-parameter, no-output-schema tool, the description covers the purpose, return content, safety profile, prerequisite, and staleness warning. It is missing explicit guidance on selecting between sibling documentation tools and the exact semantics of 'name', but overall it is sufficient for an agent to use the tool correctly in most situations.
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?
Schema coverage is 0%, so the description must compensate. The single parameter 'name' is implicitly the API/type name to look up, and the listed content types clarify what is retrieved. However, the description does not specify the expected format, namespace, or whether the name must be exact or can be a partial match.
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 clearly specifies the resource: exact API/type documentation including overloads, parameter meanings, returns, and source. It also clarifies a key behavioral trait by saying it does not mutate the MD scene. However, it lacks an explicit verb such as 'fetch' or 'return', and it does not explicitly distinguish itself from sibling tools like search_md_docs.
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?
The description gives an important prerequisite ('Requires local index: md-mcp update-docs') and a caveat about documentation lagging the runtime, which helps agents decide whether to rely on it. It does not mention alternative tools, when-not-to-use, or how to choose between this and search_md_docs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.