Skip to main content
Glama

compare_to_baseline

Read-only

Check if a text fits a writer's usual style by comparing function-word frequencies against earlier samples, returning distance measures and highlighting unusual word usage.

Instructions

Compares one piece of writing against several earlier pieces by the SAME person, using function-word frequencies (Burrows's Delta). Returns how far the questioned text sits from that writer's centre, alongside how far each of the writer's own pieces sits from it — measured identically, so the scale is the writer's own variation rather than a threshold invented by this tool. Also returns which function words differ most, with rates per 1,000 words, and how many words are used at a rate the writer has never used them at. Runs fully offline; nothing is sent anywhere. WHAT THIS CANNOT DO: it cannot tell you who wrote something. There is no "different author" result and there must not be one in your summary either. Style moves with the assignment, the genre, the deadline, a co-author, an editor, and with a person simply getting better. A text outside the range is a reason to ask what changed; it is NEVER a conclusion, an accusation, or evidence of misconduct. The most valuable outcome is the reassuring one: a text INSIDE the range settles a suspicion, and saying so plainly is usually the most useful thing you can do with this tool. It refuses to answer on thin evidence and returns "Undetermined" instead of a number — do not work around that by rerunning with less text or by estimating one yourself.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
languageNoLanguage: "en" or "es". Default "en".en
earlierWorkYesEarlier pieces by the same writer. At least ~1,400 words in total across them.
questionedTextYesThe piece being asked about. At least 300 words.
questionedTitleNoOptional title for the questioned piece.questioned
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses rich behavioral details: it runs fully offline, refuses on thin evidence returning 'Undetermined', uses the writer's own variation as the scale, and explicitly forbids interpreting results as a 'different author' conclusion. No contradictions with annotations.

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

Conciseness5/5

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

Although lengthy, every sentence earns its place. The description is well-structured: definition, limitations, recommended use, and behavioral caveats are clearly separated. The 'WHAT THIS CANNOT DO' section is critical and formatted for emphasis, adding value without redundancy.

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 complex tool with no output schema, the description fully explains expected return values (distances, function-word rates, never-used rates) and handling of insufficient evidence ('Undetermined'). It also covers interpretation and ethical cautions, making it complete for real-world use.

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

Parameters3/5

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

Schema coverage is 100%, so parameters are fully documented in the input schema. The description adds conceptual context (e.g., 'earlier pieces by the SAME person') but does not add significant new parameter-specific details beyond what the schema already states. Baseline 3 applies.

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 description clearly states the tool's function: 'Compares one piece of writing against several earlier pieces by the SAME person, using function-word frequencies (Burrows's Delta).' This specifies the verb and resource, and the explicit note that it cannot determine authorship distinguishes it from sibling analysis tools.

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?

The description provides explicit when-to-use guidance: 'The most valuable outcome is the reassuring one: a text INSIDE the range settles a suspicion.' It also states what it cannot do ('it cannot tell you who wrote something') and advises against workarounds for 'Undetermined' results, giving clear exclusions and alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/peopleworks/SignsofAI'

If you have feedback or need assistance with the MCP directory API, please join our Discord server