Skip to main content
Glama
AntonioBlago

VisiblyAI MCP Server

by AntonioBlago

score_text

Score text against brand rules and AI-slop patterns, returning compliance insights. Add a query_id to fetch NSS results; no data is stored.

Instructions

Score a text against the project's brand rules and AI-slop patterns; with a ready query_id also the NSS. Credits: 0.

Deterministic, nothing is stored. format: html|markdown (max 100000 chars). nss is null with a reason when no finished analysis is referenced.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNomarkdown
contentYes
query_idNo
persona_idNo
project_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.1

TDQS

B3.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden, and it discloses meaningful traits: 'Deterministic, nothing is stored,' 'Credits: 0,' and that nss returns null with a reason when no analysis is referenced. It does not cover permissions or the shape of the score result, but the cost/statelessness disclosure is valuable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The primary purpose is front-loaded and the text is short, but it is broken into fragments (a mid-sentence metadata line, a trailing note about nss) that read as terse notes rather than a coherent statement, slightly hurting scannability.

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. Still, for a 5-parameter tool with 0% schema coverage, leaving three parameters (content, project_id, persona_id) unexplained makes the definition incomplete for confident invocation.

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 description coverage is 0% over 5 params, so the description must compensate. It clarifies format (html|markdown, max 100000 chars) and hints at query_id's role for NSS, but content, project_id, and persona_id are entirely undocumented in both schema and description.

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 (Score) and resource (a text) plus the criteria (brand rules and AI-slop patterns), which distinguishes it from siblings like get_scorecard and seo_checklist. The 'NSS' acronym and 'query_id' extension are not defined, adding some ambiguity.

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 'with a ready query_id also the NSS' clause implies a usage scenario, suggesting the tool is used standalone or linked to a finished analysis. However, there is no explicit when-to-use/when-not guidance and no named alternative among the many siblings.

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