harmonica-mcp

Official

by harmonicabot

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.12.0
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., get_summary vs generate_summary are clearly read vs write; get_session vs get_responses vs list_participants have different purposes). The descriptions reinforce the boundaries, making misselection unlikely.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., list_sessions, create_session, delete_project, publish_sensemaking_topic). There are no mixed conventions or vague verbs, making the API predictable.
Tool Count3/5
With 21 tools, the set is on the heavier side but still scoped to the Harmonica platform's features (sessions, projects, templates, participants, messaging, publishing). It borders the 'heavy' threshold but remains functional.
Completeness4/5
The toolset covers most lifecycle needs: sessions have create/read/search/update, projects have full CRUD, summaries have get/generate, and participation via chat_message. Minor gaps exist (e.g., no session deletion, no explicit participant management), but these are workable.
Average 4/5 across 21 of 21 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden. It mentions the output ('shareable join URL') as a positive, but it does not disclose side effects (e.g., persistent record creation), permissions, or any behavioral nuances. 'Create' implies mutation, but the description does not elaborate on the creation's implications.
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?
The description is a single, front-loaded sentence that efficiently conveys the core purpose and output. It contains no fluff or redundant information, and every word earns its place. The brevity is appropriate given the rich schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters and no output schema, the description is quite thin. It only states the action and the return (a URL) but does not elaborate on what a 'Harmonica deliberation session' entails, prerequisites (e.g., template/project), or how the session behaves after creation. The schema fills in parameter meanings, but the description fails to provide broader operational context.
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?
The input schema has 100% coverage with descriptions for all 12 parameters, so the baseline is 3. The tool description itself adds no parameter information beyond the schema, but the schema is rich enough to compensate. The description does not contribute extra meaning beyond what the schema already provides.
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 verb ('Create'), the resource ('Harmonica deliberation session'), and the outcome ('get a shareable join URL'). This distinguishes it from sibling tools like update_session, get_session, and create_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention when to use it over other session tools or any prerequisites. The only usage hints come from the parameter descriptions in the schema, not from the tool description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Get details', which conveys a read-only action but adds little beyond the tool name. It does not disclose return format, error behavior, permissions, or scope of details, leaving significant ambiguity.
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?
The description is a single, front-loaded sentence with no unnecessary words. It earns its place by stating the tool's core function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description is vague about what 'details' includes. Without an output schema, the description should clarify the scope of returned information to be fully complete, but the basic purpose is clear.
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?
The input schema already fully documents the only parameter, session_id, as a required UUID string with 100% description coverage. The description adds no additional parameter semantics, but the schema covers the necessary meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get details of a specific Harmonica session', using a specific verb and resource. While it does not explicitly mention alternatives, the word 'specific' implies retrieval of a single session versus listing, which distinguishes it from sibling list_sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific session' implies use when a single session's details are needed, providing some context. However, no explicit guidance is given about when not to use it or which alternatives (list_sessions, search_sessions) might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the access scope. It does not disclose pagination behavior (despite a limit parameter), response format, or any side effects. The description is too minimal to inform the agent of behavioral details.
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?
The description is a single, concise sentence that front-loads the core action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward list operation with well-documented parameters, but the description lacks usage guidance and behavioral details, making it only minimally complete for an agent.
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?
The input schema has 100% description coverage with clear descriptions for limit, query, and status. The description adds no extra parameter semantics, so 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 uses 'List' as a specific verb, names the resource 'Harmonica deliberation sessions', and scopes to 'you have access to', clearly differentiating from get_session (singular) and search_sessions (advanced search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs search_sessions or get_session. It doesn't mention exclusions or alternatives, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the tool returns full conversation threads and warns about large data volume, but it does not mention side effects (e.g., read-only nature), pagination behavior, or error conditions. This is adequate but not rich.
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?
The description is two sentences, front-loaded with the primary purpose, followed by return characteristics and practical guidance. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a clear purpose and performance tip, but it does not fully clarify the relationship between 'participant responses' and 'full conversation threads', nor how the filters map to the response data. It is adequate given the rich schema, but leaves some ambiguity about the data structure and tool boundaries.
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?
The input schema has 100% description coverage for all 6 parameters, including filter semantics. The tool description itself does not add detail about individual parameters, so it neither enhances nor detracts from the schema's explanations. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves participant responses for a Harmonica session and returns full conversation threads. It specifies the resource and action, distinguishing it from list_participants and get_summary. However, it does not explicitly name alternative tools for comparison.
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?
The description provides clear context by recommending the use of filters to avoid fetching all data at once for large sessions. This implies a performance consideration but stops short of explicit when-to-use vs. alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It adds the 'AI-generated' context but does not disclose behavior when no summary exists, authentication needs, or return format. The read-only nature is inferred but not explicit.
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?
The description is a single, focused sentence with no filler words, efficiently stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description is largely sufficient. It lacks guidance on edge cases like missing summaries or differentiation from generate_summary, but covers the core purpose adequately.
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?
The schema covers the single parameter with a clear description ('Session ID (UUID)'). The description adds 'Harmonica session' context but no additional syntax or format detail beyond the schema.
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 uses a specific verb 'Get' and identifies a distinct resource ('AI-generated summary for a Harmonica session'), clearly distinguishing it from siblings like get_session and generate_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies retrieval of an existing summary but does not explicitly state when to use this tool versus generate_summary or get_session. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses a concrete action and return value, but it does not mention side effects, idempotency, or whether certain conditions (e.g., session state) must hold. This is acceptable high-level transparency but leaves important behavioral details undisclosed.
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?
The description is two sentences long, front-loaded with the primary action, and includes the key return value. Every word earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description sufficiently states what it does and what it returns, and the schema covers the parameters. However, the lack of an output schema means the description should also convey any return nuances; it does mention the opening facilitator message, which is helpful. Minor details like prerequisite session state are not covered, but overall the description is adequate.
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?
The input schema already covers all four parameters with descriptions, so baseline is 3. The tool description adds no parameter-specific information beyond what the schema provides, so it neither improves nor degrades the semantic clarity.
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 a specific verb ('submit') and resource ('pre-session question answers'), and it adds the outcome ('start a facilitated conversation') and return value. This distinguishes it from sibling tools like chat_message or get_questions, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('pre-session') but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It is not misleading, but the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action ('Search') and scope, but does not describe whether results are partial or complete, how keywords are matched, whether pagination exists, or any side effects. As a read-only search, 'Search' implies non-mutation, but details are absent, leaving significant behavioral ambiguity.
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?
The description is a single, front-loaded sentence with no filler or redundant information. It conveys the action, target, and scope efficiently, earning a top score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two fully documented parameters and no output schema. However, the description does not indicate what the search returns (e.g., a list of sessions) or include any usage caveats. Given no annotations and no output schema, the completeness is adequate but has gaps around return format and behavioral expectations beyond the core search action.
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?
The schema already provides 100% coverage for both parameters (query and status), but the description adds semantic value by specifying that the query is about 'topic or goal keywords', which is more nuanced than the schema's generic 'Search keywords'. This helps the agent understand the intended use of the query parameter beyond its simple type definition.
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 'Search Harmonica sessions by topic or goal keywords', identifying a specific verb (Search), resource (sessions), and search scope (topic/goal keywords). This distinguishes it from siblings like list_sessions (likely lists all sessions) and get_session (fetches a specific session), making the purpose unmistakable.
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?
The phrase 'by topic or goal keywords' clarifies when to use this tool: when you need to find sessions based on thematic or goal-oriented keywords. It does not explicitly state when not to use it or name alternatives, but the contextual guidance is clear enough for the agent to decide between searching and listing/fetching sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the side effect of creating a new participant thread on the first message, which is valuable. However, it does not mention error conditions, whether the operation is idempotent, permission requirements, or specifics about the response format beyond the vague 'get the AI facilitator response.' This is adequate but has clear gaps.
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?
Two sentences with no redundant content. The first sentence states the primary action and outcome, and the second adds a key side effect. Information is front-loaded and very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations, yet the description provides a complete enough picture for a simple messaging tool. It explains the action, the response, and the thread-creation behavior. It could go further by describing the response structure or error handling, but given the low complexity, the description is largely sufficient.
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 description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides; it only names content, session_id, participant_id, and participant_name in passing. There is no additional syntactic or contextual detail, so the schema fully carries the parameter semantics.
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 uses a specific verb ('Send') and resource ('Harmonica session conversation') and clearly states the tool's action and outcome: sending a message and getting the AI facilitator response. The additional detail about creating a new participant thread on first message differentiates it from sibling tools like get_responses or list_sessions.
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?
The description clearly implies when to use the tool: to send a message in a session and receive the facilitator's response. It does not explicitly name alternatives or exclude other tools, but the context is clear enough for an agent to select it for message-sending tasks. No exclusions are stated, so it falls short of a 5 but meets the 'clear context' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It says the tool returns the project and linked session IDs, which is useful. However, it does not disclose error behavior (e.g., if the project ID is invalid), permission requirements, or any side effects (though 'get' implies none). This is moderately transparent; a 3 fits.
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?
The description is one sentence, concise, and front-loaded with the action and resource. Every phrase adds value; no filler. Scores 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, no output schema). The description explains both the input (project by id) and the output (project with linked session IDs), which is sufficient for correct use. It does not mention error cases or authentication, but these are not essential for a basic getter. Therefore a 4.
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?
The schema fully documents project_id with description 'Project (workspace) ID'. The tool description simply says 'by id' and does not add parameter details beyond the schema. With 100% schema coverage, the baseline is 3, and the description adds no extra parameter semantics.
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 states a specific action ('Get') on a specific resource ('a single Harmonica project (workspace) by id') and adds what is included ('including the ids of the sessions linked to it'). This distinguishes it from sibling list_projects (which gets all projects) and get_session.
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?
The description clearly implies the use case: fetch one project by ID. It does not explicitly name alternative tools or when-not-to-use, but the contrast with list_projects is evident from 'single' and 'by id'. It provides clear context but no explicit exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It discloses that it only returns 'title + id' and that it is scoped to projects the user has access to. However, it does not describe anything about pagination defaults, ordering, or whether archived projects are included. For a read-only list tool this is adequate but lacks richer behavioral detail.
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?
The description is concise: two sentences that front-load the action ('List...') and then add a brief explanation of what a project is and the return fields. Every sentence contributes useful information without redundancy or bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 optional params, no output schema), the description is nearly complete: it states the resource, the scope ('you have access to'), and the return shape ('title + id'). It could have explicitly mentioned the available pagination params, but since the schema already documents them, the description is sufficient for a list endpoint. A perfect score is held back because it does not mention any potential errors or limits.
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?
The input schema already provides 100% coverage for both parameters (limit and offset) with clear descriptions. The tool description does not add any meaning beyond the schema—it simply mentions 'title + id' for the return, which is not parameter-related. Baseline of 3 is appropriate per the rubric.
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 starts with a specific verb-resource pair: 'List the Harmonica projects (workspaces) you have access to.' It clearly distinguishes from siblings like list_sessions by focusing on projects/workspaces, and adds context that projects group sessions and can be published as a sensemaking topic. This makes the tool's purpose unambiguous.
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?
The statement 'you have access to' sets a clear context for when to use the tool (i.e., to retrieve the user's accessible projects). It implies the tool is for listing, not for retrieving detailed session data, but it does not explicitly mention alternatives or when-not-to-use it. This is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds 'Requires editor role' and 'Mirrors the v1 PATCH surface,' implying partial-update semantics. However, it doesn't mention return values, idempotency, or global side effects. Rated 3 because it provides some context but not full transparency.
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?
One concise sentence front-loads the core purpose ('Update session metadata') and adds only essential extra context (API surface, role requirement). No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 20 parameters with rich per-parameter descriptions in the schema, including behavioral caveats like wholesale replacement of questions and template/prompt out-of-sync risks. The main description adds the API surface and role requirement. Missing return-value info, but the schema covers most contextual needs. Given the absence of an output schema, a brief mention of the response would make it fully complete.
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 description coverage is 100%, so baseline is 3. The description adds no parameter-specific detail beyond the ALLOWED_UPDATE_FIELDS reference, but the schema itself documents every parameter thoroughly. No need for more from the description.
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 'Update session metadata' is a specific verb+resource, clearly distinguishing it from siblings like create_session, get_session, and list_sessions. The API endpoint reference reinforces the exact operation.
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?
Clear context: use to update existing session metadata. States prerequisite 'Requires editor role.' Does not explicitly exclude alternatives, but the purpose is unambiguous relative to sibling tools. Lacks when-not-to-use guidance, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the non-destructive nature of dry_run, the paid-account requirement, and the Free tier step cap. It does not explicitly state what the tool returns on success or how it handles conflicts beyond parameter hints, but it provides meaningful context beyond minimal descriptions.
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?
The description is four sentences long, with the purpose front-loaded in the first sentence. Every sentence provides useful information (e.g., method_md input, dry_run preview, account constraints) with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no output schema, so the description should ideally explain return values or fallback behavior. It provides useful operational context (dry_run, account limits) but does not mention what is returned on success/failure or what happens when an existing template is overwritten. This is an adequate but incomplete contextual picture.
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 description coverage is 100%, so the baseline is 3. The description repeats some param details (method_md content, dry_run behavior) that are already present in the schema without adding new meaning. It does not explain parameters in a way that materially enhances the schema's clarity.
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 uses a specific verb ('Install') and clearly identifies the resource ('OFL method spec') and the resulting artifact ('runnable Harmonica chain template'). It is easily distinguished from the session/project-oriented sibling tools, which are unrelated in purpose.
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?
The description provides clear context for when to use the tool (installing a method spec) and includes important operational guidance: using dry_run to preview without writing, and noting the paid-account requirement with a free tier cap of 3 steps. It does not explicitly name alternatives or exclusion scenarios, but no obvious alternative exists among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses the editor role requirement and the custom summary_prompt behavior, and the word 'regenerate' implies overwriting. It does not explicitly state that the existing summary is replaced, but that is implied by the term.
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?
The description is concise and front-loaded: three short clauses convey the action, the prompt dependency, and the permission requirement. There is no unnecessary wording or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the core action, the permission requirement, and the behavioral nuance of custom prompt usage. It doesn't specify the return value or explicitly mention overwriting, but these are not critical for successful invocation.
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?
The input schema already fully documents session_id with 100% coverage, so the description adds no additional parameter semantics. This meets the baseline of 3 for high schema coverage; no extra details are needed.
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 with a specific verb ('Generate or regenerate') and a specific resource ('AI summary for a Harmonica session'). This differentiates it from sibling tools like get_summary, which reads a summary, and chat_message or other write tools.
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?
It provides context on when to use the tool (for generating or updating a summary) and mentions the editor role requirement. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' clearly indicates a read-only operation, and 'pre-session questions (data collection form)' tells the user what to expect. However, it doesn't mention potential errors or auth requirements, but for a simple getter this is sufficient.
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?
The description is a single, clear sentence with no redundancy. It is front-loaded with the action and resource, and every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema), the description explains what is returned (pre-session questions) and for which context (Harmonica session). It doesn't detail the exact structure of the return value, but that is not necessary for such a simple getter.
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?
The schema already provides 100% coverage for the single parameter session_id with a clear description '(UUID)'. The tool description does not add any additional meaning beyond the schema, so a baseline score of 3 is appropriate.
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 'Get pre-session questions (data collection form)' with a specific verb and resource, and clarifies the domain context 'for a Harmonica session'. It distinguishes from sibling tools like get_responses and submit_questions by specifying 'pre-session questions'.
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?
The phrase 'for a Harmonica session' provides clear context for when to use this tool, but no explicit alternatives or exclusions are mentioned. Since there are sibling tools like get_responses and submit_questions, a brief 'when not to use' would be helpful but isn't strictly necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the editor access requirement and the 'at least one' precondition. However, it does not describe the return value, side effects, or behavior on missing/invalid parameters beyond the schema, leaving some behavioral expectations unstated.
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?
The description is a single sentence that is front-loaded with the primary action and resource, followed by essential constraints. Every phrase adds value: the operation, the alias, the access requirement, and the parameter precondition. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter update tool with no output schema, the description plus schema covers the essential usage. It includes permission and parameter preconditions. It lacks any mention of return values or error behavior, but this is acceptable for a straightforward update operation given the schema's thorough parameter documentation.
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 the baseline is 3. The description adds meaningful semantic context by framing title as 'rename' and description as 'update', and by highlighting the 'at least one' constraint that is not apparent from the schema's optional fields. This goes beyond the schema's basic descriptions.
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 purpose: 'Rename a Harmonica project (workspace) or update its description.' It uses specific verbs and resources, and distinguishes itself from sibling tools like create_project, delete_project, and get_project by focusing on updating an existing project's title/description.
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?
Provides clear context on when to use: renaming or updating a project's description. Also mentions a prerequisite ('Requires editor access') and a usage condition ('Pass at least one of title / description'). It does not explicitly name alternative tools for exclusion, but the resource specificity makes the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. The verb 'List' implies a read-only operation, but it doesn't explicitly state side-effect-free or disclose auth/rate limits. It adds scope context but lacks deeper behavioral detail.
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?
A single, direct sentence that front-loads the verb and resource. No wasted words.
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 simple, no-parameter, no-output-schema list operation, the description fully communicates purpose and scope, making it easy for an agent to select and invoke.
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?
The tool has zero parameters, so the baseline of 4 applies. The description correctly avoids listing parameters that don't exist.
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 uses the specific verb 'List' and resource 'Telegram groups', adding scope with 'registered to your Harmonica account for session distribution.' It clearly distinguishes from sibling tools like list_sessions or list_projects.
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?
Provides clear context for when to use (listing Telegram groups for session distribution) and no alternative tool exists for this purpose. It doesn't explicitly state exclusions, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the outcome (live /t/[slug] page built from project sessions), the precondition (editor access), and an important behavioral caveat (listing on /explore is separate). It does not describe edge cases like idempotency or error behavior, but for a publish action the key behaviors are covered.
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?
Three sentences, each earning its place: the purpose, the publication trigger, and a key permission/caveat. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a publish action with 10 parameters, the description covers the main behavior, preconditions, and a caveat. The schema documents parameter details, so the description focuses on process. It lacks mention of what happens if the slug already exists or whether unpublish is the inverse, but these are minor gaps.
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. The description adds meaning beyond the schema by explaining that slug can be provided in this call or already saved on the project, and it links enabled:true as the publication trigger. This clarifies the relationship between two key parameters.
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 opens with a specific verb+resource+outcome: 'Author and publish a Harmonica project as a public sensemaking topic.' It clearly distinguishes this from sibling tools by specifying the two artifacts created (/explore hub entry and /t/[slug] opinion-landscape page).
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?
The description provides clear usage context: to publish, pass enabled:true with a slug; requires editor access. It also notes that /explore listing is a separate admin-curated step, managing expectations. It does not explicitly name alternative tools for similar actions, but the unique publish action makes the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses ownership ('you own'), the return value (project ID), and intended usage of that value. It does not detail error scenarios or side effects, but the core behavior is well conveyed.
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?
The description is two sentences, front-loaded with the primary purpose, and every clause adds value. It avoids repetition and directly addresses usage.
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 simple create operation, the description covers the essential context: creation, ownership, return value, and relationships to other tools. It also provides reuse guidance, making it complete despite the lack of an output schema.
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% for both parameters, so the description does not need to explain them. The description adds no parameter-specific semantics beyond the schema's own descriptions, making the baseline 3 appropriate.
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 action: 'Create a Harmonica project (workspace) you own.' It distinguishes from sibling tools by specifying 'you own' and explaining the project's role in publishing and session scoping.
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 guidance is provided: 'Reuse an existing project by passing its ID to those tools instead of creating a new one.' It also explains when to use the returned project ID for publish_sensemaking_topic or scoping sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly discloses the operation's behavior: the project is archived with status=deleted, sessions are left intact and ungrouped, and it requires owner access. It also explicitly states 'This never deletes any sessions,' which is important safety information.
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?
The description is two sentences long, front-loaded with the core action, and every clause adds value (soft-delete behavior, session impact, access requirement). No redundant information or filler.
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 simple tool with one parameter and no output schema, the description is complete. It covers the action, side effects, permissions, and explicit exclusions (never deletes sessions). It provides sufficient context for an AI agent to select and invoke the tool correctly.
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?
The input schema has 100% coverage for the single parameter, describing it as 'Project (workspace) ID'. The description repeats the workspace context but adds no additional semantic detail beyond what the schema already provides. Baseline 3 applies because the schema does the heavy lifting.
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 a specific action: 'Soft-delete a Harmonica project (workspace)' and distinguishes it from hard deletion by explaining it archives the project and leaves sessions intact. This differentiates it from sibling tools like update_project and get_project.
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?
The description provides clear context on when to use the tool: it is a soft-delete that never deletes sessions and requires owner access. However, it does not explicitly name alternatives or state when not to use this tool, though the soft-delete nature implies the exclusion of permanent deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the access scope, implies a read-only list operation, and describes the return fields. It omits rate limits or pagination, but for a simple list tool this is adequate transparency.
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?
The description is three sentences: purpose/scope, usage workflow, and return format. It is front-loaded with the primary action, and every sentence earns its place without waste.
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?
Given zero parameters and no output schema, the description fully covers what the tool does, what it returns, and how to use it. It is complete for an agent to select and invoke correctly, even without annotations.
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?
The tool has zero parameters, so schema coverage is vacuously 100% and the baseline is 4. The description adds downstream context by explaining how the returned id is used in create_session, enriching the meaning of the output beyond the schema.
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 lists Harmonica session templates with scope (public global templates + templates you own/access). It distinguishes from siblings like list_sessions by focusing on templates and explicitly mentions return fields, making its purpose unambiguous.
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?
The description explicitly says to use this tool to discover facilitation patterns and then pass the returned id to create_session. It gives a clear workflow but does not name alternative tools or provide exclusion criteria, though the guidance is strong enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it returns metadata but not full conversations, and the verb 'List' implies a read-only operation. While it doesn't explicitly mention side effects or safety, the non-mutating nature is strongly implied and the exclusion of conversations is clearly stated.
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?
The description is two sentences, front-loaded with the purpose, followed by actionable guidance. Every sentence contributes value, no fluff or redundant phrasing. It is concise and well-structured.
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?
With no output schema, the description explains what is returned: metadata with name, message count, and timestamps. It also sets expectations by explicitly stating what is not included (full conversations). Considering the moderate complexity of a filtered list tool, this is sufficient for an agent to understand the tool's behavior.
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. The description adds context beyond the schema by mentioning 'metadata (name, message count, timestamps)', which semantically aligns with parameters like session_id, min_messages, and since. It also describes the intended use of filters ('find participants') but does not duplicate each parameter's description.
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: 'List participants in a Harmonica session with metadata (name, message count, timestamps) but WITHOUT full conversations.' This specific verb+resource combination distinguishes it from sibling tools like get_responses, which retrieves full conversations. The explicit exclusion of full conversations further clarifies its scope.
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 usage guidance: 'Use this first to find participants, then get_responses with filters for specific ones.' This tells the agent when to use the tool and directs it to a specific alternative for a follow-up action, making the workflow clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![harmonica-mcp MCP server](https://glama.ai/mcp/servers/harmonicabot/harmonica-mcp/badges/card.svg)](https://glama.ai/mcp/servers/harmonicabot/harmonica-mcp)

Score Badge

Copy to your README.md:

[![harmonica-mcp MCP server](https://glama.ai/mcp/servers/harmonicabot/harmonica-mcp/badges/score.svg)](https://glama.ai/mcp/servers/harmonicabot/harmonica-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/harmonicabot/harmonica-mcp'

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