Mintive

When we ask an agent to "fix this bug," we're approving hundreds of actions we'll never see. These agents have our production credentials; and increasingly, they run in the background while we work on something else. Engineers are spinning up multiple Claude Code sessions in parallel, and ClawdBot hit >100k GitHub stars in weeks by letting agents handle email, workflows, even car purchases. The shift to agents without constant supervision is here. Today we're launching @mintive : governance for AI agents.

Cursor and MintMCP are partnering to help enterprises govern their coding agents through Cursor's new hooks program. Engineering orgs are rapidly increasing their use of Model Context Protocol in coding workflows. But most orgs have no visibility into what's actually installed, what data flows through these connections, or how to govern them. Cursor's hooks enable you to observe and control the agent loop by intervening at specific points. With MintMCP, you can enable hooks that fire before and after MCP tools are used. After enabling these hooks, you get: 🔹 A full inventory of all MCP servers installed across your organization 🔹 Allow/deny policies on servers and tools 🔹 Response scanning for sensitive data before it reaches the AI model 🔹 Complete audit trails for compliance Start by collecting data to understand actual usage patterns, then layer governance on top. Check out Cursor's announcement and our blog post on MCP governance using hooks - links in the comments below. @cursor_ai @MCP_Community @mintive

Progressive tool disclosure should be done by the agent, not as an MCP server tool. One of the challenges with MCPs is when too many tools are enabled, the context window is quickly filled. Instead of providing the agent with all the tool descriptions, progressive tool disclosure only presents the relevant tool specs to the LLM when it is relevant. Some MCP implementations now have a "search" and "use" tool where the search is used to find the right tools, and then use is another call to use a particular tool. While this could be implemented on the MCP server end, this is much better implemented on the agent end. Critically, if it's an MCP tool, then all the context for determining which tools are relevant needs to come in the call to the search tool; this message would then need to be in the context of the future conversation too! However, if it's implemented on the agent end, we have a lot more options to optimize how this decision is made. For example, the agent can use the *entire conversation* history as context with a smaller LLM. The agent doesn't need to store this lookup in the conversation history, and it can also optimize tool loading and prompt caching. @AnthropicAI's implementation of advanced tool use does a lot of this. When we built Lutra AI, we used another approach that worked well: we provided the agent with *short descriptions* of all the tools available across the ecosystem in the system prompt. At tool calling, the agent would request the tools needed; and only at that point, did we load the full tool spec into the conversation. We were also able to dynamically remove the full tool specs from the history when no longer needed (lots of prompt caching tricks here!). In practice, tool selection is still one of the most important things to optimize for. It is critical for security: if you have an agent that's only supposed to do analysis, there's no reason why it needs to have access to data write tools. The risk of agents going off track in a task is real - from prompt injections to just trying to be helpful! Making tool selections in a Virtual MCP server works really well, and pairs well with progressive disclosure. @MCP_Community

One of the biggest challenges with using agents today is figuring out how to provide the LLMs with a toolset that it understands how to use accurately, is not overly broad, and enables meaningful tasks to be completed. After testing out various approaches, we have found a use case driven way for packaging up tools to be the most effective approach. Our article with @pulsemcp goes into the details of what we've learned, why it is important to have tool groups based on use case or roles, and how it turns out that Model Context Protocol (MCP) already provides a natural way for us to implement this. We call this approach the Virtual MCP approach, where we use a gateway architecture to quickly group up tools by use case. Critically, tools in a virtual MCP come from multiple MCP servers. Using a virtual MCP setup makes it both easy for end users to configure, and also IT/admins to secure. As enterprises adopt more agents + MCPs, we think these approaches will become critical as we need control and telemetry into what the agents can and are doing. Thanks for @tadasayy @grumpygrowthguy for the collaboration. pulsemcp.com/posts/virtual-m… @mintive @MCP_Community

We just added more capabilities to @Lutra_AI to create fields and update records in @airtable! One of my favorite use cases is to get it to scan an existing table for missing data and then do the necessary work to fill it in. Getting integrations like this working robustly is hard! Particularly because users can specify custom schemas for their airtable bases and the AI needs to be aware of how to work with them (e.g., single selects have specific valid values), and it needs to be robust to issues that come up.