Autodesk Product Help MCP

by com.autodesk.aps.api

Overview Discussions Admin

Search Help Content

search_help_content

Read-onlyIdempotent

Search Autodesk Help/Support documentation and return the most relevant documents for a user question.

Use when:

The user asks how to do something in an Autodesk product.
The user reports an error (include the exact error text/code in the query).
The user needs official troubleshooting steps or reference documentation.

Call shape (recommended):

Always pass: query, locale.
If your agent has a default product context, pass it directly via product_code (preferred) or product_name.
Pass release_code only when you can validate it for that product.

Behavior:

Locale:
- Read locale from your current context. Do not guess locale.
- Pass that locale as the locale parameter.
Product and release filters (best-effort):
- If your agent already has a default product_code or product_name, pass it directly.
- Only call get_available_products to validate/normalize when: a) product is missing/unknown in context, OR b) the user explicitly specifies a product that may differ from your default, OR c) you have a release_code that may not be valid for the product, OR d) the product/release value appears malformed or not an allowed enum/value.
- If you cannot confidently map to an exact allowed value from get_available_products, omit that field rather than guessing.
- If both product_name and product_code are present, they must refer to the same product; product_code takes precedence.
Query construction:
- Make the query keyword-rich: include product + feature/task nouns.
- Include exact error text/codes when relevant.
- Use the user's wording where possible.
- Do not include secrets, credentials, or personal data.

Returns:

Up to max_results documents sorted by relevance. Each item includes title, url, locale, body, media_type, source (and may include internal IDs for debugging/deduplication).

Input Schema

Name	Required	Description
`query`	Yes	Required. Keyword-rich search text. Include product + task/feature, and exact error codes/messages when relevant. Use the user's wording when possible. Write the query in the same language as `locale`. Maximum 1500 characters. Do not include secrets, credentials, or personal data.
`locale`	Yes	Required. Locale used to scope search/results (language/region). Use the locale from context (do not guess).
`sources`	No	Optional. Restrict which sources to search. Omit to search all. sfdc_articles: support/knowledge-base articles. product_documentation: official product documentation. Choose based on the user question; if unsure, omit.
`max_results`	No	Optional. Maximum number of results to return. Default is 5. Maximum allowed is 50.
`product_code`	No	Optional. Product code filter (preferred). First check your context for product_code, then call `get_available_products` to validate/normalize it. Use only the exact product_code returned by `get_available_products` (do not guess). If provided with product_name, both must refer to the same product.
`product_name`	No	Optional. Product name filter. First check your context for a product name, then call `get_available_products` to validate/normalize it. Use only the exact `product_name` returned by `get_available_products` (do not guess). Prefer product_code if available; if both product_code and product_name are provided, they must match.
`release_code`	No	Optional. Product-specific release identifier (often looks like a year, but may be alphanumeric/variant). First check your context for a release, then call `get_available_products` to validate/normalize it. Only pass an exact `release_code` returned for the resolved product (product_code/product_name). If you cannot validate it, omit release_code rather than guessing.

Output Schema

Name	Required	Description	Default
`results`	Yes	List of search results.
`total_results`	Yes	Total number of results found.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 27, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations, the description discloses cross-parameter precedence ('product_code takes precedence'), the same-product consistency constraint, best-effort filtering semantics, a no-guessing policy, and a safety constraint on query content. Annotations already cover read-only/idempotent, and the description still adds substantial operational context.

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

Conciseness4/5

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

Long but front-loaded and sectioned into Use when / Call shape / Behavior / Returns, so an agent can skim. The Returns bullet partially repeats the output schema and is the one section that does not fully earn its space; a few lines (e.g. the locale step) restate the schema description.

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?

With seven parameters, large enums, a sibling validation tool, and an output schema, the description covers everything needed to call correctly: defaults, precedence, validation escape hatch, query shaping, and locale sourcing. Return-value detail can be left to the output 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?

Schema coverage is 100%, so the baseline would be 3, but the description adds value the schema cannot: query construction strategy (product + feature nouns, exact error text, user wording, language matching locale), what to pass by default, and when to validate product/release values. It supplies genuinely actionable semantics for the two required and three optional filter parameters.

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?

States a specific verb and resource ('Search Autodesk Help/Support documentation') plus the outcome ('return the most relevant documents for a user question'). It is clearly distinguishable from the only sibling, get_available_products, which is referenced as a validation helper rather than an alternate search path.

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?

Explicit 'Use when' list names three concrete trigger scenarios (how-to question, error report, troubleshooting/reference need). It also provides explicit conditions for routing to get_available_products (unknown product, user-specified different product, unvalidated release, malformed value) and tells the agent to omit fields rather than guess.

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

All Autodesk Product Help MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.