DevTune MCP

devtune_get_visibility_diff

Read-onlyIdempotent

Compare the current visibility window with the previous window of the same length: citation totals for each window, their change in delta, and a daily series for the current window. primaryShare and shareOfVoice are percents, null when their citations total 0, each with a sibling Range holding a 90% range as low and high in percent, successes and n counted in citations, and directional true when there are too few citations to rely on. comparisons.primaryShare and comparisons.shareOfVoice say whether each share moved: report a change only when comparison is up or down. no_clear_change means the 90% interval on the difference includes zero, so the windows do not show a move; not_comparable with notComparableReason unmeasured means a window has no citations. difference, low and high are in percentage points. The default aggregates only currently active project platforms.

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": "devtune_get_visibility_diff"
  }
}

Input Schema

Name	Required	Description
`topicId`	No	Filter by topic UUID.
`platform`	No	Filter by AI platform (e.g. chatgpt, perplexity, gemini).
`windowDays`	No	Rolling window in days: 30 or 90. Defaults to 30.
`promptScope`	No	Which topics to count: all (default), branded (only topics whose every prompt names the project’s own brand) or unbranded (every other topic, mixed ones included). Prompts that name the brand usually get it mentioned, so unbranded matches the dashboard headline. Applies together with topicId.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

addedInput schema / properties / promptScope

Added value: +{
+  "description": "Which topics to count: all (default), branded (only topics whose every prompt names the project’s own brand) or unbranded (every other topic, mixed ones included). Prompts that name the brand usually get it mentioned, so unbranded matches the dashboard headline. Applies together with topicId.",
+  "enum": [
+    "all",
+    "branded",
+    "unbranded"
+  ],
+  "type": "string"
+}

AddedOct 31, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the read-only annotations, it explains null handling for zero-citation windows, directional flags for too-few citations, comparison states including no_clear_change and not_comparable with reason, units in percentage points, and the default active-platform aggregation. This gives the agent substantial behavioral context for interpreting results.

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?

It is dense and front-loads the comparison purpose, then explains output semantics without obvious filler. However, it is a long run-on paragraph and could be structured more clearly for readability.

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?

With no output schema, the description carries the return-value burden and does so well by defining the comparison fields, share semantics, null cases, and percentage-point units. It is nearly complete, though it could more explicitly position the tool against siblings and clarify the daily series shape.

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 description coverage is 100%, so all four parameters are already documented. The description adds only the default active-platform aggregation and the same-length window comparison; it does not add much parameter-specific semantics beyond the schema.

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?

The description opens with a specific verb and resource: it compares the current visibility window against the previous window of the same length. It also names the returned comparison metrics and daily series, which clearly distinguishes it from sibling visibility summary/response tools.

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?

The comparison purpose implies when to use it, and it notes that the default aggregates only currently active project platforms. However, it does not explicitly say when to use this versus siblings like get_visibility_summary or citation_stats, nor does it state exclusions.

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

All DevTune MCP tools Inspect

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

Need Help?