Skip to main content
Glama
AIWerk

@aiwerk/mcp-server-elevenlabs

by AIWerk

create_auth_connection

Create a workspace authentication connection by defining credentials, JWT/OAuth2 settings, and token exchange parameters for ElevenLabs API requests.

Instructions

Create Workspace Auth Connection

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
tokenNo
issuerNoJWT issuer (iss claim)
key_idNo
scopesNoOAuth2 scopes to request when exchanging JWT for access token
subjectNoJWT subject (sub claim)
audienceNoJWT audience (aud claim)
passwordNo
providerNo
usernameNo
algorithmNoJWT signing algorithm
auth_typeNo
client_idNo
token_urlNoToken endpoint URL for exchanging JWT for access token
client_keyNo
secret_keyNo
header_nameNoThe name of the header to use for authentication (e.g., 'x-api-key')
extra_paramsNoAdditional custom claims to include in the JWT
client_secretNo
ca_certificateNo
custom_headersNo
key_passphraseNo
client_certificateNo
expiration_secondsNoToken expiration time in seconds
basic_auth_in_headerNoIf True, send client credentials in Authorization header as Basic Auth instead of request body
token_response_fieldNoToken field to extract from the token endpoint response.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

D1.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, which tells the agent this is a non-idempotent write reaching external systems. The description adds nothing on top of that: it does not mention that credentials or secret material are being persisted, that missing parameters may cause failures, or that repeats will create duplicates (non-idempotent). No contradiction, but no added value either.

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 single short phrase is technically concise and front-loaded, but this is under-specification rather than efficiency. Given the complexity of the operation, the brevity is a defect, not a virtue.

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

Completeness1/5

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

For a 26-parameter, zero-required mutation tool with no output schema and only partial annotation coverage, this description is completely inadequate. It cannot help an agent decide which of the mutually exclusive credential parameters (token, username/password, client_id/client_secret, secret_key) to use for a given auth_type.

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

Parameters1/5

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

With 26 parameters and only 42% schema description coverage, the description carries a heavy compensation burden, yet it names zero parameters. Fields like auth_type, provider, token_url, and the many credential options are left entirely undocumented in prose, so an agent must guess which fields to supply for a given auth method.

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

Purpose2/5

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

The description 'Create Workspace Auth Connection' is essentially a restatement of the tool name create_auth_connection with the word 'Workspace' added. It names a verb and a resource, but adds no distinguishing scope and does nothing to separate it from siblings like update_auth_connection, delete_auth_connection, or list_auth_connections. This is tautological rather than clarifying.

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

Usage Guidelines2/5

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

There is no guidance whatsoever on when to use this tool, when to prefer update_auth_connection, or what prerequisites (credentials, provider selection, scopes) are needed. The description gives the agent no routing or context information at all.

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

Deploy Server

Other Tools