Skip to main content
Glama

MentionFox

by io.github.OsakaSaul
OverviewDiscussionsAdmin

Short brief on one subject

get_snapshot

A short brief on one subject — a person, a firm, a publication — written from what is on the record and returned as text plus a link to a formatted page you can share. Say who the subject is and what kind of subject they are, because the brief is written for the kind: what matters about a founder is not what matters about a doctor. What comes back is about a page: who they are, what the record shows, what stands out, and what to be careful of. Ask for the same subject twice and the second time is free — you are handed the brief already written, unchanged, rather than paying for it again. Nothing is charged when there is no such subject or too little on the record to say anything useful. Subject types you can ask for, and what each costs: company (5 credits), counterparty (5 credits), crypto_coin (5 credits), donor (5 credits), executive (5 credits), expert_witness (5 credits), founder (5 credits), insurance_underwriting (5 credits), investor (5 credits), journalism_person (5 credits), journalist (5 credits), litigation_funder (5 credits), nft_collection (5 credits), pe_firm (5 credits), penny_stock (5 credits), physician (10 credits), pre_ipo_secondary (5 credits), publication (5 credits), source (5 credits), spac_sponsor (5 credits), specific_fund (5 credits), vc_firm (5 credits), wealth_advisor (5 credits). Use this when someone says "who is this", "what should I know before I meet them", "quick read on this firm". For the long version, use get_full_report.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
companyNoOptional. The organisation they are with, or the domain, when the name on its own could mean several people.
subjectYesWho or what the brief is about — a person's name, a firm, a publication. Add the employer or domain to it if the name alone is common.
new_reportNoSet this only when you want a fresh brief on a subject you already have one for. It writes and charges for a second brief and leaves the earlier one untouched. Leaving it off hands you the brief you already bought, free.
subject_typeYesWhich kind of subject this is. The accepted values are listed in this tool's description, each with its price; they are read from the live price list, so ask for one of those exactly.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the annotations by disclosing per-type credit costs, the cache rule (the same subject asked twice is free and unchanged), the no-charge conditions (no such subject, or too little on the record), and the fact that new_report writes and charges for a second brief. This is exactly the pricing/side-effect context that readOnlyHint=false and idempotentHint=false hint at but do not explain.

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?

Front-loaded with the deliverable, then usage, then cost/caching rules — every sentence carries information. The 23-entry price list is bulky, but it substitutes for the missing enum in the schema, so it earns its space.

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?

For a paid, open-world lookup with no output schema, the description covers cost, caching, failure/refund conditions, what the returned page contains, and how to size the request (subject + subject_type). Nothing an agent needs before calling is missing.

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%, so baseline is 3, but the description adds meaning the schema lacks: the full subject_type vocabulary with per-type prices, plus the note that names should be qualified with employer/domain when ambiguous. It does not add much to new_report beyond the schema's own wording.

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 concrete deliverable (a one-page brief on a single subject) and its return shape (text plus a shareable link), then explicitly names get_full_report as the long-form alternative. An agent can distinguish it from get_dossier, get_full_report, and enrich_person without opening another schema.

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

Usage Guidelines5/5

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

Gives explicit trigger phrasings ('who is this', 'quick read on this firm') and an explicit alternative ('For the long version, use get_full_report'). It also constrains which subject_type values are legal and notes they must match the live price list exactly.

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

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