Skip to main content
Glama
Sign In
Proofpage MCP Server

Proofpage MCP Server

by Mehxeo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

proofpage_collect

Collect a configured source by ID within shared cooldown limits to refresh web evidence for local search, cited results, and verification.

Instructions

Collect an existing configured source within shared cooldowns.

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": {
      "source_id": "<source_id>"
    },
    "name": "proofpage_collect"
  }
}

Input Schema

NameRequiredDescriptionDefault
source_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

C2/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. "Shared cooldowns" hints at rate limiting or shared quota, but it does not say whether the call is a mutation, whether it is synchronous or asynchronous, what it costs, or what happens when the cooldown is active (error? queue?).

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?

One short sentence with no padding, so it is appropriately sized, but the terseness reflects under-specification rather than economy — the core action is never defined.

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

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No annotations, no output schema, undocumented parameter, and a vaguely named action in a domain full of similarly named siblings. An agent has nothing to decide whether calling this is safe, cheap, or idempotent.

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% for the single required parameter source_id, and the description adds only that the source must already be "configured" and exist. That is a small semantic gain, but nothing about format, acquisition path, or error behavior for an invalid ID.

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

Purpose2/5

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

"Collect an existing configured source" gives a verb and a resource, but "collect" is opaque jargon that never resolves into a concrete action (fetch? snapshot? enqueue a run?). It is barely distinguishable from siblings like proofpage_recheck_source or proofpage_schedule_source, which also act on a configured source.

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

Usage Guidelines2/5

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

There is no statement of when to use this versus recheck_source, schedule_source, or ensure_fresh. The only contextual hint is "within shared cooldowns," which describes a constraint rather than a selection rule.

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