Skip to main content
Glama

HubSpot

set_hubspot
Idempotent

Conecta o link permanente já publicado ao HubSpot. Uma conexão por link, method oauth ou private_app; conectar por um método substitui o outro. OAuth: authorize:true devolve authorizeUrl (503 config_missing sem HUBSPOT_CLIENT_ID e HUBSPOT_CLIENT_SECRET); o usuário autoriza e o retorno traz code e state. App privado: token pat-… (Development → Legacy apps → Private → Auth → Show token). Escopos dos dois: crm.objects.contacts.read, crm.objects.contacts.write, crm.schemas.contacts.read e crm.schemas.contacts.write. Cada lead.created busca o contato pelo e-mail e atualiza só as propriedades mapeadas, ou cria se não existir. O e-mail fica na propriedade email. O padrão manda nome, telefone E.164, tour, UTMs e o texto e a data do consentimento LGPD em propriedades guiaflow_*. mapping troca o nome interno; string vazia desliga o campo. A credencial fica cifrada e a resposta só traz tokenLast4, method e oauthAvailable. remove:true apaga (OAuth revoga o refresh). sendTest:true grava o contato teste@guiaflow.pro. Falhas usam a mesma fila e o mesmo corte de 20 tentativas do webhook.

Input Schema

NameRequiredDescriptionDefault
codeNoCódigo OAuth devolvido pelo HubSpot. Use junto com state. Substitui um token de app privado.
stateNostate da authorizeUrl. Amarra o code a este tour.
tokenNoToken do app privado do HubSpot (pat-…). Substitui uma conexão OAuth. A resposta nunca devolve o token inteiro.
removeNo
tourIdYesid do tour (de create_tour ou list_tours).
enabledNo
mappingNoNome interno da propriedade no HubSpot para cada campo. Padrão guiaflow_* . Escopos do app: crm.objects.contacts.read crm.objects.contacts.write crm.schemas.contacts.read crm.schemas.contacts.write.
sendTestNoCria ou atualiza o contato teste@guiaflow.pro.
authorizeNoDevolve authorizeUrl, redirectUri e scopes. Não conecta. 503 se o OAuth não está configurado.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / authorize / description
      Previous value: -"Devolve authorizeUrl, redirectUri e scopes. Não conecta."New value: +"Devolve authorizeUrl, redirectUri e scopes. Não conecta. 503 se o OAuth não está configurado."
    • changedInput schema / properties / code / description
      Previous value: -"Código OAuth devolvido pelo HubSpot. Use junto com state."New value: +"Código OAuth devolvido pelo HubSpot. Use junto com state. Substitui um token de app privado."
    • changedInput schema / properties / mapping / description
      Previous value: -"Nome interno da propriedade no HubSpot para cada campo. Padrão guiaflow_* . Escopos do app: crm.objects.contacts.write crm.schemas.contacts.write."New value: +"Nome interno da propriedade no HubSpot para cada campo. Padrão guiaflow_* . Escopos do app: crm.objects.contacts.read crm.objects.contacts.write crm.schemas.contacts.read crm.schemas.contacts.write."
    • removedInput schema / properties / mapping / properties / email
      Removed value: -{
      -  "type": "string"
      -}
    • addedInput schema / properties / token
      Added value: +{
      +  "description": "Token do app privado do HubSpot (pat-…). Substitui uma conexão OAuth. A resposta nunca devolve o token inteiro.",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is partly covered. The description adds real value beyond that: credential encryption, response limited to tokenLast4/method/oauthAvailable, 503 config_missing, OAuth refresh revocation on remove, and the shared 20-attempt retry queue. However, there is tension: 'remove:true apaga' (and revokes the refresh token) reads as a delete against a destructiveHint=false annotation. It discloses what is destroyed, which earns credit, but the idempotentHint=true claim isn't clearly reconciled with the state-changing OAuth/token-swap modes.

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?

Dense but front-loaded: the core connection rule leads, then per-mode detail, then side effects. Every sentence adds operational information, though the LGPD/mapping paragraph could be tightened.

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 9-parameter, nested-object tool with no output schema, it covers the return shape (tokenLast4, method, oauthAvailable), error cases (503 config_missing), mapping defaults, and what each flag does. An agent has enough to call it correctly without guessing.

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?

With 78% schema description coverage the baseline is 3, and the description goes further by documenting defaults (mapping uses guiaflow_* ), the empty-string-to-disable rule for mapping fields, the pat- token format, and the code+state pairing. These are semantics the schema does not fully spell out.

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 ('Conecta o link permanente já publicado ao HubSpot') and immediately scopes it ('Uma conexão por link, method oauth ou private_app'). It is clearly distinguishable from siblings like set_rd_station and set_lead_webhook by naming the target integration.

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?

Explicitly maps each mode to its trigger: authorize:true for OAuth, a pat- token for private app, remove:true to disconnect, sendTest:true to write a test contact. It also states the mutual-exclusion rule ('conectar por um método substitui o outro'), so an agent knows exactly which path to pick.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources