PJQ — Public Judgment Quotient
Server Details
Observatory of public media reception: classify YouTube comments for mood, support and controversy.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 7 of 7 tools scored. Lowest: 3.3/5.
Each tool serves a distinct purpose: controversial_videos for high-controversy topics, mood_matrix for aggregate mood metrics, video_classify for the full analysis pipeline, video_exemplars for quote extraction, video_history for temporal snapshots, videos_list for cataloging, and video_verdict for the latest verdict. Descriptions clearly differentiate them, reducing ambiguity for an agent.
Tool names mix prefix styles: most use 'video_' (e.g., video_classify, video_history) but 'mood_matrix' and 'controversial_videos' deviate. Additionally, 'videos_list' uses plural 'videos' while others use singular 'video', breaking consistency. Overall pattern is partially predictable.
With 7 tools, the server is well-scoped for its purpose of analyzing public judgment on YouTube videos. Each tool covers a specific operation without redundancy, and the count is within the ideal range for agent usability.
The tool surface covers listing, verdict retrieval, history, classification, exemplar extraction, and aggregate views. Minor missing features (e.g., search by keywords or domain-only filtering) are non-critical, and the core workflow from classification to analysis is fully supported.
Available Tools
7 toolscontroversial_videosAInspect
Самые спорные видео — высокий controversy (раскол SUP/AGA, 0..1).
Для поиска тем с максимальным расколом мнений в аудитории. Отличается от mood_net (направление): controversy = размер раскола. 1.0 = война 50/50.
limit: сколько вернуть (1..20, default 5). days: макс возраст вердикта (default 30).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries the burden. It explains the controversy scale (0..1) and parameter semantics (limit range 1-20, days as max verdict age). However, it lacks explicit statement that the operation is read-only or any side effects. Still, the behavioral description is clear and complete for the tool's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two highly efficient sentences: first explains purpose and differentiation, second details parameters. No redundant phrases; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no required, no enums, output schema present), description fully covers purpose, parameter constraints, and differentiation. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds crucial meaning: 'limit' specified as count (1-20, default 5) and 'days' as max verdict age (default 30). This compensates for missing schema descriptions and adds clear value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns controversial videos based on audience split (SUP/AGA), with a specific verb 'поиск' (search) and distinct resource. It explicitly differentiates from sibling 'mood_net' by defining controversy as magnitude of split rather than direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says when to use ('Для поиска тем с максимальным расколом мнений') and contrasts with mood_net, providing sibling distinction. However, it does not explicitly state when not to use or mention alternative tools beyond mood_net.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mood_matrixAInspect
Агрегатный mood-вью с фильтрами по домену и tier.
domain ∈ {POL, ECON, BIZ, TECH, EDU, ENV, SOC, MED, TRV, ENT, LIFE, unassigned}.
tier ∈ {official, semi_official, independent, unassigned}.
Возвращает последние limit снапшотов с расчётом mood_net и support_pct.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | ||
| limit | No | ||
| domain | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states it returns snapshots with calculations, but does not disclose whether it is read-only, destructive, or any side effects. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, two lines that front-load the core purpose and parameter options. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the tool has only three optional parameters, the description covers the essential behavior and filter options. It could improve by noting default behavior when params are null, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It lists the allowed enum values for domain and tier, and clarifies that 'limit' controls the number of snapshots. This adds significant meaning beyond the schema, though it omits default values and meaning of null.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an aggregate mood view with filters by domain and tier, listing allowed values. It specifies it returns the last 'limit' snapshots with mood_net and support_pct. This is specific and distinct from sibling tools which are video-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for filtered mood aggregation but does not explicitly state when to use this tool versus alternatives. Since sibling tools are unrelated, lack of explicit guidance is less critical, but it still misses the opportunity to clarify context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
video_classifyAInspect
Полный pipeline: URL -> вердикт в SQLite + Obsidian vault.
ВАЖНО: долгая операция, ~10-20 мин на 300 комментов (haiku 10м + sonnet QA 8м).
qa=False — пропустить sonnet-эскалацию (быстрее, но без QA-метрик).
Возвращает verdict_id + summary (hard_counts + mood + QA-stats).
На публичном сервере отключён env-флагом PJQ_PUBLIC_CLASSIFY_DISABLED=1 — синхронный classify не выдерживает параллельной нагрузки и угрожает Claude Max-подписке. Замена на job queue + worker в работе.
| Name | Required | Description | Default |
|---|---|---|---|
| qa | No | ||
| url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully covers behavior: discloses side effects (writes to databases), duration, and environmental limitations (disabled on public server). This is comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet informative, with key information front-loaded ('Полный pipeline: URL -> вердикт') and important caveats in a clear structure. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (pipeline, long operation, dual storage, optional QA), the description covers purpose, usage guidelines, parameter semantics, and environmental context. Output schema exists, so return value detail is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains the 'qa' parameter meaning and impact (skip sonnet escalation, faster but no QA metrics). The 'url' parameter is self-explanatory as the video URL.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a full pipeline from URL to verdict stored in SQLite and Obsidian vault. It distinguishes itself from sibling tools like 'video_verdict' by emphasizing the complete pipeline nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: suggests using 'qa=False' for faster execution when QA metrics are not needed, warns about long operation time (10-20 min), and notes that on the public server it's disabled due to load, with a replacement in progress.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
video_exemplarsAInspect
Exemplar-цитаты последнего снапшота по video_id.
Если stance задан (SUP/AGA/NEU/OFF/THIN/SUS/AGN) — фильтруется по нему. Это единственное место, где хранится текст комментариев.
| Name | Required | Description | Default |
|---|---|---|---|
| stance | No | ||
| video_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions it returns data from the last snapshot and is the only source of comment text, implying a read-only operation, but does not explicitly state safety, rate limits, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with three short sentences. First sentence defines purpose, second adds filtering detail, third notes uniqueness. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description covers purpose, parameter details, and a key uniqueness point. Adequate for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning to both parameters: explains that video_id identifies the video, and lists the possible stance values (SUP/AGA/NEU/OFF/THIN/SUS/AGN) and that it filters when set. Compensates for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves exemplar quotes from the last snapshot for a given video_id, with optional stance filtering. It also notes it's the only store of comment text, distinguishing from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for getting exemplar quotes but provides no explicit guidance on when to use versus siblings or when not to use. The uniqueness statement hints at its role but lacks direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
video_historyBInspect
Все снапшоты по video_id во времени (от старого к новому).
Полезно для анализа динамики mood — как меняется приём со временем.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that data is sorted by time but does not mention permissions, rate limits, or side effects. For a read-only tool, minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Purpose and usage context are front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return values need not be described. Description is adequate for a simple list tool but lacks details on pagination or limits. Sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds meaning by stating that the parameter is the video_id for which all snapshots are returned. However, no format or validation details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns all snapshots for a video_id over time, sorted from old to new. The verb 'list' is implied, and resource is 'snapshots'. It distinguishes from siblings like mood_matrix by focusing on historical data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for analyzing mood dynamics, but no explicit when-to-use or exclusions. Does not specify when not to use or which sibling to choose instead, e.g., mood_matrix for aggregate mood analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
videos_listAInspect
Все видео из канона. Поля: id, external_id, title, channel_name, domain, tier, first_seen.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool returns, but does not mention that it is read-only, any required authentication, or rate limits. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus a field list, which is highly concise and front-loaded. Every word contributes to understanding the tool's output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description is sufficient to inform an agent about the tool's return. However, it lacks any mention of filtering, ordering, or edge cases, and sibling tools are not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is trivially 100%. Per the rubric, baseline for 0 parameters is 4. The description adds no parameter meaning, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns 'All videos from the canon' and lists the fields included, which is a specific verb+resource. It distinguishes from sibling tools like 'controversial_videos' and 'mood_matrix' by focusing on a broad list of canon videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention preconditions, exclusions, or comparison with sibling tools such as 'video_classify' or 'video_verdict'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
video_verdictBInspect
Последний снапшот вердикта по YouTube video_id (11 симв.).
Возвращает строку из verdicts + расклад в %% (из v_verdict_mood): n_sampled, cnt_* по 7 категориям, pct_*, mood_net (-1..+1), support_pct, qa_sampled_pct / qa_agreement_pct, classifier_model, rubric_version.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given the absence of annotations, the description should disclose whether the tool is read-only, has side effects, or requires specific permissions. It only describes the output structure, not behavioral traits beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences covering purpose and output. It avoids unnecessary details and is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface with one parameter and a detailed output schema. The description explains the output fields, but it lacks context on when to use this tool, error handling, or typical use cases. Given the sibling tools, additional guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides 'video_id' as a string. The description adds that it is a YouTube video_id must be 11 characters, which provides semantic context. Since schema coverage is 0%, the description compensates well by explaining what the parameter is used for and the return format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the last snapshot of a verdict for a given YouTube video ID. It specifies the exact return fields, which differentiates it from siblings like 'video_classify' and 'mood_matrix'. However, it does not explicitly contrast with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only describes the output, leaving the agent without context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!