superpos-mcp

Official

by Superpos-AI

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose, with specific names like superpos_create_task vs superpos_create_issue, and descriptions that leave no ambiguity. Even related tools like poll_tasks and poll_events are easily differentiated by their target.
Naming Consistency5/5
All 42 tools follow the consistent pattern superpos_verb_noun in snake_case, with verbs like get, create, update, delete, list, poll, etc. This makes the API predictable and easy to navigate.
Tool Count4/5
At 42 tools, the count is high but appropriate for the broad scope of the server, which covers agent identity, task management, knowledge, schedules, issues, tracks, and hive exploration. A few tools could potentially be merged, but overall the granularity is justified.
Completeness5/5
The tool surface covers the full lifecycle of tasks, issues, tracks, schedules, and knowledge, plus extras like agent status, events, and hive mapping. No obvious gaps are apparent for the stated purpose of a multi-agent collaboration platform.
Average 3.5/5 across 42 of 42 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 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?
With no annotations, the description should explain behavioral traits. It lacks details on side effects (e.g., what if dependency already exists? Does it validate sub-issues?), error conditions, or idempotency.
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?
Two sentences with no extra fluff. Could be more structured (e.g., separate parameter descriptions) but is efficient.
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 4 parameters, no annotations, and an output schema, the description is insufficient. It misses key parameter semantics and usage context, making it hard for the agent to use correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It only explains 'kind' (enum values). It does not describe 'issue_id', 'depends_on_issue_id', or 'hive_id', leaving the agent uncertain about their meaning.
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 declares an issue dependency, specifies the 'kind' parameter, and mentions the return value. It distinguishes itself from siblings like 'superpos_remove_issue_dependency' by focusing on adding a dependency.
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 on when to use this tool versus others (e.g., when to use 'blocks' vs 'related'). No mention of prerequisites or when not to use it.
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 provided, so the description must disclose behavioral traits. It only mentions creation, with no details on side effects, permissions, idempotency, or response behavior.
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?
Two concise sentences, efficiently conveying key parameter info. Could be slightly improved with bullet structure for readability.
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?
Given no annotations, incomplete parameter coverage, and no mention of return value (despite output schema existing), the description lacks completeness for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage. The description explains only 'slug' format and 'spec' as optional markdown, leaving 'name', 'state', 'hive_id', and 'description' unexplained.
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 verb 'Create' and resource 'track', distinguishing from siblings like update or transition. However, it does not specify what a track represents in this system.
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 on when to use this tool versus alternatives (e.g., update_track, transition_track). No prerequisites or context for creation are mentioned.
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 must disclose behavioral traits. It only mentions marking complete and attaching a result, but omits critical details like state validation, authorization requirements, or side effects of hive_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is good for front-loading. However, it is too brief and omits essential details, making it insufficiently informative.
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?
Despite an output schema existing, the description does not cover prerequisites (e.g., task must be claimed), optional parameter meanings, or return value hints. The tool is state-changing but lacks necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add meaning for parameters. It only explains the 'result' parameter implicitly; task_id (required), hive_id, and status_message are left unexplained.
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 (mark as completed), the resource (claimed task), and the ability to attach a JSON result. It distinguishes from siblings like fail_task and claim_task.
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 on when to use this tool versus alternatives such as fail_task or get_task. The description does not specify prerequisites or context for invocation.
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?
With no annotations, the description must fully disclose behavioral traits. It only states listing tracks and their states, but omits important aspects like whether results are paginated, sorted, or filtered by hive_id (which is an optional parameter). No mention of permissions, rate limits, or side effects.
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?
Two sentences with a clear focus: first sentence defines the tool and resource, second lists possible states. Front-loaded and no filler. However, it could be more informative about the parameter without becoming verbose.
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?
Given the output schema exists, return value explanation is not required. However, the description does not integrate the optional hive_id parameter into the context, nor does it help the agent understand scope (e.g., all hives vs specific). It is minimally complete for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description does not explain the 'hive_id' parameter at all, leaving its purpose and usage undocumented. This forces the agent to guess or rely on external knowledge.
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?
Description clearly states 'List tracks' with a precise definition of tracks as 'first-class containers that group related issues into a body of work (like an epic).' Lists states for further clarity. The verb 'list' and resource 'tracks' are explicit, and the tool distinguishes itself from siblings like 'get_track' by implying a collection return.
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 on when to use this tool vs alternatives like superpos_get_track, superpos_create_track, etc. The description does not specify prerequisites, contexts, or exclusions. The agent is left 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry full burden. It discloses cursor-based iteration and return of seq numbers, but fails to mention rate limits, idempotency, authentication requirements, or behavior when cursor is null or hive_id is omitted.
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, front-loaded with purpose and followed by return value info. No redundant words, clear and efficient.
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?
Given the polling pattern and 3 optional parameters, the description lacks detail on limit, hive_id, and behavior for null cursor. Output schema exists but is not summarized, leaving the agent without full context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only explains the cursor parameter. The 'limit' parameter (default 50) is not described at all, and 'hive_id' is entirely omitted. This leaves the agent without understanding of these parameters' meaning.
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 it fetches events from the hive since a cursor, using specific verbs and resource. However, it does not differentiate from sibling tools like superpos_poll_tasks, though the resource (events vs tasks) is distinct.
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 for polling events sequentially via cursor, but lacks explicit guidance on when to use this tool versus alternatives (e.g., searching events). No when-not-to-use or examples provided.
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 burden. It mentions 'including its full value,' implying a complete return, but lacks details on idempotency, safety, authentication requirements, or side effects. The behavior is minimally disclosed.
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?
The single-sentence description is very concise and front-loaded, stating the core action immediately. However, it could add brief parameter clarification without harming conciseness, so it is slightly under-informative for the 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?
Given the presence of an output schema and 2 parameters (1 optional), the description is adequate but not thorough. It omits explanation of the optional hive_id parameter and how it affects the retrieval. For a simple get tool, it meets minimum completeness but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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. It references 'by id' but does not explicitly map to 'entry_id' or explain the optional 'hive_id' parameter. The meaning of 'full value' is vague regarding parameter scope.
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 retrieves a single knowledge entry by ID, which distinguishes it from sibling tools like search_knowledge or list_knowledge that handle multiple entries. The verb 'Get' and resource 'knowledge entry by id' are specific and unambiguous.
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 guidance on when to use this tool versus alternatives such as search_knowledge or list_knowledge. It does not mention exclusions, prerequisites, or any context for optimal usage, leaving the agent to infer without support.
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 must carry the full burden. It does not disclose behavioral traits such as whether the tool is read-only, what happens if the task_id does not exist, or any error handling. The description is minimal.
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?
The description is a single, concise sentence that efficiently conveys the core purpose. However, it sacrifices necessary detail, which prevents a higher score.
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 an output schema (indicated), but the description only lists the fields without explaining the output structure or behavior (e.g., error handling). For a simple getter, it is somewhat adequate but lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameter descriptions in schema. The description does not explain the purpose or usage of the parameters (task_id and optional hive_id). It fails to compensate for the lack of schema documentation.
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 (Get) and the resource (single task), and explicitly lists the returned fields (status, payload, result, error). It distinguishes itself from sibling tools like superpos_poll_tasks (which retrieves multiple tasks) and superpos_create_task (creation).
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 the tool is for fetching a specific task, but it does not provide explicit when-to-use or when-not-to-use guidance. It could be improved by noting that for multiple tasks, superpos_poll_tasks should be used.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action but does not describe side effects, permissions required, or whether transitions are reversible. The output schema exists but its content is unknown, so the description is insufficient.
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 with no redundant words. It effectively communicates the core action without unnecessary detail.
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?
Despite the presence of an output schema, the description lacks context on what the tool returns, error handling, or transition constraints. For a mutation tool with no annotations, this is inadequate for an agent to confidently use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only indirectly explains the 'to' parameter by listing states, but does not explain 'slug', 'reason', or 'hive_id'. This leaves ambiguity about parameter purpose and expected values.
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 moves a track to a new state and explicitly lists the allowed states: planning, active, paused, done, or archived. This provides a specific verb+resource and distinguishes it from sibling tools like superpos_transition_issue.
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 on when to use this tool instead of alternatives like update_track or create_track. It lacks information on prerequisites, valid transitions, or conditions for use.
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 provided. Description does not disclose behavioral traits such as required permissions, side effects, or success/failure behavior. Minimal disclosure for a create operation.
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?
Extremely concise: two sentences front-loading the purpose, then clarifying key parameters. No extraneous 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?
Has output schema, so return values not needed. But missing details on optional parameters and default behavior (e.g., issue_type defaults to 'task' not mentioned). Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description explains only issue_type and assignee parameters (2 out of 7), leaving title, description, hive_id, and metadata unexplained. Partially compensates but insufficient.
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?
Clearly states 'Create an issue' with specific details about issue_type and assignment parameters. Distinct from sibling tools like superpos_create_task which creates tasks.
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 on when to use this tool versus alternatives like superpos_create_task or superpos_list_issues. Lacks context for optimal selection.
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 must disclose behavioral traits. It only states the action (linking) and outcome (issue appears in track), but omits details like idempotency, permissions, or whether linking replaces existing links. For a mutation tool, this is minimal.
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 17-word sentence that directly states the tool's purpose and effect. It is front-loaded and contains no extraneous words 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?
Given the tool's moderate complexity (3 params, output schema exists) and lack of annotations, the description covers the basic function but misses contextual details like constraints (e.g., track must exist) or reversibility (sibling unlink_issue exists). Adequate for simple linking but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters have no descriptions. The description adds no parameter-level information beyond their names (e.g., track_slug, issue_id, hive_id). The agent gains no additional semantic meaning 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 clearly states the action: 'Link an existing issue to a track' and the effect: 'shows up in the track's body of work.' It distinguishes from siblings like superpos_unlink_issue (reverse) and superpos_link_task_to_issue (links task to issue), making the tool's specific role clear.
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 (to associate an issue with a track) and sibling tools (unlink_issue, link_task_to_issue) provide contrast, but no explicit when-to-use or when-not-to-use guidance is given. The agent can infer context but lacks explicit directives.
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 provided, so the description must disclose behavioral traits. It only states the action without mentioning safety (e.g., read-only), side effects, pagination, or limits. The agent cannot infer whether this operation is destructive or has other impacts.
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, well-structured sentence with no redundancy. Every word adds value, making it concise and easy to parse.
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?
Given a simple tool with one optional parameter and an output schema (not shown), the description is minimally adequate but omits details like parameter explanation and usage context. It does not fully exploit the available schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention or explain the lone parameter 'hive_id'. The agent receives no additional meaning beyond the schema's name and type, which is insufficient for correct invocation.
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 'List', the resource 'schedules', and specifies scope ('recurring/one-time', 'in the hive', 'create tasks automatically'). It effectively distinguishes from siblings like superpos_create_schedule and superpos_delete_schedule.
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 tells what the tool does but provides no guidance on when to use it versus other listing tools (e.g., superpos_list_hives, superpos_list_knowledge). There are no explicit conditions, exclusions, or context for selection.
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 exist, so the description must disclose behavioral traits. It only states the action ('drop') and how to find the id, but does not describe side effects, reversibility, error handling, or required permissions for this mutation.
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?
The description is a single, focused sentence with no extraneous words. However, it lacks structured sections like requirements or examples, and could benefit from bullet points for parameter usage.
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?
Given the tool has 3 parameters, no schema descriptions, no annotations, but has an output schema, the description does not cover important aspects such as success response, error conditions, or the effect on associated data. It provides only minimal information to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter individually. Dependency_id is referenced indirectly, but hive_id and issue_id are not explained. The description adds no parameter meaning beyond the schema's property names.
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 verb 'Drop' to clearly indicate removal, specifies the resource ('dependency row'), and explains how to identify it by its id from the dependencies array. This distinguishes it from the sibling tool add_issue_dependency.
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 tells the agent to look for the dependency id in the dependencies array from superpos_get_issue, providing a clear source for the required parameter. It implicitly defines the use case of removing an existing dependency, but does not explicitly state when to use vs alternatives or prerequisites.
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 provided; description carries full burden. Discloses that issue is not deleted, but lacks info on permissions, side effects, state constraints, or any validation. Insufficient for a mutation tool.
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?
Single sentence, 10 words, no redundancy. Front-loaded with key info. Highly concise.
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?
Output schema exists but description is minimal. Adequate for a simple unlinking operation, but lacks context on return value, side effects, or prerequisites for a tool with sibling complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description does not explain any parameter. 'track_slug', 'issue_id', and optional 'hive_id' are not elaborated. Description adds no meaning beyond 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?
Description uses specific verb 'Remove' and resource 'issue from a track'. Clarifies that issue is not deleted, which distinguishes from delete operations. Clear purpose with sibling differentiation from 'superpos_link_issue'.
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?
Implied usage: use when you want to unlink an issue from a track. No explicit guidance on when not to use or alternatives. Lacks when/when-not clarity.
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 burden. It correctly identifies the operation as listing (read-only), but fails to mention pagination behavior, ordering, or what happens when no filter is applied. The limit parameter hints at pagination but is not explained.
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?
The description is a single sentence, front-loaded with the verb, and contains no filler. However, it may be too brief given the complexity of the tool's parameters.
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?
Given the three parameters and no annotations, the description lacks important contextual details such as pagination behavior (limit), the scope of hive_id (default hive), and the ordering of results. The output schema exists but is not referenced.
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 description adds meaning for the 'key_prefix' parameter (optional filter), but does not explain 'hive_id' (which hive, default null meaning current hive?) or 'limit' (max page size?). With 0% schema description coverage, the description should compensate more comprehensively.
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 knowledge entries in the hive and supports an optional key prefix filter. It distinguishes from siblings like 'superpos_search_knowledge' (full-text search) and 'superpos_get_knowledge' (single entry).
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 for listing with optional prefix filtering, but does not explicitly state when to use this versus alternatives like search or get, nor does it mention any exclusions or prerequisites.
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 full burden. It indicates a read-only search operation but does not disclose potential side effects, authentication needs, or rate limits. The mention of modes gives some insight into behavior, but details like pagination, result structure, or handling of missing results are absent. The presence of an output schema partially mitigates this.
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 extremely concise, consisting of two short sentences. The first sentence states the action and lists modes, the second sentence clarifies the purpose. Every word adds value with no redundancy. It is well-structured and easy to scan.
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?
Given the tool's complexity (4 parameters, with 1 required, has output schema) and sibling context, the description covers the core functionality and purpose. However, it omits details on optional parameters like 'hive_id' (which scopes the search) and the effect of 'limit'. The description is adequate for basic use but leaves room for ambiguity in advanced scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds meaning for the 'mode' parameter by listing its possible values (hybrid, fts, semantic) and default (hybrid). However, it does not describe the 'query', 'limit', or 'hive_id' parameters, leaving the agent to rely solely on the schema's minimal type information. The description compensates partially for one parameter but neglects the other three.
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 searches the hive's shared knowledge store and lists the available modes (hybrid, fts, semantic). It specifies the purpose: to recall decisions, context, and results. While it indirectly distinguishes from sibling tools like superpos_get_knowledge and superpos_list_knowledge by emphasizing search, it does not explicitly differentiate between these use cases.
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 advises using the tool 'to recall decisions, context, and results other agents have stored,' which provides a clear use case. However, it does not mention when to avoid using this tool or suggest alternative tools (e.g., superpos_get_knowledge for retrieving a specific record, superpos_list_knowledge for listing all entries). No exclusionary guidance is given.
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 provided, so description carries full burden. It mentions version bumping but omits whether the value replacement is full or partial, whether the entry must exist, permission requirements, or idempotency. Minimal behavioral disclosure.
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?
Single sentence with immediate action verb and effect. No filler words; highly concise.
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?
Despite an output schema present, the description fails to explain the semantics of replacement or the implications of the nested 'value' object. For a mutation tool with 3 parameters, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description adds no insight into parameters beyond the schema. It does not clarify that 'value' is a full replacement object, that 'hive_id' is optional, or any constraints on 'entry_id'.
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 replaces the value of an existing knowledge entry and bumps its version. It distinguishes from create (new entry) and get/list/search (read operations) among the siblings.
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 use when updating an existing entry, but does not explicitly state when to use versus alternatives like create_knowledge or search_knowledge. No exclusion criteria or prerequisites mentioned.
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 explains trigger types but fails to disclose side effects, permission requirements, or whether the schedule starts immediately. The return value is not mentioned even though an output schema exists.
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 core purpose, and includes essential parameter guidance without unnecessary words. Every sentence is earned.
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?
Given 8 parameters and only 3 required but no output schema visible, the description is incomplete. It omits explanations for name, task_type, task_payload, and hive_id. The agent may lack context for what values to provide. No examples are given.
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 description adds value by explaining the relationship between trigger_type and the parameters cron_expression, interval_seconds, and run_at. However, it does not describe the meaning of name, task_type, task_payload, or hive_id. With 0% schema coverage, the description compensates partially but not fully.
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 creates a schedule that produces tasks automatically, and it distinguishes from sibling tools like superpos_create_task by focusing on scheduling. It also explains the three trigger types and associated parameters.
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 gives guidance on which trigger type to use and which parameters to include (e.g., 'cron' with cron_expression). However, it does not explicitly state when not to use this tool versus alternatives like superpos_create_task, nor does it provide exclusion criteria or prerequisites.
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 burden. It discloses that the action is subject to a closure policy, but omits details on side effects (e.g., notifications, state changes), permissions, or whether the action is reversible.
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 action, and no redundant information. Every sentence is necessary.
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?
Given the absence of annotations and partial parameter coverage, the description is minimally adequate. It mentions the closure policy but does not explain what that entails, and the output schema is present but unaddressed.
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?
With 0% schema description coverage, the description adds value for the 'reason' parameter by stating it is optional, but it does not mention the 'hive_id' parameter or clarify its purpose, leaving gaps.
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 ('Close') and resource ('issue'), and clarifies the state ('as done') with optional reason recording, clearly distinguishing from sibling tools like superpos_transition_issue.
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 for final closure of an issue, but does not explicitly state when to use this vs. alternative tools like superpos_transition_issue for other transitions, nor does it provide exclusions or prerequisites.
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?
With no annotations, the description must disclose behavioral traits. It mentions that deletion stops task creation but omits critical details: what happens to existing tasks created by the schedule, whether the action is reversible, or if special permissions are required. This is a significant gap for a mutation tool.
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, 11-word sentence that immediately conveys the purpose. It is concise and front-loaded with no unnecessary information.
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?
While an output schema exists (unseen), the description lacks essential details about the effect on existing tasks and the overall behavior of the tool. For a delete operation, this omission limits the agent's ability to fully understand consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no additional meaning for the two parameters ('hive_id' and 'schedule_id'). The agent must rely solely on parameter names, leaving 'hive_id' ambiguous.
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 ('Delete a schedule') and the primary reason ('so it stops creating tasks'), which distinguishes it from sibling tools like list or create schedule.
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 implies the tool is for permanently stopping a schedule from generating tasks. It provides clear context for use but does not explicitly exclude cases like temporary disablement or mention potential prerequisites (e.g., schedule existence).
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 full burden for behavioral disclosure. It explains that the tool writes to memory and specifies the three modes (append, prepend, replace), but does not disclose side effects, authorization requirements, or data persistence guarantees. The description adds some value but lacks depth.
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?
The description is concise, with only one sentence and a short list of modes. It is front-loaded and wastes no words. However, it could be slightly more structured (e.g., separate sentences for action and parameters) to improve readability.
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 simplicity, the description covers the core purpose and parameter semantics. An output schema exists, so return values need not be detailed. However, it omits potential constraints like content length limits or whether multiple writes accumulate. Overall, it is complete enough for basic 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 description coverage is 0%, so the description must compensate. It explains the 'mode' parameter's possible values and default, but does not add semantics beyond 'content' as the content to write. For a two-parameter tool, the description partially compensates but leaves content's format or constraints unspecified.
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 writes to the agent's persistent MEMORY document, using a specific verb ('Write') and resource ('this agent's persistent MEMORY document'). The name and description effectively distinguish it from sibling tools like superpos_update_knowledge, which target a different data store.
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 guidance on when to use this tool versus alternatives like superpos_update_knowledge. It only explains the mode parameter without any context for when to choose append, prepend, or replace, or when to use this tool over other memory-related tools (which are absent).
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?
With no annotations, the description must convey behavioral traits. It explains parameter formats (key, value, scope, ttl) but does not disclose what happens on key conflicts (overwrite vs. error), required permissions, or side effects. This lack of conflict behavior and error conditions limits transparency.
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?
The description is concise (two sentences) and front-loaded with purpose. However, it could be slightly more structured (e.g., bullet points) and omits hive_id, which is an information gap. Still, it is efficient and minimally verbose.
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?
Given 5 parameters and the presence of nested objects and output schema, the description covers key, value, scope, and ttl, but omits hive_id. It doesn't address default behaviors or edge cases like TTL expiration. While much is covered, the missing parameter and behavioral context reduce completeness.
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. It describes key (dotted name), value (JSON), scope (hive/organization/agent), and ttl (duration/ISO8601), covering 4 of 5 parameters. Only hive_id is omitted. This adds significant meaning beyond the bare 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 'Store a knowledge entry shared with other agents,' which is a specific verb-resource pair. It further differentiates itself by explaining the key format (dotted, domain-scoped) and scope options, distinguishing it from sibling tools like search, list, or update.
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 provides context on when to use the tool (for creating knowledge entries), but it does not explicitly guide the agent on when to use alternatives like superpos_update_knowledge or superpos_search_knowledge. No exclusions or alternative recommendations are given.
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 full burden. It indicates a read operation and lists returned fields, but lacks details on error handling, authentication requirements, or behavior in edge cases. For a simple get tool, this is minimally adequate.
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 and efficient. It clearly states the action and lists key outputs without 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 description lists the returned data, and an output schema exists to define the return structure. However, it lacks parameter documentation and usage context. For a simple tool, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters (hive_id, issue_id). It mentions 'single issue' but does not clarify which parameter identifies it or the role of hive_id. This leaves the agent with insufficient guidance on parameter usage.
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 'Get a single issue' and enumerates the returned data (type, linked tasks, dependencies, approvals, allowed_transitions). This specific verb and resource distinguishes it from sibling tools like superpos_list_issues.
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 when a single issue's details are needed, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., list_issues for multiple issues) or when not to use it.
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?
With no annotations, description should disclose more behavioral traits. Only states it fetches pre-assembled persona, implying read-only but doesn't explicitly state lack of side effects, rate limits, or permissions needed.
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?
Single sentence, no fluff. Front-loaded with action and resource description. Efficiently communicates purpose and 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?
Since output schema exists, description doesn't need to detail return format. Provides enough context about what the persona contains. Slight lack of detail on how the assembled persona is structured, but acceptable.
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?
No parameters so baseline is 4. Description adds value by enumerating the components of the persona (SOUL, RULES, STYLE, MEMORY), giving context beyond the empty 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?
Clearly states verb 'Fetch' and specific resource 'persona/system prompt', with details on contents (SOUL, RULES, STYLE, MEMORY). Distinct from siblings like superpos_get_knowledge which fetches individual knowledge items.
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 on when to use this tool versus alternatives. Does not mention when not to use it or compare with sibling tools like superpos_whoami.
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 provided, so description carries full burden. It mentions 'point-in-time map' and 'timeframe bounds activity-derived edges', implying it is read-only. However, it does not explicitly state non-destructive behavior, required permissions, or how null hive_id is handled.
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 extremely concise: two sentences with no wasted words. It front-loads the core purpose ('point-in-time map of the hive graph for drill-down') and then adds the key detail about timeframe.
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?
Covers main concept (nodes and edges with timeframe filtering) but lacks specifics on output structure (though output schema exists) and behavior for null hive_id. Adequate for a map tool but leaves some questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains timeframe with examples ('1h', '24h', '7d'), but does not explain hive_id (anyOf string/null, default null) – leaving ambiguity about what null means. Only one of two parameters gets meaningful context.
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 it provides a 'point-in-time map of the hive graph' for drill-down, listing specific node types (agents, services, inboxes, schedules) and edge types (task flow, proxy access, triggers, cross-hive links). This distinguishes it from siblings like superpos_hive_agents (lists agents only) and superpos_list_hives (lists hives).
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 use for drill-down into the hive graph, but does not explicitly state when to use versus alternatives (e.g., superpos_hive_agents for a flat list of agents). No exclusion criteria or prerequisites are mentioned.
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 must carry the full burden. It only states the basic linking action without disclosing side effects, permissions, idempotency, or consequences of linking.
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, well-formed sentence with a front-loaded action and a relevant example, containing no unnecessary 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 has three parameters and an output schema, but the description omits parameter details and behavioral context. It is minimally adequate for a simple linking tool but leaves gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain the parameters (hive_id, task_id, issue_id) beyond their names, failing to add meaningful context.
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 ('Attach an existing task to an issue') and provides a concrete use case example involving a sibling tool, distinguishing it from similar siblings like link_issue.
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 gives a specific scenario ('when you spawn a subtask to resolve the issue') that implies when to use this tool, but does not explicitly state when not to use it or list alternatives.
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 available, so the description carries the transparency burden. It lists the output fields, implying a read-only operation, but does not explicitly state that the operation is safe, idempotent, or free of side effects. More detail on behavior (e.g., caching, rate limits) would improve 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?
Two sentences, no filler. The first sentence defines the action and output, the second gives workflow context. Every word adds value, and the most critical information appears first.
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 covers the return fields and usage context, but the parameter hive_id is left unexplained. Given that an output schema exists, the return structure is likely documented. However, a user must infer how to use the optional parameter, which is a notable gap for a tool with a single parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter (hive_id) with 0% description coverage, yet the description does not explain its purpose or effect. The agent is left to guess whether hive_id filters by hive or is required for multi-hive setups. Complete omission of parameter meaning is a major gap.
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 explicitly states the tool lists the 'issue-type catalogue' with specific fields (id, key, label, closure_policy). It clearly distinguishes from sibling tools like superpos_list_issues (lists issues) and superpos_create_issue (creates issues) by framing it as a discovery step before issue creation.
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 explicit guidance: 'Use this to discover valid issue_type keys before superpos_create_issue.' This tells when to use the tool and its role in the workflow. It lacks exclusion statements about when not to use it, but the provided context is sufficient.
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?
Discloses it creates tasks for other agents and routing options, but no mention of side effects, permissions, or other behavioral traits. No annotations so description carries burden.
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?
Two sentences, front-loaded with main action, then specific guidance. Efficient but could include brief parameter hints without being verbose.
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?
Moderately complex tool with 9 params and no annotations; description covers main use but lacks detail on many parameters. Output schema exists but is separate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only clarifies instructions and payload parameters; other 7 parameters (hive_id, priority, etc.) are unexplained. Schema coverage is 0%, so description should compensate more.
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?
Clearly states 'Create a task in the hive for another agent to pick up', specifying the verb (create), resource (task in hive), and distinguishes from siblings like get_task or complete_task.
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 guidance on using instructions vs payload, and routing with target_capability or target_agent_id. Lacks explicit when-not-to-use or alternatives, but is adequate.
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 discloses that issues are included 'by default', hinting at the 'include_issues' parameter default. However, it does not mention any side effects, authentication requirements, or rate limits. The information 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 a single sentence that front-loads the main action and key included data. Every word is necessary; 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?
Given the tool has an output schema (so return values are documented there), the description provides a useful summary. For a simple retrieval tool, it is mostly complete, though it could mention that the result is a single track object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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. It indirectly explains 'slug' (identifies the track) and 'include_issues' (included by default), but does not mention 'hive_id' at all. Two of three parameters get partial explanation, leaving a gap.
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 ('Get'), the resource ('track by slug'), and what is included ('full spec document and...issues linked to it'). It distinguishes from siblings like 'list_tracks' (which lists all tracks) and 'get_issue' (which gets a single issue).
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 when a specific track slug is known and one wants the full spec and issues. However, it does not provide explicit guidance on when not to use it or mention alternatives such as 'list_tracks' for browsing or 'get_issue' for issue details.
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 full burden. It discloses that the tool lists agents with status and capabilities, implying a read-only operation. However, it does not explain what happens when hive_id is null (default) or specify any behavioral traits like pagination or rate limits.
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?
The description is a single sentence with a dash, front-loading the action. It is concise and to the point, though the second clause adds useful context. No unnecessary 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?
For a simple list tool with one optional parameter and an output schema, the description provides the core purpose and usage hint. However, it lacks explanation of the parameter's behavior when omitted, which is a gap for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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. The description mentions 'in the hive' but does not explicitly link 'hive_id' to filtering by hive, nor does it explain what a 'sibling' agent is. The purpose of the parameter is only partially inferable.
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 specifies the exact verb 'List', the resource 'sibling agents', and the returned information 'status and capabilities'. It also distinguishes itself from siblings like superpos_list_hives and superpos_list_issues by focusing on agents.
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 states the tool is 'useful before routing a task with target_capability or target_agent_id', providing a clear when-to-use scenario. It does not explicitly mention when not to use it or alternative tools, but the context is sufficient for an AI agent.
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 full burden. It discloses ordering behavior (newest-updated first) and basic filtering, but lacks details on pagination, permissions, rate limits, or response format. Adequate but not comprehensive for a read operation.
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?
Very concise at three sentences, front-loaded with purpose. Each sentence adds value without redundancy. Could be slightly more structured but efficient.
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?
Given 6 parameters, no annotations, and an output schema (existing but not described), the description covers basic purpose and two parameter meanings but lacks details on all parameters, pagination, and expected output. Leaves significant gaps for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must add meaning. It explains state (lists values) and query (title substring), but ignores hive_id, per_page, assignee_id, and issue_type_id. Per_page has a default but no pagination behavior is described. Incomplete parameter coverage.
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 issues in the hive's planning surface, ordered newest-updated first. It distinguishes from sibling tools like superpos_get_issue (single issue) by implying a list 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?
The description provides usage context by listing possible state values and explaining the query parameter filters by title substring. It does not explicitly mention when not to use or alternative tools, but the context is clear enough for an agent.
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 present, so the description must convey behavior. It states 'only the ones provided', indicating partial updates. However, it does not disclose potential side effects, permissions, or constraints beyond that.
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 extremely concise: a single sentence plus a referral to another tool. It is front-loaded with the main purpose, with no wasted words.
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?
Given the complexity (8 parameters, output schema present), the description is too scant. It fails to explain parameter usage, validation, or what the output contains, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 8 parameters. It only generically says 'fields', offering no clarification on what each parameter does or any relationships.
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 explicitly states the action ('Update an issue's fields') and the resource ('issue's fields'). It also distinguishes from the sibling tool 'superpos_transition_issue' by noting that state changes should use that tool, clarifying 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 clear guidance: it tells the agent to use 'superpos_transition_issue' for state changes, implying this tool is for field updates. This directs the agent away from misuse.
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 adds some behavioral context (server may retry). However, it doesn't disclose prerequisites (task must be claimed) or other side effects.
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, no redundant words, action-oriented and front-loaded.
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?
Output schema exists, so return values are covered. However, missing prerequisites (task must be claimed), valid error code values, and effect of hive_id make it less complete for a state-modifying tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any parameter individually. It only mentions error code and message in general, not specific meaning, defaults, or relationships.
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 (mark as failed), the object (claimed task), and the means (error code and message). It distinguishes from sibling tools like superpos_complete_task and superpos_task_progress.
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 implies usage after claiming a task and mentions retry policy, but doesn't explicitly state when not to use (e.g., for success) or alternatives.
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 provided, so description carries full burden. It fails to disclose behavioral traits such as read-only nature, required permissions, or side effects. Only states basic functionality.
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?
Single sentence with no filler words. Extremely concise and front-loaded with key 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?
Given no parameters and existence of output schema, description is sufficient for a simple list operation. Could mention organization scope more explicitly but overall clear.
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?
Tool has zero parameters and schema description coverage is 100%, so baseline score is 4. No additional parameter info 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?
Description clearly states the verb 'list', resource 'hives (workspaces)', and qualifier 'this agent's organization has access to', distinguishing it from sibling tools like superpos_hive_map and superpos_hive_agents.
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?
Usage is implied but no explicit guidance on when to use or alternatives. The description does not mention when not to use or contrast with other list tools like superpos_list_knowledge.
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 present, so the description must disclose behavior. It explains broadcast effects (subscribers receive the event) but omits details like idempotency, persistence, or rate limits. The output schema exists but the description adds no behavioral context about return codes.
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, no redundant words. The core action and effect are front-loaded, making it efficient for an agent to parse quickly.
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?
For a simple publish tool with an output schema, the description covers the primary use case but lacks parameter details. It is minimally adequate but incomplete without explaining hive_id and payload semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only gives an example for event_type, leaving hive_id (nullable, default null) and payload (arbitrary object) unexplained. This is insufficient for an agent to properly populate arguments.
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 ('broadcast') and identifies the resource ('event to the hive'), with a concrete example ('deploy.finished'). It clearly distinguishes from sibling tools like poll_events (listening) and create_task (task operations).
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 implies usage context: when you want to notify other agents subscribed to an event type. It does not explicitly state when not to use or compare to alternatives, but the intent is 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?
Without annotations, the description discloses side effects: 'creates a pending approval and moves an in_progress issue to blocked'. It covers the main behavioral traits (approval request, state change) and preconditions, though it omits details on authorization or reversibility.
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?
The description is concise (two sentences), front-loads the main action, and avoids redundancy. However, it could be better structured to include parameter details without losing conciseness.
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 covers the core action and preconditions but lacks parameter documentation. With an output schema present, return values are covered externally, but the missing parameter semantics reduces completeness for a tool with 5 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage. The tool description does not explain any parameter's purpose or usage, forcing the agent to rely solely on schema titles (e.g., 'Risks', 'Summary'), which are insufficient for correct invocation.
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: 'Escalate an issue for human approval' and provides an example use case. It specifies the verb ('request approval') and resource ('issue'), and distinguishes from sibling tools like 'close_issue' or 'transition_issue' by highlighting the approval workflow.
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 gives usage context: 'before closing risky work' and preconditions ('Valid only when the issue is in_progress or blocked'). It implies when to use this tool but does not explicitly mention when not to or name alternatives.
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 carries the full burden. It discloses partial update behavior ('only the fields provided'), which is useful. However, it does not mention required permissions, idempotency, or whether the tool returns the updated track (though output schema exists).
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 unnecessary words. The first sentence states the purpose and fields, the second provides a cross-reference to an alternative. Every sentence earns its place.
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 partially covers the tool's behavior and parameters but leaves gaps. The required slug parameter is not explained, and hive_id is unmentioned. However, the output schema may document the return value, reducing the need for explanation.
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 0%, so the description must compensate. It mentions three parameters (name, description, spec) but omits slug (required) and hive_id. This adds some meaning but is incomplete for a 5-parameter tool.
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 updates a track's name, description, or spec document. It also distinguishes itself from the sibling tool superpos_transition_track by noting that state changes should use that tool instead.
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 tells when to use this tool versus an alternative: 'Use superpos_transition_track to change state.' This provides clear context, though it does not specify any exclusions or prerequisites.
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 exist, so description carries full burden. It mentions rejection of invalid transitions but lacks details on side effects, atomicity, or whether the operation is destructive. Could be improved with post-condition or error handling behavior.
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 filler, front-loaded with purpose. Every word earns its place. Appropriate length for the tool's complexity.
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?
Has output schema, so return values are covered. However, lacks context on when to provide 'reason' or 'hive_id', and the precondition about checking transitions is the only usage context. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet description only explains 'to' implicitly through the state list. Parameters 'reason' and 'hive_id' are not mentioned, leaving their purpose unclear. Minimal value added beyond schema for most 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 clearly states the verb 'Move' and resource 'issue' with explicit list of target states (open, in_progress, blocked, awaiting_review, done, cancelled). It distinguishes from sibling tool 'superpos_transition_track' which handles tracks, not issues.
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?
Explicitly instructs to 'Check allowed_transitions on the issue first' and warns that 'invalid transitions are rejected', providing clear when-to-use guidance and precondition.
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 atomicity and conflict behavior. However, it does not mention the return value or any side effects beyond claiming, though the output schema may cover that.
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, with two sentences that front-load the purpose and key behavior. No extraneous words.
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 simplicity and the presence of an output schema, the description covers the essential purpose and behavior. It lacks parameter guidance but is otherwise complete for an atomic claim operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining parameter roles. It does not mention either task_id or hive_id. The parameter names are somewhat self-explanatory, but the description adds no value 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's purpose: 'Atomically claim a pending task so no other agent processes it.' This distinguishes it from sibling tools like superpos_get_task (retrieve only) and superpos_poll_tasks (list pending).
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 guides usage: 'Claim before starting work; fails with a conflict if already claimed.' This tells when to use it and what failure mode to expect, but does not explicitly state when not to use it or list alternatives.
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?
Discloses empty return behavior and filtering. No annotations provided, so description carries full burden; it covers key aspects but omits potential side effects or read-only nature.
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 efficient sentences, front-loaded with purpose, no redundant words.
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?
Adequate for a poll tool with output schema. Covers filtering and empty return, but lacks details on ordering or polling behavior, though not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only explains 'capability' parameter. With 0% schema coverage, description fails to explain 'limit' and 'hive_id', leaving ambiguity.
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 clearly the verb 'list' and resource 'pending tasks' with added context about filtering and empty return. Distinguishes from sibling tools like get_task and claim_task.
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?
Implies usage for finding work to claim, and when to filter by capability. Lacks explicit when-not-to-use or alternatives but is clear enough for an agent.
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 full burden. It mentions the timeout prevention behavior but does not disclose what happens if progress is out of range, whether the tool is idempotent, or what the response contains (output schema exists but is not described).
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 short, front-loaded sentences with no wasted words. Every sentence adds essential 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 tool's simplicity and the existence of an output schema, the description covers the core purpose and critical usage rule (30s interval). However, it lacks parameter details that would help the agent use it correctly without additional schema info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal meaning beyond the schema. It specifies a 0-100 range for progress but does not explain the task_id or optional parameters like hive_id and status_message.
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 'report' and resource 'progress on a claimed task' with a specific range (0-100), distinguishing it from sibling tools like complete_task or fail_task.
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?
Explicitly provides a usage guideline: 'Send at least every 30s during long work to prevent a server-side timeout.' This tells when and how often to use the tool, adding critical context for the agent.
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 exist, so the description must convey behavior. It mentions sending a heartbeat and optional status setting but does not disclose potential side effects, rate limits, or consequences of not calling it. For a read-only-like operation, this is minimal but 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?
Two sentences, front-loaded with the primary action ('Send a heartbeat'), no redundant information. Every word adds 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?
Tool is simple with one optional parameter and an output schema (details unknown). Description covers purpose and parameter sufficiently; it does not need to detail return values since output schema exists. Could optionally mention when not to use, but overall adequate.
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?
Input schema has 0% description coverage, so the description compensates by explaining the 'status' parameter: optional and lists possible values (online, busy, idle, offline, error). However, these are not formalized as enums in the schema, slightly reducing 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?
Description clearly states the tool sends a heartbeat to show the agent online in the dashboard, with an optional status update. This is a specific verb-resource pair with no sibling tools covering the same action.
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 implies when to use (to indicate agent liveness) but does not explicitly state when not to use or mention alternatives. However, given the tool's simplicity and lack of sibling overlap, this is acceptable.
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 full burden. It describes a read-only operation (checking connectivity and showing profile/hive/URL) with no mention of side effects. This is transparent and consistent with the tool's behavior.
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 just two sentences, front-loaded with the main purpose and usage guidance. Every sentence is necessary and there is no 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 the tool's simplicity (no parameters, no nested objects, output schema exists), the description fully covers what the tool does, what it shows, and when to use it. It is complete for its context.
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 input schema has zero parameters, so schema description coverage is 100% by default. The instruction states that 0 params earns a baseline of 4, and the description adds no further parameter info, which 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 checks Superpos connectivity and shows authenticated agent profile, configured hive, and base URL. It uses specific verbs (Check/Show) and identifies the resource. No other sibling tool serves this purpose, so it is well-distinguished.
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 'Call this first to verify setup,' which provides clear guidance on when to use the tool. It does not discuss when not to use it or alternatives, but for a verification tool, this is adequate guidance.
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:

[![superpos-mcp MCP server](https://glama.ai/mcp/servers/Superpos-AI/superpos-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Superpos-AI/superpos-mcp)

Score Badge

Copy to your README.md:

[![superpos-mcp MCP server](https://glama.ai/mcp/servers/Superpos-AI/superpos-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Superpos-AI/superpos-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/Superpos-AI/superpos-mcp'

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