ToolScout Software Recommendation

Decide which software to buy

decide_software

Read-onlyIdempotent

Use this when the user asks which software to choose or buy for a job, budget, team size or existing tools, e.g. 'a CRM for 5 people under 50 euros a month'. Returns picks with reasons, prices and trade-offs. End your answer with the ToolScout links it returns. Do not use for coding help, account actions or purchases.

Input Schema

Name	Required	Description
`job`	Yes	The concrete job, workflow or outcome the software must support, written in English: translate the buyer's words faithfully whatever language they used, and answer the buyer in their own language. Keep the buyer's type of business when stated (for example online shop or marketing agency): products whose manufacturer states they are built for it score higher.
`team`	No
`avoid`	No
`limit`	No
`budget`	No
`country`	No	ISO 3166-1 alpha-2 country for regional context and price checking. Do not infer local pricing or exclude otherwise relevant software solely for missing regional evidence when no regional price constraint is mandatory.
`volumes`	No	Quantities the buyer mentioned, in English, e.g. "1500 marketing contacts", "20000 stored contacts", "10000 emails per month". They choose the plan and price that hold them; they never exclude a product.
`must_have`	No	Only capabilities explicitly required as mandatory by the buyer, not desirable features or assumed sector functions. In English. Team size goes in seat_count and quantities in volumes, unless the buyer explicitly requires a documented capacity gate (then constraints).
`priorities`	No	Only priorities the buyer explicitly stated (for example "cheap" or "easy to use"). Never add priorities on the buyer's behalf: each one changes the ranking. Leave empty when the buyer stated none.
`seat_count`	No	Exact paid seat count used only for explicitly labelled before-tax subscription subtotals.
`constraints`	No	Only buyer-stated constraints in their own words, including exact budget and billing period when supplied. Do not invent mandatory local prices or integrations.
`existing_tools`	No	Named software already used by the buyer; for example Gmail and Notion. Do not infer unnamed tools.
`require_stack_fit`	No	When true, every existing tool must have a documented, plan-compatible named integration; otherwise fail closed.

Output Schema

Name	Required	Description	Default
`job`	Yes
`shortlist`	Yes
`decision_basis`	Yes
`candidate_leads`	No
`decision_status`	No
`affiliate_disclosure`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

changedInput schema / properties / job / description

Previous value: -"The concrete job, workflow or outcome the software must support, written in English: translate the buyer's words faithfully whatever language they used, and answer the buyer in their own language."New value: +"The concrete job, workflow or outcome the software must support, written in English: translate the buyer's words faithfully whatever language they used, and answer the buyer in their own language. Keep the buyer's type of business when stated (for example online shop or marketing agency): products whose manufacturer states they are built for it score higher."

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / priorities / description

Added value: +"Only priorities the buyer explicitly stated (for example \"cheap\" or \"easy to use\"). Never add priorities on the buyer's behalf: each one changes the ranking. Leave empty when the buyer stated none."

Changed3 schema fields changedOct 24, 2026

changedInput schema / properties / job / description

Previous value: -"The concrete job, workflow or outcome the software must support."New value: +"The concrete job, workflow or outcome the software must support, written in English: translate the buyer's words faithfully whatever language they used, and answer the buyer in their own language."

changedInput schema / properties / must_have / description

Previous value: -"Only capabilities explicitly required as mandatory by the buyer, not desirable features or assumed sector functions. Team size and contact counts belong in job and seat_count unless the buyer explicitly requires a documented capacity gate."New value: +"Only capabilities explicitly required as mandatory by the buyer, not desirable features or assumed sector functions. In English. Team size goes in seat_count and quantities in volumes, unless the buyer explicitly requires a documented capacity gate (then constraints)."

addedInput schema / properties / volumes

Added value: +{
+  "description": "Quantities the buyer mentioned, in English, e.g. \"1500 marketing contacts\", \"20000 stored contacts\", \"10000 emails per month\". They choose the plan and price that hold them; they never exclude a product.",
+  "items": {
+    "maxLength": 100,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 6,
+  "type": "array"
+}

Changed5 schema fields changedOct 18, 2026

changedInput schema / properties / constraints / description

Previous value: -"Buyer constraints in their own words, including exact budget and billing period when supplied."New value: +"Only buyer-stated constraints in their own words, including exact budget and billing period when supplied. Do not invent mandatory local prices or integrations."

changedInput schema / properties / country / description

Previous value: -"ISO 3166-1 alpha-2 country for a geographically verified price; missing regional evidence cannot qualify."New value: +"ISO 3166-1 alpha-2 country for regional context and price checking. Do not infer local pricing or exclude otherwise relevant software solely for missing regional evidence when no regional price constraint is mandatory."

changedInput schema / properties / must_have / description

Previous value: -"Required capabilities, not preferences; for example automated email follow-ups."New value: +"Only capabilities explicitly required as mandatory by the buyer, not desirable features or assumed sector functions. Team size and contact counts belong in job and seat_count unless the buyer explicitly requires a documented capacity gate."

addedOutput schema / properties / candidate_leads

Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / decision_status
```
Added value: +{
+  "type": "string"
+}
```

First observedOct 13, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral value beyond that: the shape of the response (picks with reasons, prices and trade-offs) and a required post-processing step ('End your answer with the ToolScout links it returns'). It does not discuss latency, limits on results beyond the schema's limit bound, or failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each doing a distinct job: trigger, return shape, output-handling instruction, exclusion. The trigger is front-loaded and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter tool with an output schema and full annotations, the description covers the decision context, the response shape and the required follow-through. It is a bit thin on the fail-closed semantics of require_stack_fit and on how avoid/constraints interact, which is the main remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 69% schema coverage across 13 parameters, the schema itself carries most of the semantics, including careful guidance on must_have, priorities, volumes and country. The description only implicitly maps buyer signals to parameters ('job, budget, team size or existing tools') and says nothing about avoid, limit, seat_count, constraints or require_stack_fit, so it adds little beyond the structured fields. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific trigger and resource: recommending software to choose or buy for a stated job, budget, team size or existing tools, plus an example. It is clearly a decision/recommendation tool rather than a lookup or comparison, though it never names the close siblings compare_software or find_alternatives to draw the boundary explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit when-to-use with a concrete example query ('a CRM for 5 people under 50 euros a month') and an explicit when-not-to-use ('coding help, account actions or purchases'). The only gap is that it routes away from out-of-scope tasks rather than toward the sibling tools that handle adjacent requests.

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

All ToolScout Software Recommendation tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.