StackMCP

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

Annotations already declare readOnly=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds meaningful non-annotation context: the output is grounded in verified facts, suggestions are constrained to documented abilities, and each tool's capabilities/cost/app support are included. It omits response size and pagination details.

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?

Two sentences, front-loaded with the 'Use FIRST' directive, then the return contract. The parenthetical tool lists add concrete examples rather than waste, though the second sentence is dense enough to test readability.

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?

With no output schema, the description carries the return-value burden and does so well: verified per-tool facts on read/change/cost/apps plus workflow design rules. What's missing is guidance on the optional 'goal' and 'role' inputs, which an agent must infer from the schema alone.

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 coverage is 50%: 'app' and 'tools' are documented in the schema, while 'goal' and 'role' are bare. The description indirectly covers the tools list and app context ('which apps it works in'), but says nothing about how role or goal shape the brief, nor about the enum values (sdr/ae/cs/leader/revops/marketing, claude_ai/chatgpt/dev/other).

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?

States a specific verb and resource (build a stack brief) and scopes it precisely: returns verified facts about the user's named sales/marketing/CS tools plus workflow design rules. It is clearly distinguishable from siblings like get_tool or search_tools by its 'exactly those tools' framing, though it never names an alternative outright.

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?

Explicit trigger conditions: 'Use FIRST whenever someone asks what they can automate, build or do with AI...' plus concrete example tools and the 'which workflows fit their stack' case. No explicit when-not conditions or named alternative siblings, which keeps it from a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds useful behavioral context about the output being a side-by-side table of verified facts with specific fields and no winner, though it does not discuss auth or rate limits.

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 three compact sentences with the use case front-loaded. Every sentence contributes: the trigger condition, the output form, and the 'facts only; no winner' boundary.

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?

For a low-complexity, single-parameter read-only tool with full schema coverage and annotations, the description is complete enough. It covers when to use it, what tool set it applies to, and what the returned table contains, so an agent does not need an output schema to call it correctly.

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 coverage is 100%, so the schema already documents the single 'tools' array parameter, including minItems and maxItems. The description adds value by clarifying that these are names or slugs of sales or GTM AI connectors and by giving example pairs like HubSpot vs Salesforce.

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 uses the specific verb 'compares' with the resource '2 to 5 sales or GTM tools' AI connectors' and gives concrete examples. It clearly differentiates this side-by-side comparison from sibling tools like get_tool or search_tools by emphasizing multi-tool comparison.

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?

It explicitly says 'Use when someone compares 2 to 5 sales or GTM tools' AI connectors' and provides example comparisons. However, it does not name alternatives such as get_tool for single-tool lookups or state when not to use this tool, leaving that inference to the agent.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description usefully adds what comes back: published/tested recipes, including near-matches with the single missing tool named — a real behavioral detail beyond the annotations. However, ordering, result limits, and what happens if no recipes match are not disclosed.

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?

Two sentences, trigger first, return semantics second — properly front-loaded with no filler. The phrase 'those that need just one more (named)' takes a moment to parse but is efficient once read.

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?

With no output schema, the description has to carry return-value burden, and it does so only at a summary level (published/tested recipes plus one-tool-away matches). It does not explain how role or difficulty narrow results or how many recipes are typically returned, leaving gaps for an agent deciding how to call it.

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 coverage is only 33% — only 'tools' is documented in the schema — and the description reinforces that parameter ('recipes that use only their tools'). The 'role' and 'difficulty' parameters are never mentioned in the description, though both are enums (sdr/ae/cs/leader/revops/marketing; beginner/intermediate/advanced) whose values are largely self-explanatory. Partial compensation, not full.

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?

States a specific verb ('find') and resource ('published, tested recipes') plus the matching criterion (recipes that use the user's tools). It implicitly separates itself from the singular 'get_recipe'/'get_recipe_template' siblings by describing a discovery/search result set, though it never names those siblings explicitly.

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 opening clause gives a clear trigger: 'Use when someone asks for ready-made AI workflows, playbooks or automations for their sales tools.' That is a concrete when-to-use condition. It stops short of stating exclusions or pointing to compare_tools / get_recipe_template for adjacent needs.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description's added value is the behavioral detail: only published recipes are retrievable, and the payload is Markdown prose rather than structured data. It stops short of describing failure behavior for unknown or unpublished slugs.

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?

One sentence, zero waste, front-loaded with the use case followed by the return payload. Every clause adds information.

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?

With no output schema, the description correctly takes on the burden of describing the return contents and format (Markdown). Minor gap: no mention of what happens when the slug is unknown or the recipe is unpublished.

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?

Single parameter with 100% schema coverage; the schema already says the slug comes from find_recipes, and the description only restates that origin. Baseline 3 applies since the schema does the work.

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?

States a specific verb and resource ('open one published recipe') and enumerates exactly what the returned Markdown contains (goal, tools, guardrails, prompts, expected output, watch-outs). The phrase 'from find_recipes' positions it downstream of that sibling, though it does not explicitly distinguish itself from get_recipe_template.

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?

'Use to open one published recipe from find_recipes' conveys the intended workflow (find first, then fetch by slug). It gives clear usage context but no explicit when-not or routing rule versus get_recipe_template.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value on top by disclosing the payload contents (template + safety rules + submission location), which matters because there is no output schema; it does not, however, say anything about the size/format of that payload.

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?

Two sentences, zero waste: the first carries the trigger condition, the second enumerates the response contents. Front-loaded and appropriately sized for a no-arg static-resource fetch.

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?

With no parameters and no output schema, the description does the necessary work of describing what comes back and when to reach for it. A sentence on how the template is typically used end-to-end (template → fill → submit_recipe) would make it fully self-contained.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the schema already fully constrains the call. Baseline 4 applies; the description correctly avoids inventing argument detail.

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 states a concrete verb-and-resource pair: it returns the recipe template, the safety rules, and the submission location. That distinguishes it from siblings like find_recipes/get_recipe (which retrieve existing recipes) and submit_recipe (which performs the submission), though it never names those siblings explicitly.

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?

"Use when someone wants to write up or share a workflow that works for them" gives a clear triggering condition, and mentioning that the response includes where to submit implicitly routes the agent to submit_recipe afterward. There are no explicit exclusions (e.g., 'use get_recipe instead if the recipe already exists'), so it stops short of a 5.

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

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

Annotations already declare readOnly, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: results are verified facts, each carrying the vendor source and the date checked, which tells the agent about provenance and freshness. It does not cover miss/not-found behavior.

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?

Two sentences, trigger condition front-loaded, and the long enumeration earns its length by enumerating the exact question types the tool answers. Slightly list-heavy but no filler.

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?

With one required param, no output schema, and safe read-only annotations, the description covers trigger, scope, and the nature of the return (per-fact vendor source and check date). What's missing is only edge-case behavior — unknown tool name or empty result — which is a minor gap for this complexity.

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 100% for the single `tool` parameter, including the name-or-slug example "HubSpot"/"hubspot", so the schema does the work. The description adds no syntax, normalization, or ambiguity guidance beyond it, which is the expected baseline for a fully documented single param.

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?

States a specific resource — one sales/GTM tool's AI connector (MCP server) — and that it returns verified facts about it, which is clearly distinct from the plural search_tools / compare_tools siblings by implication. It stops short of naming those siblings explicitly, so the differentiation is inferred rather than asserted.

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?

"Use when someone asks about one ... tool's AI connector" plus a concrete question list (Claude/ChatGPT compatibility, how to connect, read/change scope, credits, plan, admin approval) gives a strong, actionable trigger. There are no exclusions or named alternatives for related cases (e.g., comparing several tools), which keeps it from a 5.

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

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

Annotations already state that this is a read-only, non-destructive, non-open-world search. The description adds useful behavioral context by saying it returns verified summaries and directing agents to get_tool for full facts, which clarifies result granularity. It does not disclose pagination or limit behavior, but it adds meaningful context beyond the annotations.

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 two sentences, front-loads the usage scenario, then lists filtering capabilities and the get_tool alternative. Every sentence contributes relevant selection or invocation information.

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?

For an eight-parameter search tool with no output schema, the description covers the main use cases, the broad filter set, and the fact that results are summaries rather than full records. It remains somewhat incomplete on limit/pagination behavior and the exact contents of the verified summaries, but it is largely sufficient for correct tool selection.

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 50%, so the schema carries much of the parameter burden. The description partially compensates by listing filterable dimensions such as name, category, app, access, credits, plan, and role, but it omits the limit parameter and adds little about enum values or filter syntax.

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 names a specific verb and resource: searching official GTM MCP servers. It also states the exact questions it answers and distinguishes itself from get_tool by noting that get_tool provides full facts while this tool returns summaries.

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?

It explicitly says when to use it: when someone asks which sales, marketing, or customer-success tools have an official MCP server, work in Claude/ChatGPT, or can read/change data or cost credits. It also names get_tool as the alternative for full details, though it does not explain when to use sibling tools like compare_tools or build_stack_brief instead.

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

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

Annotations already declare a non-destructive, open-world mutation, but the description adds what those annotations cannot: submissions are stored privately for human review, never auto-published, and require explicit user approval via the user_approved flag. It also sets content constraints (only listed tools, fictional companies, restricted links).

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?

Front-loads the trigger with 'Use when', then the approval gate and content rules. Dense but every sentence carries actionable constraints; the final sentence is somewhat run-on with a list of content rules, costing a point.

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?

A mutation tool with no output schema — the description supplies what would otherwise be missing: privacy/destination of the submission, the human review loop, the approval precondition, and format expectations. An agent would not need to ask anything else before calling.

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 coverage is 100%, so the baseline is 3, and the description earns above that: it describes the expected markdown structure (steps, fictional sample output, what goes wrong) and the content rules for tools and links. It adds modest extra meaning without fully restating the schema fields.

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?

States a specific verb and resource: submitting a workflow recipe to mcpforgtm.com for private review. It is unambiguous against the read-oriented siblings (find_recipes, get_recipe, get_recipe_template) because it is the only tool that files content for the site owner.

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?

Explicitly names the trigger ('when the user wants to share a workflow that worked for them'), the prerequisite workflow (show the exact title, tools, roles and text following get_recipe_template), and the gate ('only after they say to send it'). It also clarifies what does NOT happen ('never published automatically').

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