web_scoutResearch the live web: search for information, read documentation, fetch API references, or verify library usage. Returns structured findings as markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What to research or look up on the web | |
| urls | No | Specific URLs to visit (optional — if omitted, will search the web) | |
| maxPages | No | Max pages to fetch content from |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context by saying 'live web' and 'Returns structured findings as markdown,' which informs the agent that results may reflect real-time external content and come in a particular format. No contradiction exists.
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 concise sentences with no filler. It front-loads the core action ('Research the live web'), lists representative use cases, and ends with the output format. Every sentence earns its place.
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 simple read-only web research tool with three well-documented parameters and no output schema, the description is sufficiently complete. It explains what the tool does, the kinds of tasks it supports, and the markdown output. It could slightly expand on how the optional urls parameter interacts with the default search behavior, but the schema covers that well enough.
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%, so the schema already explains all three parameters: goal, urls, and maxPages. The description adds overall purpose but does not enrich individual parameter semantics beyond the schema, so the baseline of 3 is appropriate.
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 a specific verb-resource pairing ('Research the live web') and names concrete use cases: search for information, read documentation, fetch API references, verify library usage. This clearly distinguishes web_scout from the sibling tools like db_query and deploy_app, which are about entirely different resources.
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 gives clear context on when to use the tool: research on the live web, documentation, API references, or library verification. It does not explicitly list exclusions or name alternative tools, but the domain is obvious enough relative to siblings, so it earns a 4 rather than a 5.
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.
Each tool maps to a distinct action/resource: build lifecycle (build/deploy/status/list), GTM content workflow (generate/list/publish/analytics), and utility helpers (echo/shadcn_ui/web_scout) are clearly separated. Even closely related tools like get_build_status and list_builds differ in specificity.
Most tools follow a snake_case verb_noun pattern like build_app, deploy_app, and gtm_publish_content. Echo, shadcn_ui, and web_scout break the pattern but remain recognizable and do not create confusion.
11 tools cover the build workflow, GTM workflow, and a few support utilities without redundancy or bloat. The count is well within the ideal range and each tool earns its place.
The main build and GTM workflows are represented, but there is no tool to respond when get_build_status returns needs_clarification, leaving a potential dead end. Content editing/deletion and build deletion are also absent, though this may be acceptable if drafts and builds are treated as immutable.