get_hot_leadsGet all hot and warm leads with MEDDIC evidence. The morning briefing tool.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| client | No | Agency only: target a managed client org by its id to query that client's data. Omit for your own. | |
| include_warm | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / clientAdded value: +{
+ "description": "Agency only: target a managed client org by its id to query that client's data. Omit for your own.",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this a safe read operation, so the description doesn't need to restate that. It adds context about the scope (all hot and warm leads) and the MEDDIC evidence filter, but does not disclose behaviors like pagination, ordering, or data freshness. With annotations covering the safety profile, the added context is sufficient but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence delivers the core action and scope, the second adds a memorable use-case tagline. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the main purpose but omits details about output format and parameter effects. With no output schema and modest parameter documentation, a more complete description would help. The 'MEDDIC evidence' and 'morning briefing' cues provide some context about the nature of the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not mention any parameters. It provides no clarification for 'days' or 'include_warm', leaving their semantics ambiguous. The phrase 'hot and warm leads' hints at include_warm, but the description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and the resource ('all hot and warm leads'), and specifies the unique qualifier 'with MEDDIC evidence', which distinguishes it from sibling tools like get_lead_enrichment or get_meddic_summary. The 'morning briefing' tagline further narrows its intended role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'The morning briefing tool' but does not explicitly state when to use it over alternatives, nor does it mention exclusions or scenarios where siblings should be preferred. This is implied context rather than clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are clearly distinct, but get_conversations and search_by_intent both return conversations, and get_hot_leads vs get_lead_enrichment have some overlap. Descriptions clarify their specific purposes, so ambiguity is minimal.
The majority of tools follow the get_* pattern, but search_by_intent deviates. Otherwise, naming is consistent and readable.
With 8 tools, the count is well-scoped for the server's purpose. Each tool focuses on a distinct aspect of buyer intent, from summaries to specific searches, without unnecessary bloat.
The server covers core needs: overview, listing, detail, enrichment, MEDDIC summary, knowledge gaps, and search. Missing are non-read operations and a general lead list (only hot leads), but these are minor gaps for an analytics-focused server.