Skip to main content
Glama
Sign In

Citehound

by io.github.andacuzel
OverviewDiscussionsAdmin

Get Citehound research

get_research
Read-onlyIdempotent

Returns Citehound’s published research: with no argument, the list of reports (the llms.txt and crawler study, the AgaOne case study and the benchmark data) with title, date, one-line finding and URL; with a slug, the key findings, the method limits, the URL and a ready line for citing it. Findings are checked against the published pages and data files. Every study measures readiness inputs, not whether any assistant names a brand. Read-only, fetches nothing external. Use when the user wants evidence for a claim about AI crawler access or llms.txt, a statistic to cite, or the reports behind the benchmarks.

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

Input Schema

NameRequiredDescriptionDefault
slugNoOptional. A report slug from the list this tool returns with no argument. Omit to list the reports.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover safety (readOnlyHint, openWorldHint false, idempotent, non-destructive), and the description adds genuinely new context beyond them: 'fetches nothing external', 'findings are checked against the published pages and data files', and the important scope caveat that studies measure readiness inputs, not whether any assistant names a brand. This is material behavioral disclosure an agent cannot infer from structured fields.

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?

Content is well front-loaded and every clause (report inventory, slug-mode return, verification note, scope caveat, usage cue) carries information. The opening sentence is a dense, semicolon-chained run-on, which slightly taxes parsing but wastes nothing.

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?

With no output schema, the description carries the burden of explaining return values and does so for both invocation modes, plus a caveat about what the findings do and do not prove. An agent has everything needed to call it correctly and set user expectations.

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 100% and the single slug parameter is documented, so the baseline is 3. The description goes further by describing what each mode returns and clarifying that the slug comes 'from the list this tool returns with no argument', which adds real semantic guidance about the value's origin.

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 ('Returns Citehound's published research') and enumerates the concrete content returned in both modes (report list with title/date/finding/URL; slug mode with findings, method limits, citation line). The dual no-arg vs slug behavior is spelled out, letting an agent predict the output without opening the schema.

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

Usage Guidelines4/5

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

Explicitly names triggering situations: 'evidence for a claim about AI crawler access or llms.txt, a statistic to cite, or the reports behind the benchmarks.' Clear context, but it does not name the adjacent siblings (get_benchmark, get_methodology, get_sample_report) as alternatives or say when to prefer them, leaving some routing ambiguity.

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

All Citehound toolsInspect
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