Skip to main content
arrow-left Back to Docusign.com
Question

OAuth discovery for DocuSign MCP: /.well-known/oauth-authorization-server returns HTML

  • May 5, 2026
  • 1 reply
  • 14 views
J
Newcomer
Forum|alt.badge.img

Hi everyone,

I'm trying to connect to the DocuSign hosted MCP server (mcp-d.docusign.com/mcp) from an MCP client that follows the standard OAuth discovery flow, and I'm seeing what looks like an RFC 8414 deviation that I'd like to confirm before assuming it's an issue.

The flow my client is doing is:

  1. Fetch https://mcp-d.docusign.com/.well-known/oauth-protected-resource. Returns 200 JSON, lists https://account-d.docusign.com as the authorization server.
  2. Per RFC 8414, fetch https://account-d.docusign.com/.well-known/oauth-authorization-server for the AS metadata. This is where I'd expect a JSON metadata document.


What I see at step 2:
 

$ curl -sSL -i https://account-d.docusign.com/.well-known/oauth-authorization-server 
HTTP/2 200 
content-type: text/html; charset=utf-8 

<!DOCTYPE html> <html lang="en" class="account-server"> ... 200 OK with text/html


which the client then tries to parse as JSON and fails with:
 

Unexpected token '<', "<!DOCTYPE "... is not valid JSON


Same response on production (account.docusign.com).

I noticed https://account-d.docusign.com/.well-known/openid-configuration returns valid JSON with the same authorization_endpoint and token_endpoint values, but I wanted to ask:

  1. Is the HTML response at /.well-known/oauth-authorization-server intentional? Should clients be using /openid-configuration instead?
  2. If RFC 8414 metadata isn't supported, would a 404 there be possible? That would let clients fall back to OIDC discovery cleanly without misinterpreting the HTML as a successful response.
  3. I noticed claude.ai connects to the DocuSign MCP successfully. Does anyone know which discovery method that client uses?
  4. Is there documentation I missed that recommends one discovery endpoint over the other for MCP/OAuth clients connecting to DocuSign? Thanks for any pointers.

1 reply

B
Newcomer
Forum|alt.badge.img
  • bseeNewcomer
  • Newcomer
  • May 7, 2026

+1 on this issue.

https://mcp.docusign.com/.well-known/oauth-protected-resource returns
 

{"resource":"https://mcp.docusign.com/mcp","resource_name":"Docusign MCP","authorization_servers":["https://account.docusign.com"],"bearer_methods_supported":["header"],"scopes_supported":["signature","click.manage","me_profile","room_forms","inproductcommunication_read","data_explorer_signing_insights","notary_read","notary_write","search_read","search_write","webforms_manage","dtr","valmod_manage","models_esign_manage","ad_read","models_read","aow_manage","account_read","adm_entity_transactions_read","adm_entity_transactions_write","act_read","addon_management_api","adm_store_unified_repo_write","adm_store_unified_repo_read","public_dms_document_read","agreement_object_model_read","cds_read","addon_events_consuming","user_read","group_read","document_uploader_write","document_uploader_read","models_write","dcf_read","dcf_write","act_execute","act_write","audit_log_read","spring_read","ai_jobs_engine_read","ai_jobs_engine_write","provision_account_plan_items","cds_write","account_product_read","spring_write","setting_service_read","setting_service_write","clause_read","clause_write","webforms_instance_write","pi_read","one_ds_ai_read","iam_folders_read","iam_folders_write"],"resource_documentation":"https://developers.docusign.com/tools/mcp-server/"}

 

And per the RFC, it will fetch https://account.docusign.com/.well-known/oauth-authorization-server for authorization server metadata. This website returns HTML instead of JSON.

The fix is to have https://mcp.docusign.com/.well-known/oauth-protected-resource return ["https://mcp.docusign.com"] in the authorization server list.

Code of ConductAccessibility statement

Docusign Community

Code of Conduct