Flowlines - MCP Analytics

Inspect an MCP recommendation

get_mcp_recommendation

Read-onlyIdempotent

Inspect a saved MCP recommendation. Start with overview for rationale, confidence, qualifications, scope, sample coverage and supporting call IDs. Read change for the exact before/after definition and baseVersionId (or behavior/capability proposal); read evidence for retained calls, sessions, contract, drift and profiles. Large sections return jsonFragment: concatenate decoded fragments in cursor order and parse JSON only after nextCursor is null. Keep the same recommendation and section when paging. A conflict means the record changed: discard fragments and restart. A partial fragment is never a complete suggested fix. Check the current repo contract against the saved base before applying; this read tool does not apply changes. Results may contain end-user personal data: quote minimally and mask direct identifiers.

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": {
      "reason": "<reason>",
      "user_intent": "<user_intent>",
      "namespace_id": "<namespace_id>",
      "recommendation_id": "<recommendation_id>"
    },
    "name": "get_mcp_recommendation"
  }
}

Input Schema

Name	Required	Description	Default
`cursor`	No	Opaque cursor from a previous page.
`reason`	Yes	A short phrase saying why you are calling this tool, for example: find unpaid invoices.
`section`	No		overview
`user_intent`	Yes	One sentence describing what the user is trying to accomplish. Keep it the same across calls until the user's goal changes.
`namespace_id`	Yes	Flowlines namespace UUID.
`recommendation_id`	Yes

Output Schema

Name	Required	Description	Default
`data`	Yes
`notice`	No
`truncation`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With readOnlyHint/idempotentHint already covering safety, the description adds substantial operational behavior: large sections return jsonFragment that must be concatenated in cursor order and parsed only after nextCursor is null, a conflict means the record changed and fragments should be discarded, and a partial fragment is never a complete fix. It also discloses a privacy constraint (end-user personal data, quote minimally and mask identifiers).

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 the purpose, then ordered by reading flow, and every sentence carries operational weight (paging mechanics, conflict handling, privacy). It is a dense single block mixing several concerns, which costs a little readability but no sentence is filler.

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?

An output schema exists, so return-value explanation is not required; the description covers everything else an agent needs — section choice, pagination protocol, conflict recovery, the no-write guarantee, and the data-handling constraint. Nothing necessary to invoke it correctly is missing.

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 67% and the section enum has no inline descriptions, but the description richly explains each section's payload (overview/change/evidence) and clarifies cursor semantics for fragment assembly and paging. It does not add meaning for reason, user_intent, or the two UUIDs beyond the schema, so it stops short of full compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Inspect a saved MCP recommendation") with singular scope, which inherently separates it from the list_mcp_recommendations and get_mcp_overview siblings. An agent immediately knows this reads one saved recommendation record.

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 reading order (overview first for rationale/confidence/scope, then change for before/after, then evidence for retained calls/contract/drift), plus the rule to keep the same recommendation and section while paging. It also states the when-not: this read tool does not apply changes, and you must check the repo contract against the saved base first.

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

All Flowlines - MCP Analytics tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?