rogue-blender-mcp

Overview Schema Source Related Servers Discussions Admin

get_python_api_docs

Read-only

Fetch Blender Python API docs by identifier, supporting wildcard patterns to list modules and children. Returns exact RST content, definitions, or suggestions when no match is found.

Instructions

Return the Blender Python API docs for identifier, or list modules matching a trailing-* discovery pattern.

identifier should be a fully-qualified Python name (e.g. bpy.app or bpy.types.Scene.frame_current). The trailing-* forms are supported as discovery entry-points:

* enumerates the top-level modules (bpy, bmesh, mathutils, gpu, ...).
X.* enumerates the direct-child identifiers under the X namespace (bpy.* -> bpy.app, bpy.context, ...).

Both return a namespace response even when X.rst would otherwise resolve to exact; the .* form lets an agent force the child listing.

The response always carries kind, found, and identifier. The remaining keys depend on kind:

"exact" (found=True): <identifier>.rst was read. Extra keys: content (RST text), examples. When the file exceeds 32 KB, content is replaced with a dot-point summary of the file's top-level definitions (prefixed by a header noting the truncation) and examples is empty - re-query individual members for their rendered blocks.
"namespace" (found=True): no <identifier>.rst but <identifier>.<child>.rst siblings exist. Extra key: submodules (list of child identifiers).
"definition" (found=True): identifier is defined inside a parent RST (e.g. bpy.props.IntProperty lives in bpy.props.rst). Extra keys: content (rendered block), examples.
"partial" (found=False): the parent RST was located but the trailing component isn't defined in it. Extra keys:
- parent the identifier whose RST was loaded.
- available top-level definitions in that RST.
- submodules sibling identifiers <parent>.<child> with their own RSTs, filtered to those whose last component contains every character of the missing tail.
For a toctree landing page like bpy.types available is empty and submodules is the near-miss list; for a self-contained module like bpy.props it's the reverse.
"suggestions" (found=False): no direct match, but identifier appears as a component of other files. Extra key: suggestions (list of full identifiers).
"missing" (found=False): nothing matched.

examples (present on the exact and definition kinds) is a list of {path, content} entries referenced from this documentation.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`identifier`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description goes far beyond the readOnlyHint annotation by detailing the six response kinds (exact, namespace, definition, partial, suggestions, missing), the truncation rule for files over 32 KB, and the structure of each response. This is comprehensive behavioral disclosure that fully prepares the agent for what to expect.

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?

Although long, the description is tightly organized with bullet points, code formatting, and a logical flow from purpose to response kinds. Every sentence contributes essential information, and the front-loaded summary of purpose and patterns is immediately actionable. No filler or redundancy.

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

Completeness5/5

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

For a tool with multiple response kinds, edge cases, and a large-file truncation rule, the description covers every aspect an agent needs to invoke it correctly and interpret results. The presence of an output schema does not detract; the description adds the necessary semantic context beyond the schema.

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

Parameters5/5

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

With schema description coverage at 0%, the description carries the full burden of explaining the parameter. It thoroughly describes the identifier format, the meaning of trailing-* patterns, and provides examples (bpy.app, bpy.types.Scene.frame_current). This is exemplary compensation for the missing schema documentation.

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 description clearly states the tool's function: 'Return the Blender Python API docs for *identifier*, or list modules matching a trailing-* discovery pattern.' This is a specific verb and resource, and the distinction from sibling search_api_docs is evident—this tool targets exact identifiers and discovery patterns, not free-text search.

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

Usage Guidelines4/5

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

The description provides detailed guidance on how to format the identifier (fully-qualified Python name, trailing-* patterns) and explains the behavior of each pattern. However, it does not explicitly state when to prefer this tool over alternatives like search_api_docs, leaving the when-not-to-use guidance implicit. The context is clear but lacks explicit exclusions.

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

Deploy Server