Skip to main content
Glama

Recorded corporate connection path

actor_path
Read-onlyIdempotent

Find a recorded path between two corporate-network records within three hops. Requires the customer's account. A clipped search returns incomplete, never a claim that no relationship exists. Return the ordered hops with their source/publication evidence. Costs 15 credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNo
limitNo
source_idYes
target_idYes
source_kindYes
target_kindYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior3/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 genuinely new behavior: a 15-credit cost and the important caveat that a clipped search yields incomplete results rather than a negative claim. It does not explain how depth/limit clipping actually works, which is the other half of that caveat.

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?

Five short sentences, each carrying distinct information: purpose, prerequisite, clipping caveat, return shape, cost. Constraint and purpose are front-loaded with no filler.

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

Completeness3/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 values need not be explained, and cost/prerequisite/caveat are covered. The gap is parameter documentation: with 0% schema coverage, an agent has no guidance on what depth and limit do or how they interact with the stated three-hop bound.

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

Parameters2/5

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

Schema coverage is 0% and none of the six parameters (depth, limit, source_kind/id, target_kind/id) are defined. The only trace is 'within three hops', which loosely maps to the depth default of 3. For a zero-coverage schema the description should carry this burden and largely does not.

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+scope: 'Find a recorded path between two corporate-network records within three hops.' An agent can distinguish this from a generic graph query. However, it never names the closest siblings (actor_network, entity_relationships), so the boundary is left to inference.

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

Usage Guidelines3/5

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

It gives one prerequisite ('Requires the customer's account') but no when-to-use guidance or alternatives. With actor_network and entity_relationships in the sibling set, the description should say when a between-two-nodes path query is preferred over a network expansion.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources