Skip to main content
Glama
Sign In

Spaces by Peakflo

by ai.peakflo
OverviewDiscussionsAdmin

graph_linked_datastores

Read-only

List datastores linked to a graph or workflow subject. Returns hydrated details including datastore name, document metadata, and chunk previews. Use to inspect what supporting documents are associated with an entity, relationship, entity type, or workflow node.

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": {
      "subject_type": "<subject_type>",
      "subject_id": "<subject_id>"
    },
    "name": "graph_linked_datastores"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax results (default 50)
subject_idYesID of the subject (entity ID, relationship ID, entity type ID, "<workflowId>:<nodeId>", or workflow ID)
subject_typeYesType of subject to query linked datastores for
include_chunksNoWhether to include chunk-level links (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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 beyond them by disclosing the shape of the response (hydrated datastore name, document metadata, chunk previews). It does not mention pagination or how the default limit of 50 behaves in practice.

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?

Three short sentences: purpose first, return payload second, use case third. Front-loaded and free of filler, with only mild overlap between the subject-type list and the stated return contents.

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 four-parameter read tool with full schema descriptions and no output schema, the description covers what it does, what comes back, and when to reach for it. Only the relationship to the sibling link and datastore query tools is left implicit, which is a minor 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?

Schema coverage is 100% and each parameter carries its own description, including the enumerated subject types and the '<workflowId>:<nodeId>' format. The description only partially mirrors this by listing subject kinds and implying include_chunks via 'chunk previews', so it adds little beyond the schema; baseline 3 applies.

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?

States a specific verb and resource: 'List datastores linked to a graph or workflow subject,' plus what is returned (hydrated details, document metadata, chunk previews). It is clearly distinguishable from graph_link_datastore, though it never names that sibling or any of the datastore_* tools 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?

'Use to inspect what supporting documents are associated with an entity, relationship, entity type, or workflow node' gives a concrete when-to-use context. No exclusions or alternatives are offered, e.g. when to prefer datastore_query or datastore_get, but the intended usage is unambiguous.

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

All Spaces by Peakflo toolsInspect
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.

Resources