Skip to main content
Glama
SVerITG

Metis

by SVerITG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Metis — Suggest Interests From Work

suggest_interests_from_work

Analyzes a researcher's own papers, projects, and notes to find recurring domain terms missing from their declared interests, then proposes those suggestions, with the option to apply them to the library list.

Instructions

Read the researcher's own work and propose interests they have not declared.

Interests should not depend on someone being able to articulate them from a
blank field. Their work already states them — project titles, captured ideas,
what their papers are about, what their sessions keep returning to. This mines
those sources for recurring domain terms and proposes the ones missing from
their declared lists.

Proposals go to the LIBRARY list by default: what recurs in someone's own
papers and projects is what they want a background on. What they want to hear
about in the NEWS is a different question, frequently outside their work
entirely, and cannot be mined from it — that one has to be asked. See
`start_interest_interview()`.

Args:
    apply: False (default) proposes only, so the researcher decides. True adds
        the suggestions to `library_interests` directly — use when they have
        said to go ahead, or for a silent top-up during onboarding.
    top: How many suggestions to consider. Default 12.

Returns:
    Suggested terms with what evidence supports each, and what was already
    declared so nothing is proposed twice.

Input Schema

NameRequiredDescriptionDefault
topNo
applyNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.6/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the burden and does well: it discloses that the tool reads multiple own-work sources, that `apply=True` writes directly into `library_interests`, and that already-declared terms are never proposed twice. It does not discuss permissions, cost, or failure modes when a source is empty, which keeps it short of a 5.

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 core action, then Args/Returns. The rationale paragraph on why interests shouldn't depend on self-articulation is persuasive but costs a sentence or two beyond what an agent needs to call the tool; still, the whole is short for the amount of routing information it delivers.

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 two-parameter, no-annotation tool, everything an agent needs is present: sources mined, target list, dedupe guarantee, both parameter behaviors, the sibling for the unmineable case, and the return shape (suggested terms plus supporting evidence plus already-declared terms) even though an output schema also exists.

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 0%, so the description must compensate and does: `apply` gets default, effect, and two situational triggers; `top` gets default 12 and a definition. `top` is described as 'how many suggestions to consider', which is slightly ambiguous about whether it caps returned proposals or mined candidates.

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+resource+scope: reads the researcher's own work (project titles, ideas, paper topics, sessions) and proposes undeclared interests. It explicitly contrasts with the sibling `start_interest_interview()` and explains that news interests, unlike library interests, cannot be mined from work — a domain distinction an agent could not infer from the name.

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 when-to-use routing: default proposes only for researcher review, `apply=True` when they've said to go ahead or for a silent onboarding top-up, and `start_interest_interview()` for news-category interests. It even states why the alternative exists rather than just naming it.

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