Análise do Smithery

• Registro MCP: um diretório público com mais de 7.300 servidores MCP, cada um exibindo volume mensal de chamadas, percentual de disponibilidade, taxa de sucesso, ferramentas disponíveis e um trecho de conexão para copiar e colar. As categorias incluem busca na web, automação de navegador, finanças, ferramentas de programação e pesquisa acadêmica.
• Smithery CLI: uma interface de linha de comando para buscar no registro, adicionar servidores a clientes locais, listar e chamar ferramentas, publicar servidores e emitir tokens de serviço com escopo. Ela exige o Node.js 20 e se instala com um único comando npm.
• Toolbox: uma coleção pessoal de servidores MCP salvos que mantém as conexões mais usadas do time organizadas e acessíveis.
• Biblioteca de habilidades: um catálogo separado de habilidades de agente reutilizáveis, conjuntos estruturados de instruções que ampliam o que um agente de IA consegue fazer dentro de ambientes como o Claude Code. As habilidades cobrem áreas como design de frontend, criação de documentos, análise competitiva, modelagem financeira e fluxos de implantação.
• Uplink: um recurso de túnel que expõe um servidor MCP rodando localmente como uma conexão ativa do Smithery, útil para testar antes de publicar ou para operar ferramentas privadas que dependem de recursos locais.
• Deep linking: um protocolo que permite a clientes de IA compatíveis instalar automaticamente a configuração de um servidor MCP quando o usuário clica em um link, eliminando a configuração manual de JSON.
• Triggers (pré-visualização): um mecanismo que permite a servidores MCP expor eventos de origem como webhooks, para que consumidores recebam notificações em tempo real sem que o Smithery esteja no caminho da entrega.
• Ferramentas de publicação: desenvolvedores podem publicar servidores MCP baseados em URL ou arquivos MCPB empacotados no registro a partir da CLI, com varredura automática, extração de metadados e um playground de ferramentas na página do servidor.

Em conjunto, esses recursos permitem que um time pequeno de desenvolvimento conecte seus agentes de IA a serviços externos em minutos, e não em dias, sem construir ou manter a infraestrutura subjacente de autenticação e sessão.

Recursos de IA

• Descoberta de ferramentas sensível ao contexto: servidores MCP publicam um esquema JSON descrevendo suas capacidades, que os agentes de IA leem em tempo de execução para decidir qual servidor se encaixa em cada tarefa. Isso difere da chamada de funções codificada porque o agente descobre capacidades dinamicamente em vez de depender de rotas pré-programadas.
• Tradução de linguagem natural em chamada de ferramenta: clientes MCP traduzem um pedido em linguagem natural do usuário na chamada exata que o servidor espera, sem exigir que o usuário conheça a sintaxe da API subjacente.
• Filtragem inteligente de ferramentas pelo desenho do esquema: servidores MCP bem desenhados expõem apenas as ferramentas relevantes a um caso de uso, reduzindo a poluição de contexto na memória de trabalho do agente. Servidores como o Exa Search seguem esse princípio devolvendo apenas os campos de que um agente precisa, em vez de cargas completas da API.
• Habilidades como instruções de ordem superior: a biblioteca de habilidades oferece conjuntos reutilizáveis de instruções que vão além de chamadas isoladas de ferramenta, codificando boas práticas para tarefas complexas como construir interfaces ou analisar demonstrações financeiras.

O que distingue a abordagem MCP das integrações comuns é a capacidade do agente de descobrir e encadear ferramentas em tempo de execução, sem que essas rotas estejam codificadas de antemão. É isso que faz do MCP uma infraestrutura, e não apenas um conjunto de ferramentas: é a camada que permite a existência de software nativo de IA, em que agentes são os usuários principais de um serviço e nenhuma interface voltada a humanos é necessária.

Dito isso, a qualidade dessa inteligência depende muito da implementação. Servidores MCP que expõem centenas de ferramentas sem filtragem, ou que devolvem cargas de API não processadas, degradam em vez de melhorar o desempenho do agente. As ferramentas de observabilidade do Smithery existem em parte para ajudar desenvolvedores a identificar e tratar esses problemas.

Integrações

• Produtividade e comunicação: Gmail, Slack, Google Drive, Notion, Jira, Linear, Attio.
• Web e pesquisa: Exa Search para busca na web e recuperação de conteúdo, Browserbase para controle remoto de navegador, Semantic Scholar e arXiv para busca de artigos acadêmicos e análise de citações, Context7 para documentação de SDKs e frameworks.
• Ferramentas de desenvolvimento: GitHub, Vercel para implantação, Figma e diversos conectores de banco de dados.
• Operações de negócio: Stripe e uma gama de conectores de CRM e finanças.

Cada página de servidor mostra quais clientes MCP mais o utilizam, o que dá aos times um sinal prático sobre compatibilidade no mundo real antes de conectar.

A API do Smithery, alimentada pelo agent.pw de código aberto, oferece uma interface programática para gerenciar conexões em escala, incluindo criar conexões com etiquetas de metadados e definir escopo de tokens por usuário ou espaço de trabalho.

Segurança e conformidade de dados

A propriedade dos dados no Smithery segue um modelo em camadas. O Smithery, operando como Clavia, Inc., atua como controlador dos dados pessoais coletados pela própria plataforma, como informações de conta, dados de uso e metadados de conexão. Quando desenvolvedores publicam servidores MCP, esses servidores interagem diretamente com os serviços subjacentes, e o tratamento de dados nesse nível é regido pelas políticas de cada serviço.

Quanto ao treinamento de IA, o aviso de privacidade do Smithery não indica que dados de clientes sejam usados para treinar modelos. A plataforma coleta análises de uso, como volumes de chamadas de ferramenta, origens de cliente e métricas de latência, principalmente para observabilidade e melhoria do produto.

Credenciais e chaves de API são armazenadas com armazenamento criptografado e somente de escrita, o que significa que não podem ser lidas depois de salvas. Tokens OAuth são tratados automaticamente, incluindo a renovação, de modo que credenciais de vida longa não ficam expostas a aplicativos cliente. Tokens de serviço têm escopo com restrições explícitas cobrindo namespace, recurso, operação, metadados e tempo de vida, e não podem exceder as permissões do token principal que os emitiu.

O Smithery suporta login por OAuth com provedores como o Google. Uma observação para times com requisitos rígidos de segurança: a CLI do Smithery é distribuída como um pacote npm minificado. O código-fonte da CLI estava inicialmente fechado no lançamento, e o fundador anunciou planos de abri-lo pouco depois. Times em ambientes sensíveis à segurança devem verificar o status atual do repositório antes de implantar a CLI em produção.

Idioma: suporte ao cliente e interface

A plataforma, a documentação e a CLI do Smithery estão inteiramente em inglês. O registro público, as páginas de servidor, o blog e a documentação para desenvolvedores são escritos em inglês, e não há versão da interface em português no momento desta análise.

O suporte ao cliente está disponível por e-mail em contact@smithery.ai. A plataforma também oferece uma comunidade no Discord para discussão entre desenvolvedores, feedback e suporte técnico, que funciona principalmente em inglês.

Idioma da IA

As funções da própria plataforma Smithery, como descoberta de ferramentas, análise de esquemas e gestão de conexões, não dependem de processamento de linguagem natural. O protocolo MCP é baseado em JSON e agnóstico de idioma: o esquema de um servidor MCP funciona de forma idêntica para um agente que recebe instruções em português ou em inglês, porque o protocolo opera no nível de dados estruturados, e não no nível do texto.

A experiência de idioma para o usuário final depende, portanto, do cliente de IA usado junto com o Smithery, e não do Smithery em si. Se o agente subjacente roda em um modelo multilíngue como o Claude, ele consegue entender e responder em português independentemente do idioma do servidor MCP. A camada MCP é transparente às capacidades linguísticas do modelo.

Acesso móvel

O Smithery não oferece aplicativo móvel dedicado para iOS ou Android. A plataforma é um registro baseado na web e uma ferramenta de linha de comando, ambos pensados para ambientes de desktop ou notebook.

O site smithery.ai é acessível por navegadores móveis, e o catálogo do registro pode ser navegado no celular. No entanto, a CLI exige um ambiente de terminal, e o uso significativo do Smithery, como conectar servidores, chamar ferramentas, publicar e gerenciar namespaces, é um fluxo de desktop.

Isso é coerente com o posicionamento da plataforma voltado a desenvolvedores e não representa uma limitação significativa para seu público-alvo.

Suporte, onboarding e gestão de conta

A documentação do Smithery cobre os fluxos essenciais: conectar-se a servidores MCP, gerenciar credenciais, publicar servidores, usar a CLI, definir escopo de tokens e usar o Uplink. A documentação é estruturada para desenvolvedores já familiarizados com a linha de comando e com configuração em JSON, com exemplos de código em TypeScript e cURL ao longo do texto.

Para times novos no MCP, o blog da plataforma traz uma introdução conceitual detalhada ao protocolo, cobrindo a relação servidor-cliente, a estrutura de esquema e exemplos práticos, o que oferece um bom ponto de partida antes de trabalhar com a CLI.

A comunidade no Discord funciona como principal recurso de onboarding para dúvidas não cobertas pela documentação.

Não há função dedicada de gestão de conta documentada para os planos padrão. O nível Custom inclui suporte no Slack e um SLA de disponibilidade, o que sugere que um onboarding mais assistido está disponível para contas maiores mediante solicitação.

Times sem experiência prévia em MCP devem prever tempo para a curva de aprendizado. Os comandos da CLI são concisos e bem documentados, mas entender por que o MCP funciona como funciona exige leitura além do guia rápido.

Facilidade de uso / UX

A interface web do Smithery é fácil de entender.

O registro é bem organizado, as páginas de servidor destacam a informação que importa, como disponibilidade, volume de chamadas e lista de ferramentas, e o toolbox oferece uma forma sensata de gerenciar uma coleção pessoal de servidores. Para navegar e descobrir, a experiência é direta.

A CLI é o verdadeiro ambiente de trabalho, e reflete um bom desenho de experiência para desenvolvedores: os comandos são intuitivos, o menu de ajuda é organizado, a saída em JSON está disponível para automação, e o log detalhado fica a uma flag de distância na hora de depurar.

Para quem não é desenvolvedor, a experiência é outra. Não há construtor visual de fluxos, nem interface de arrastar e soltar, nem assistente guiado de configuração além da documentação.

A rapidez com que uma PME extrai valor do Smithery depende quase inteiramente do ponto de partida técnico do time. Um desenvolvedor que já usa o Claude Code consegue adicionar e testar um servidor MCP em menos de dez minutos.

O Smithery oferece três níveis estruturados em torno de chamadas de procedimento remoto (RPCs). Uma RPC é uma única requisição JSON-RPC 2.0 a um servidor MCP, como listar ferramentas, chamar uma ferramenta ou ler um recurso.

O plano Hobby é gratuito e inclui 50.000 RPCs por mês e até três namespaces, com OAuth gerenciado e conexões persistentes inclusos. Não é preciso informar meio de pagamento para começar.

O plano Pay as You Go tem uma mensalidade fixa e inclui 100.000 RPCs por mês e até 100 namespaces. Esse nível serve a times de desenvolvimento de PMEs com uso moderado de agentes que precisam de mais capacidade de namespaces do que o plano gratuito oferece.

O plano Custom está disponível mediante solicitação e inclui tudo do Pay as You Go, além de limites de taxa personalizados, um SLA de disponibilidade e suporte dedicado no Slack.

Publicar um servidor MCP no registro do Smithery é totalmente gratuito, independentemente do nível do plano. Desenvolvedores pagam apenas pelo consumo de RPCs ao usar servidores como clientes. Para PMEs avaliando a plataforma, o nível gratuito oferece capacidade suficiente para testar integrações e construir fluxos de prova de conceito antes de assumir um plano pago.

Uma pequena consultoria de software passa boa parte de cada semana em reuniões com clientes, chamadas de descoberta e alinhamentos internos. O time usava o Granola para capturar e transcrever essas conversas, mas as anotações ficavam presas dentro do aplicativo de notas, longe das ferramentas em que o time efetivamente agia sobre elas. Depois de cada chamada, alguém precisava reler uma transcrição e levar manualmente decisões, bugs e itens de ação para chamados, quadros de projeto e e-mails de acompanhamento.

Depois de conectar o Granola à sua configuração do Claude Code pelo Smithery com um único comando de CLI, aquele contexto de reunião passou a ser diretamente consultável pelo agente. O servidor MCP do Granola expõe um conjunto enxuto de ferramentas: o agente pode fazer perguntas em linguagem natural sobre todo o histórico de reuniões do time, listar reuniões por intervalo de datas, extrair resumos e participantes de chamadas específicas e recuperar transcrições completas. Assim, em vez de abrir o aplicativo e caçar a chamada certa, um desenvolvedor podia perguntar ao agente o que foi decidido na reunião com o cliente daquela manhã e usar a resposta, completa com citações que remetem às anotações de origem, como contexto para redigir o acompanhamento ou dimensionar a próxima tarefa. Como o Smithery cuidou da autorização automaticamente, a única etapa de configuração foi rodar o comando uma vez.

O valor esteve menos em qualquer recurso isolado e mais em fechar a distância entre o que foi dito em uma reunião e o que aconteceu depois. Ao transformar o contexto das reuniões em algo que um agente já presente no fluxo diário conseguia alcançar, o time eliminou uma etapa manual recorrente e parou de depender da memória e do copiar e colar para fazer o trabalho avançar. Vale notar que a profundidade do acesso depende do plano do Granola.

Vídeos

https://twitter.com/i/status/2048847052923425109

Tanto o Smithery quanto o Firebase atendem times de desenvolvimento que constroem produtos com IA, embora resolvam problemas diferentes.

	Smithery	Firebase
Propósito principal	Registro MCP e conectividade de ferramentas para agentes	Plataforma completa de backend de aplicação
Usuário-alvo	Desenvolvedores que constroem agentes de IA	Desenvolvedores que constroem aplicativos web ou móveis
Gestão de autenticação	OAuth gerenciado, renovação de tokens, escopo	Firebase Authentication para usuários do app
Amplitude de integração	Mais de 7.300 servidores MCP	Mais de 100 extensões, principalmente do ecossistema Google
Nível gratuito	50 mil RPCs/mês, 3 namespaces	Cotas generosas entre produtos

O Firebase serve a PMEs que constroem aplicativos móveis ou web completos e precisam de autenticação, bancos de dados, hospedagem e análises. Mas os dois não são concorrentes diretos: o Firebase constrói a camada de aplicação, enquanto o Smithery conecta o agente a serviços externos, então um time poderia usar ambos. O Firebase oferece seu próprio servidor MCP e a CLI do Gemini, mas apenas dentro do ecossistema Google Cloud, e não no registro aberto que o Smithery oferece.

A integração direta com API por chamada de funções ainda funciona para times com algumas integrações confiáveis e escritas à mão. Ela apenas não escala, já que cada novo serviço significa mais trabalho sob medida, e é aí que o Smithery conquista seu lugar: quanto mais serviços um agente precisa alcançar, mais seu valor aparece.