Skip to main content
Glama

create_mcp_server

Register a new MCP server for an agent, enabling the agent to use tools exposed by that server. Configure transport (HTTP/stdio) and authentication (bearer, API key, OAuth).

Instructions

Registra um novo MCP server para um agente. O agente poderá usar as tools expostas pelo server.

Transports: 'http' (Streamable HTTP; era do protocolo negociada automaticamente), 'stdio' (local, apenas dev). O 'sse' legado foi descontinuado (migração MCP 2026-07-28).

Combinações auth_method + config:

  • none: config vazio {} (sem autenticação)

  • bearer: { vault_secret_id: "NOME_DO_SECRET" } — o secret contém o token Bearer

  • api_key: { vault_secret_id: "NOME_DO_SECRET", api_key_header: "X-Api-Key" } — header customizável

  • tunnel: config vazio {} — token da plataforma resolvido via env var INTERNAL_TUNNEL_TOKEN (não vault). Usar para MCP servers via Zihin Tunnel

  • oauth: { vault_secret_id: "OAUTH_CREDS", oauth_token_url: "https://..." } — OAuth2 client credentials

Campos opcionais em config: timeout (ms, 1000-120000 — só CONEXÃO + listagem de tools), call_timeout_ms (ms, 1000-120000 — timeout por CHAMADA de tool deste server; omitido = 30s global; alimenta também o teto do executor — doc loop-review/34 F1; retry de timeout é opt-in, não default), headers (object com headers extras), defaults_from_context (object com valores fixos injetados nas tools). Contrato: zihin://schemas/mcp_resource_config.

Input Schema

NameRequiredDescriptionDefault
nameYesNome do MCP server
configNoConfiguração adicional (vault_secret_id, headers, timeout de conexão, call_timeout_ms por chamada de tool)
agent_idYesUUID do agente
endpointYesURL do endpoint ou comando stdio
transportNoTipo de transportehttp
auth_methodNoMétodo de autenticaçãonone
descriptionNoDescrição do server

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.2.2
    • changedInput schema / properties / config / description
      Previous value: -"Configuração adicional (vault_secret_id, headers, timeout)"New value: +"Configuração adicional (vault_secret_id, headers, timeout de conexão, call_timeout_ms por chamada de tool)"
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations declare this is a non-readonly, non-idempotent create. The description goes well beyond that: it specifies per-call vs connection timeout semantics, that timeout retry is opt-in, the default 30s call timeout, and that tunnel tokens are resolved via env var rather than vault. No annotation contradiction.

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?

Front-loaded purpose followed by a well-organized transport line and an auth_method/ config mapping list. Dense but every section earns its place; the parenthetical provenance notes ('doc loop-review/34 F1') add slight noise.

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

Completeness4/5

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

Covers transports, all five auth methods with config shapes, and key optional fields for a 7-param creation tool with no output schema. Missing only a note about required error cases (e.g., duplicate names) or the return value, which is minor.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: the exact config shapes per auth_method (bearer vs api_key vs oauth with required keys), the allowed timeout ranges, and the contract reference 'zihin://schemas/mcp_resource_config'.

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+resource (register a new MCP server for an agent) and adds the consequence ('the agent can then use the tools exposed by the server'). Distinguishes clearly from siblings like update_mcp_server and test_mcp_server.

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?

Provides rich guidance on transport selection (http vs stdio, sse deprecated) and when to use each auth_method (tunnel for Zihin Tunnel, oauth for client credentials). Lacks explicit when-not-to-use framing or routing to update_mcp_server for existing servers, but context is strong.

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