Skip to main content
Glama

MentionFox

by io.github.OsakaSaul
OverviewDiscussionsAdmin

Full written report on one subject

get_full_report

The long version: a full written report on one subject, section by section, ending with the sources it drew on. Where the short brief runs to a page, this runs to several thousand words. It is fixed at the moment it is made — it records what the record said on that day and is never edited afterwards, so what you show someone in six months is what you bought. If you want a fresher picture, you ask for a new one: it is written and paid for separately and the old one stays exactly as it was. Asking again for a subject you already have a report on hands you the one you already bought, free. Writing takes a few minutes; if it is still being written when the call comes back you get a link and can return to it. Costs 50 credits and needs the Pro plan. Subject types you can ask for: accelerator (50 credits), company (50 credits), counterparty (50 credits), crypto_coin (50 credits), donor (50 credits), executive (50 credits), expert_witness (50 credits), founder (50 credits), insurance_underwriting (50 credits), investor (50 credits), journalism_person (50 credits), journalist (50 credits), litigation_funder (50 credits), nft_collection (50 credits), pe_firm (50 credits), penny_stock (50 credits), physician (50 credits), pre_ipo_secondary (50 credits), publication (50 credits), source (50 credits), spac_sponsor (50 credits), specific_fund (50 credits), vc_firm (50 credits), wealth_advisor (50 credits). For a company, put its website in company (for example subject "Flock Safety", company "flocksafety.com") and the report starts on that company straight away; a website on its own as the subject works too. If you give only a name and more than one company goes by it, nothing is charged: you get a short list of the companies it could be, each with its website and a line on what it does, and you call again with the right website in company. Use this when someone says "I need the full write-up", "proper due diligence before we commit", "the long one".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
companyNoOptional. The organisation they are with, or its website, when the name on its own could mean several. For a company report, put the company's website here (for example flocksafety.com) so the report runs on exactly that company without a follow-up question.
subjectYesWho or what the report is about — a person's name, a firm, a publication, or a company name or website.
new_reportNoSet this only when you want a NEW report on a subject you already have one for. It writes and charges for a second report; the earlier one is left untouched. Leaving it off returns the report you already bought, free.
subject_typeYesWhich kind of subject this is. The accepted values are listed in this tool's description; they are read from the live price list, so ask for one of those exactly.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / company / description
      Previous value: -"Optional. The organisation they are with, or the domain, when the name on its own could mean several people."New value: +"Optional. The organisation they are with, or its website, when the name on its own could mean several. For a company report, put the company's website here (for example flocksafety.com) so the report runs on exactly that company without a follow-up question."
    • changedInput schema / properties / subject / description
      Previous value: -"Who or what the report is about — a person's name, a firm, a publication."New value: +"Who or what the report is about — a person's name, a firm, a publication, or a company name or website."
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With readOnlyHint=false and idempotentHint=false already set, the description goes well beyond the annotations: immutability after generation, free re-retrieval of a previously purchased report, separate billing for new_report, 50-credit cost, Pro-plan requirement, multi-minute latency with an async link fallback, and a name-collision flow that charges nothing. The remaining gap is that it never says what the returned artifact actually looks like structurally (format, delivery, size limits).

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

Conciseness2/5

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

The purpose is front-loaded, but the body is bloated: the credit cost is restated 24 times as '(50 credits)' in the subject_type list, and the immutability/caching idea is spread across three overlapping sentences. Several clauses restate what the new_report and company schema properties already say.

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 costly, non-idempotent generation tool with no output schema, the description covers pricing, plan gating, latency and async retrieval, caching semantics, disambiguation fallback, and the full accepted subject_type set — everything an agent needs to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the schema explicitly defers to the description for subject_type ('listed in this tool's description') and there are zero enums in the schema — so the 24-value subject_type list here is the only place an agent can learn valid inputs. It also adds the concrete company/website disambiguation example, giving real value over the schema text.

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?

The opening sentence gives a specific verb and resource — 'a full written report on one subject, section by section, ending with the sources it drew on' — and immediately scopes it against 'the short brief', which lets an agent separate it from the lighter snapshot/dossier siblings without opening any 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?

Explicit trigger phrases are supplied ('I need the full write-up', 'proper due diligence before we commit', 'the long one') plus an explicit contrast with the shorter tool, and the new_report flow spells out exactly when to re-request versus accept the cached copy.

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