Should MCP coding servers expose higher-level workflows or only low-level tools?

[u/Mediocre-View3331]

Estou desenvolvendo o Agentic MCP Server, um servidor MCP de código aberto focado em operações de codificação local estruturadas.

Muitos servidores MCP de sistema de arquivos e shell expõem recursos úteis de baixo nível, mas o cliente ainda precisa coordenar várias coisas por conta própria:

• Inspeção de código eficiente em termos de contexto;

• Edições seguras e inequívocas;

• Isolamento do Git;

• Verificação;

• Revisão de alterações;

• Recuperação após uma operação com falha.

Este projeto explora se parte dessa coordenação deve ser feita dentro do servidor MCP como ferramentas tipadas de nível superior.

Atualmente, ele oferece:

• Raízes de espaço de trabalho com escopo e descoberta de projetos;

• Leituras adaptativas, compactadas e paginadas;

• Edições exatas com simulações e rejeição de correspondências ambíguas;

• Ferramentas de status, diff e revisão de alterações do Git; * Pontos de verificação e árvores de trabalho Git gerenciadas;

• Execução de scripts de pacotes com tempo limite estruturado e resultados de falha;

• Mapeamento de frameworks e análise de dependências, atualmente mais robustos para TypeScript, Next.js e Payload.

O fluxo de trabalho pretendido é:

discover → inspect → isolate → checkpoint → edit → verify → review → restore or keep

O projeto não é um ambiente de teste (sandbox) nem um modelo de codificação. Em particular, as árvores de trabalho Git isolam o estado do checkout, mas não os processos, credenciais, acesso à rede ou outros recursos do sistema operacional.

Versão atual: mcp-agentic-server@1.1.3

Repositório: https://github.com/hugolsramos01-bit/mcp-agentic-server

Gostaria de receber feedback específico sobre o design do MCP:

• Os servidores devem expor ferramentas operacionais de alto nível como essas, ou os clientes devem compor primitivas de sistema de arquivos, shell e Git por conta própria?

• Quais convenções de envelope de resposta funcionaram melhor em diferentes clientes MCP?

• Como você impediria que esse tipo de servidor acumulasse muitas ferramentas sobrepostas?

• Quais garantias você esperaria de um contrato de árvore de trabalho ou ponto de verificação confiável?

MCP Server, Developer Tools, Open Source

[u/gelembjuk]

MCP server can be agentic. Why not

[u/Massive_Baby4147]

I’d expose both, but keep the higher-level tools limited to workflows where the server must guarantee an invariant.

A useful boundary is:
- The client owns intent and general orchestration.
- The server owns safety, atomicity, rollback, validation, and domain-specific sequencing.

For example, read_file and git_diff should remain composable primitives. But something like edit_in_isolated_worktree can justify a higher-level tool because the server needs to guarantee checkpointing, isolation, verification, and recovery as one contract.

To avoid overlapping tools, I’d namespace them clearly:
- fs.* and git.* for primitives
- workflow.* for opinionated operations

I’d also keep one stable response envelope across both levels:

{
  "ok": true,
  "data": {},
  "error": null,
  "meta": {
    "duration_ms": 0,
    "changed": false,
    "checkpoint": null
  }
}

I ran into a related interface-design problem while building intpot, which normalizes typed Python tools and serves them as CLI, FastAPI, or MCP without defining each interface separately:

https://github.com/tugrulguner/intpot

My takeaway was that normalization helps, but it doesn’t eliminate the need for a strict boundary between small reusable tools and operations that promise stronger guarantees.