DeepScout

Create a project

scout_create_project

Create a project only when the user asks for a new one, e.g. for another client or market. A project is a separate workspace with its own websites and exports. A matching connects only the websites of one project. Each project pays for its websites: a website in a second project takes another analysis and another paid scrape. Thus do not create a project for each website. The customer_id is in scout_list_projects.

country: ISO 3166 code of the market of the project, e.g. "CZ". currency: ISO 4217 code of the prices in the exports, e.g. "CZK".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "customer_id": "<customer_id>",
      "name": "<name>",
      "country": "<country>",
      "currency": "<currency>"
    },
    "name": "scout_create_project"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`country`	Yes
`currency`	Yes
`customer_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only cover openWorldHint=false and destructiveHint=false; the description adds the critical billing consequence (a website in a second project means another paid scrape/analysis) and the containment semantics of projects versus matching. It does not state reversibility or permission requirements, but the cost/side-effect disclosure is the highest-value addition for a create tool.

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

Conciseness4/5

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

The gating condition is front-loaded in the first sentence, and the middle paragraph about project cost justifies its length because it prevents duplicate project creation. A few clauses restate the same idea (separate workspace, matching scope) and could be tightened.

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

Completeness5/5

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

For a 4-required-param create tool with an output schema (so return values need no explanation) and thin annotations, the description supplies the missing decision context: when to create, why not to over-create, billing impact, and where customer_id comes from. Nothing essential to invoking it correctly is absent.

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

Parameters4/5

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

Schema coverage is 0%, so the description must carry the load: it documents country as an ISO 3166 market code with an example, currency as an ISO 4217 code with an example, and locates customer_id in scout_list_projects. Only 'name' is left without any format or guidance, which keeps it out of the top score.

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?

Specific verb+resource ('Create a project') plus a definition of what a project is (a separate workspace with its own websites and exports), which distinguishes it from scout_list_projects and scout_match_websites. It stops short of naming a sibling as the alternative action, but the conceptual boundary with 'matching' is drawn explicitly.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('only when the user asks for a new one, e.g. for another client or market') and an explicit anti-pattern ('do not create a project for each website'), with the cost reason behind it. It also tells the agent where to source customer_id (scout_list_projects), leaving little to inference.

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

All DeepScout tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.