Skip to main content
Glama

Metis — Create Focus Area

create_focus_area

Create a focus area to stay current on a subject with precise keyword groups, combining terms across axes to retrieve relevant news and literature.

Instructions

Define a focus area — a lens over news, literature and your own thinking.

A focus is for a subject you want to stay CURRENT on, as opposed to a course
you finish or a project you deliver. It owns no content: it is a saved query
plus a place to write, so removing it later cannot remove anything.

`keyword_groups` is the important argument, and it is groups rather than a
list on purpose: OR within a group, AND across groups. "AI in health" is a
conjunction of two axes, and a flat list returns "Can AI ever be conscious?".

Args:
    title: Human name, e.g. "AI in Health & Epidemiology".
    keyword_groups: JSON list of lists, e.g.
        '[["artificial intelligence","machine learning","llm"],
          ["health","clinical","epidemi","surveillance"]]'
    subtitle: One line on what this focus is for.
    layers: Comma-separated knowledge-layer slugs to search for documents.
    overview: The standing narrative — what matters here and why.
    activate: Put it on the shelf immediately (max 3 active).

Returns:
    The created focus and its shelf state.

Input Schema

NameRequiredDescriptionDefault
titleYes
layersNo
activateNo
overviewNo
subtitleNo
keyword_groupsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the disclosure burden and does it well: it explains that a focus 'owns no content' and that removing it 'cannot remove anything,' which is non-obvious and directly addresses reversibility/safety. It also surfaces the 'max 3 active' constraint on activate and states what is returned. Missing only operational details like permission requirements.

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 purpose and the key mental model, then cleanly organized into Args and Returns. Slightly discursive in the opening paragraphs, but each sentence contributes a distinct idea (scope, semantics, constraint) rather than restating the signature.

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?

Six parameters, zero schema descriptions, no annotations — the description covers every argument, the behavioral contract (no owned content, max 3 active), and briefly the return value even though an output schema exists. Nothing an agent needs to call it correctly is missing.

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 0%, so the description must compensate, and it documents all six parameters including the non-obvious one: keyword_groups is a string containing JSON, with the OR-within / AND-across semantics plus a concrete two-axis example explaining why groups rather than a flat list. That is meaning the raw schema cannot convey.

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 (define/create) and a well-bounded resource (a focus area), then immediately differentiates it conceptually from sibling concepts: 'a subject you want to stay CURRENT on, as opposed to a course you finish or a project you deliver.' An agent can tell this apart from create_project or save_course_curriculum 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 Guidelines4/5

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

Gives a clear selection criterion — a focus is for ongoing subjects, not finished courses or delivered projects — which implies when to reach for this rather than the project/course creation siblings. It does not explicitly name those sibling tools or say when NOT to create a focus (e.g., duplicates), so it stops short of full routing guidance.

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