Skip to main content
Glama
Sign In
webscout-mcp

webscout-mcp

by wxs-lang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

web_knowledge_graph

Build a knowledge graph from a page or text by extracting named entities and their co-occurrences, then rank entities by centrality to map what a document covers and how its parts connect.

Instructions

Build a knowledge graph of entities and relationships from a page or text.

Extracts named entities (people, organizations, locations, technologies) and the relationships between them, then ranks entities by centrality.

Provide either url (fetched first) or text (used directly). This is useful for mapping who/what a document is about and how they connect, rather than reading it linearly.

Relationship types are currently co_occurs_with only: relationships come from proximity, not from parsing sentence semantics. Entity types are rule-based, so some are reported as unknown rather than guessed.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "web_knowledge_graph"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNo
textNo
max_entitiesNo
include_centralityNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.4.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does unusually well: it discloses that relationships are proximity-based (`co_occurs_with` only, not semantic parsing) and that entity typing is rule-based with `unknown` fallbacks. It omits only a statement of the operation's safety/read-only nature and expected cost or latency.

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?

Front-loaded with purpose, then input selection, then caveats — a sensible ordering. Slight redundancy between the opening sentence and 'mapping who/what a document is about', but no sentence is wasted in a damaging way.

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?

An output schema exists, so return-value explanation is correctly omitted, and the caveat paragraph covers the main interpretive risk (co-occurrence ≠ semantic relation, `unknown` entity types). The only real gap is the undocumented `max_entities` behavior.

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?

Schema coverage is 0%, so the description must compensate. It meaningfully explains the `url` vs `text` precedence ('fetched first' / 'used directly') and implicitly motivates `include_centrality` via the ranking sentence, but `max_entities` is never mentioned and no defaults or bounds are given for any parameter.

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?

Opens with a specific verb+resource: 'Build a knowledge graph of entities and relationships from a page or text', and the second sentence names exactly what is extracted and ranked. It is clearly distinguishable from siblings like web_extract or web_rag_context, though it never names them 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?

Gives concrete usage context ('useful for mapping who/what a document is about and how they connect, rather than reading it linearly') and states the url-vs-text selection rule. It stops short of naming an alternative sibling or stating when not to use it.

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

Deploy Server

Other Tools