mirofish-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Several tools have overlapping purposes, especially around status/progress monitoring: get_task, prepare_status, report_generate_status, get_report_progress, simulation_run_status, and check_report_status all serve similar roles with subtle differences. This makes it difficult for an agent to know which tool to call, leading to potential misselection.
Naming Consistency3/5
All tools share the 'mirofish_' prefix, which is good for namespacing, but the pattern after the prefix is inconsistent. Some tools use verb_noun (get_simulation, list_projects), others use noun_verb (report_generate_status), and a few are noun_noun phrases (simulation_run_status, simulation_history). This mixed style reduces predictability.
Tool Count2/5
With 50 tools, the server is far above the typical well-scoped range. Many tools are redundant (e.g., multiple report progress/status tools, several simulation status variants), making the surface area heavy and harder to navigate. The count should be reduced by consolidating related operations.
Completeness4/5
The tool set covers the main workflow comprehensively: project creation, ontology generation, graph building, simulation lifecycle, agent interviews, and report generation. Minor gaps exist, such as no update_project, no update_simulation_config, and no pause/resume for simulations, but these are not critical given the breadth of coverage.
Average 3.6/5 across 50 of 50 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
The description adds no behavioral context beyond the annotations. While annotations indicate idempotentHint=true, destructiveHint=false, and readOnlyHint=false, the description does not explain what 'close' entails (e.g., resource cleanup, reversibility, side effects). It merely restates the action without enriching the agent's understanding.
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 minimal redundancy, making it concise and front-loaded. The use of 'close/shut down' is slightly redundant but not overly verbose. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one fully documented parameter and annotations covering mutation and idempotency, the description is minimally adequate. However, it omits details about return values, success/failure behavior, or what closing entails, which would be useful for an agent to anticipate outcomes. The lack of output schema raises the need for such context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single required parameter simulation_id, so the baseline is 3. The description does not add any additional meaning about the parameter, such as format, default behavior, or edge cases, but the schema alone is sufficient for basic invocation.
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 action: 'Close/shut down a simulation environment.' This uses a specific verb and resource, distinguishing it from tools like stop_simulation and delete_project. However, it doesn't explicitly clarify the difference between 'environment' and 'simulation,' leaving some ambiguity with sibling tools.
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 mirofish_stop_simulation or mirofish_delete_project. It lacks prerequisites, context, or any mention of alternative tools, leaving the agent without direction on 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond what annotations provide—no mention of return format, pagination, or other traits. It adds no value here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. It contains no wasted words or redundant information, making it appropriately 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?
There is no output schema, so the description should clarify return values, but it only vaguely says 'details and current status'. It does not specify which details or how this differs from sibling tools like simulation_run_status or get_simulation_config. Given the tool's simplicity, the description is insufficiently informative for an agent choosing among many similar getters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with simulation_id documented as 'The simulation ID'. The description does not add any additional parameter semantics, but the schema already provides the needed meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get') and resource ('details and current status of a specific simulation'), making the core purpose clear. However, it does not differentiate from sibling tools such as mirofish_simulation_run_status or mirofish_get_simulation_config, which also fetch simulation-related details. The lack of distinction prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With over 40 sibling tools, including several simulation-specific getters, the absence of usage context or exclusions leaves the agent to guess. This is a clear gap.
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?
The description adds no behavioral context beyond what the annotations already provide (readOnlyHint, idempotentHint, destructiveHint). It does not mention return format, pagination, or other behavioral traits, so it offers no added value for 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 a single, straightforward sentence with no unnecessary words. It is concise and front-loaded, but it is also quite minimal and could include usage guidance without becoming verbose.
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?
With no output schema and many sibling tools, the description is insufficient. It does not explain what the configuration parameters contain or how this tool differs from get_simulation, get_simulation_profiles, or other simulation getters, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter simulation_id with a description, and the tool description does not add further semantics. Baseline of 3 is appropriate given high schema coverage.
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 a specific verb 'Get' with a resource 'simulation configuration parameters', indicating the tool retrieves configuration data. However, it does not explicitly differentiate from sibling tools like get_simulation or get_simulation_profiles, leaving minor ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about scenarios, prerequisites, or related tools, which is essential given the large number of simulation-related sibling tools.
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?
The description adds no behavioral context beyond the annotations, which already indicate read-only, idempotent, and non-destructive. It does not disclose what the return format is, whether it includes only completed interviews, or any limits. For a tool with no output schema, the lack of return information is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no extraneous words. It is appropriately concise for a simple retrieval tool.
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?
The tool has no output schema, and the description does not explain what the history contains, how it is structured, or when it is applicable. Given the availability of numerous sibling tools, more context about the return payload and usage scenario would be necessary to make the description complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with basic descriptions for simulation_id and agent_name. The description does not add any extra meaning or clarify how the parameters relate to the returned history. Baseline of 3 is appropriate when schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves conversation history for a specific agent interview, using the verb 'Get' and naming the resource. It distinguishes from interview initiation tools like mirofish_interview_agent, though it does not explicitly contrast with mirofish_simulation_history or explain the scope beyond 'specific agent interview'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., that an interview must have been conducted) or contrast with siblings like mirofish_interview_agent or mirofish_get_simulation_timeline. The description offers no 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds no additional behavioral context beyond restating the core action. It does not disclose return format, error behaviors, or how progress is measured, so it fails to add value beyond the annotations.
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 with no unnecessary words. It is front-loaded and immediately conveys the tool's purpose, though it lacks additional useful details. The brevity is a strength but leaves some gaps covered in other dimensions.
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 status-checking tool with no output schema, the description is too minimal. It does not explain what 'progress' looks like, whether a task_id or simulation_id is required, or what a successful response contains. This incompleteness makes it hard for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters ('task_id' and 'simulation_id') described. The description adds no extra meaning about parameter usage or relationships, but the schema already provides sufficient semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check the progress of simulation preparation' clearly states the tool's function with a specific verb and resource. It distinguishes itself from sibling tools like simulation run status or report generation status, though it does not explicitly mention alternative tools.
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 mirofish_get_task or mirofish_simulation_run_status. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction for tool 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds no behavioral context beyond the title's meaning—no details about return format, polling behavior, or potential errors. It doesn't contradict the annotations but provides zero additional 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 a single sentence with no fluff, which is concise and front-loaded. However, it is so minimal that it borders on tautological with the title, though it still conveys the core purpose efficiently.
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?
With no output schema, the description should explain what the tool returns (e.g., status values, progress percentage). It only says 'check the progress,' leaving return semantics ambiguous. It also doesn't clarify the relationship between task_id and simulation_id or which one to use. The presence of similar sibling tools increases ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description doesn't mention parameters, but the schema already explains task_id and simulation_id. The description adds no extra meaning beyond what the schema provides.
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 'Check the progress of report generation' clearly states the action and resource. However, it does not distinguish from sibling tools like mirofish_get_report_progress or mirofish_check_report_status, which likely serve similar purposes. The verb 'check' is specific, but differentiation is absent.
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. It doesn't mention prerequisites (e.g., after calling generate_report), nor does it reference any sibling tools. There is no context for choosing this over mirofish_get_task, mirofish_get_report_progress, or mirofish_check_report_status.
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?
The description adds no behavioral context beyond the annotations. The annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear, but the description does not disclose error behavior, return format, or any special conditions like 'no report found' that might occur. It simply restates the 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?
The description is a single, concise sentence: 'Get the report associated with a specific simulation.' It is front-loaded with the verb 'Get' and contains no filler, making it optimally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with one parameter and no output schema, so the description could suffice, but it lacks information about what exactly is returned (e.g., a report object or report metadata) and does not help the agent choose between this and similar tools like mirofish_get_report. Given the absence of an output schema, some return-value context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% since the only parameter, simulation_id, is described as 'The simulation ID'. The tool description adds no additional parameter-level meaning beyond what the schema already provides. Baseline 3 is appropriate because the schema carries the full burden.
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's purpose: 'Get the report associated with a specific simulation.' It identifies a specific resource (report) and context (simulation), which is more than a tautology. However, it does not explicitly distinguish from the sibling tool 'mirofish_get_report', which may retrieve a report by report ID, leaving potential for confusion.
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 mirofish_get_report or mirofish_list_reports. It does not mention prerequisites, exclusions, or why one might choose this tool over its siblings.
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?
Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds that the search uses Zep's semantic search, which is a useful behavioral detail. However, it does not disclose result format, return value structure, or any limitations, so it stays at the baseline.
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 filler. The key detail about semantic search is included. It is efficient and front-loaded, though slightly generic. It earns a 4 because it is well-structured and concise without sacrificing the core message.
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?
With no output schema and a large set of sibling tools, the description does not provide enough context about what results look like or how this tool differs from others. It does not explain limit behavior, result ordering, or whether the search is graph-scoped (graph_id implies it). This lack of guidance makes it incomplete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all three parameters with meaningful descriptions (query, graph_id, limit). The description adds no additional parameter-level meaning, and since schema coverage is 100%, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search the knowledge graph for facts and information') and names the resource. However, it does not differentiate from sibling retrieval tools like mirofish_get_entities or mirofish_get_graph_data, so it lacks the specificity needed for one-to-one tool selection.
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?
It provides no guidance on when to use this tool versus alternatives. There are no explicit use cases, exclusions, or references to sibling tools, leaving the agent without direction on when this search is preferred over other query methods.
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 destructiveHint=true already present in annotations, the description merely restates the action ('Delete') without adding any context such as irreversibility, cascading effects, or whether special permissions are required. It does not contradict annotations, but provides zero additional behavioral insight beyond the structured data.
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, front-loaded with the action, and zero wasted words. 'Delete a generated report.' is an appropriately sized description for a simple deletion tool.
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 delete with one parameter and full schema coverage, the description is adequate but lacks any mention of side effects, return values, or lifecycle context (e.g., cannot delete a report being generated). The presence of destructiveHint and complete param schema raise it to the minimum viable level, but it could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes report_id as 'The report ID to delete' with 100% coverage. The description adds no extra meaning about the parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'generated report', which is specific and distinguishes it from sibling delete tools like delete_project and delete_graph. No ambiguity about what this tool does.
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 or any exclusions/alternatives. There is no mention of prerequisites (e.g., report must exist) or that it should be used only for generated reports. Sibling tools like generate_report and get_report exist, but no comparative usage advice is 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds only the scoping phrase 'during a simulation' which is largely implied by the required simulation_id parameter. It does not disclose additional behavioral traits like return format or whether the simulation must be completed.
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, tightly worded sentence (9 words) that leads with the action and object. There is no redundancy, filler, or unnecessary explanation, making it appropriately concise for a simple one-parameter tool.
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 simplicity (one required parameter, clear annotations, no output schema), the description offers a minimal but acceptable level of completeness. However, since there is no output schema, the description could have clarified what statistics are returned or which agent behaviors are covered, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the only parameter, simulation_id, is already documented as 'The simulation ID.' The description's reference to 'during a simulation' adds no additional semantic meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names a clear resource: 'statistics about agent behavior during a simulation.' This conveys the core function. However, it does not explicitly distinguish itself from other statistics-related sibling tools like graph_statistics or get_simulation_profiles.
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?
There is no guidance on when to use this tool versus the many simulation-related siblings (e.g., get_simulation_actions, simulation_history). No prerequisites, limitations, or alternative suggestions are mentioned. The description leaves the agent without selection criteria.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the context of 'real-time' status and 'process state,' but does not disclose further behavioral details such as return format or whether the state is cached. This is acceptable but not highly informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the tool's purpose with no unnecessary words or repetition. It is well-structured and front-loaded with the key action and resource.
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 tool with one parameter and no output schema, the description gives a high-level overview but leaves the exact meaning of 'process state' and the format of the returned status unspecified. While the tool is simple, the lack of return-value details is a notable gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter simulation_id with a clear description, providing 100% coverage. The description adds no additional parameter semantics beyond what the schema already states, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Get' as a clear verb and specifically names the resource as 'real-time running status of a simulation including process state.' It differentiates from generic simulation retrieval tools by emphasizing the real-time status aspect, though it does not explicitly contrast with siblings like mirofish_simulation_run_status_detail.
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 usage guidance is provided. The description does not state when to use this tool instead of related tools such as mirofish_get_simulation or mirofish_simulation_run_status_detail, leaving the agent to infer the appropriate context on its own.
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?
The description does not disclose any behavioral traits beyond what annotations already indicate (destructiveHint: true). It simply repeats the action 'delete' without adding context such as permanence, cascading effects, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the action, target, and required parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one fully documented parameter and a destructive annotation, the description is largely sufficient. It could optionally mention permanence or return behavior, but these are not essential given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents graph_id with 100% coverage, and the description's 'by its ID' adds no meaning beyond the schema. The baseline of 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a Zep knowledge graph by its ID. It uses a specific verb ('Delete') and resource ('Zep knowledge graph'), distinguishing it from sibling tools like delete_project and delete_report.
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, nor does it mention prerequisites or exclusions. The intended usage is only implied by the verb 'delete'.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the 'real-time' behavior and 'current section' detail, but it does not disclose polling behavior, error conditions, or what happens when the report is not in progress.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the action and resource. Every word contributes meaning, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and read-only annotations, the description gives adequate context for basic use. It reveals the key output aspects (real-time progress and current section), though it does not specify the full return shape or cover potential edge cases, which is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the only parameter (report_id) with a clear description. The tool description adds no additional semantics beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets real-time progress of report generation, with a specific detail about the current section being written. However, it does not distinguish itself from sibling status tools like report_generate_status or check_report_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many alternative report status and retrieval tools. The description implies usage during report generation but omits explicit context, exclusions, or alternative tool references.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description does not add any additional behavioral context beyond the tool's purpose, but it is consistent with the annotations and contains no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded with the action and resource, making it easy to quickly understand.
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 only one parameter, rich annotations, and no output schema, the description adequately conveys the tool's purpose. However, it does not describe the output format or clarify whether a single profile or a list is returned, which is a minor gap.
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 for the single parameter (simulation_id) is 100%, so the schema fully documents its meaning. The description adds no extra parameter semantics beyond what is already in the input schema.
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's function with a specific verb ('Get') and resource ('agent profiles generated for a simulation'). It is easily distinguished from sibling tools by the unique 'agent profiles' focus, though it does not explicitly compare itself to alternatives.
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 other simulation-related tools such as mirofish_get_simulation or mirofish_get_simulation_config. There is no mention of prerequisites, timing, or 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the scope of async task categories but nothing beyond that—no mention of return format rate limits, or error behavior. Given the annotations, the description provides some additional context but is 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, concise sentence that is front-loaded with the core action ('Check the status and progress') and includes illustrative examples. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema) and the description adequately explains what it does and covers common use cases. It does not mention how to obtain a task_id or that it is the generic fallback for status checks, but these are minor omissions for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the only parameter (task_id) is 100%, with the description 'The task ID to check'. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking the status and progress of an async task, with concrete examples (graph building, simulation preparation, report generation). It uses a specific verb ('Check') and resource ('async task'), but does not explicitly differentiate from sibling status-specific tools like mirofish_simulation_run_status or mirofish_report_generate_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this generic task status tool versus the many sibling status-specific tools (e.g., mirofish_prepare_status, mirofish_simulation_run_status) or when to use a list endpoint like mirofish_list_tasks. The description implies a generic use case but gives no explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the scope 'all simulations' and the inclusion of 'run status and results', which provides some behavioral context beyond annotations. However, it does not describe pagination, result size, or any edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the verb and resource. It is concise, front-loaded, and contains no superfluous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description sufficiently conveys purpose and return content (history with run status and results). It lacks explicit mention of the list return shape or default limit, but the schema covers limit and the description is adequate for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (limit) with a complete description ('Max results') and 100% schema description coverage. The tool description does not add any parameter-related meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('history of all simulations'), and specifies that it includes run status and results. It is specific enough to distinguish from siblings like mirofish_list_simulations, but does not explicitly differentiate itself from similar tools.
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 instead of alternatives. It does not mention whether to prefer this over mirofish_list_simulations or mirofish_simulation_run_status_detail, nor 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?
Annotations already indicate this is a mutating, open-world, non-idempotent operation. The description adds the prerequisite about the knowledge graph, which is useful behavioral context. Yet it does not disclose important behavioral traits such as whether creating a simulation also starts it, what side effects occur, or whether the operation is reversible. Given the annotation coverage, a score of 3 is appropriate.
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 short sentences that are front-loaded with the primary action and immediately state the key prerequisite. There is no fluff or redundant information. Every word earns its place, making this an excellent model of 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 is complete enough for a simple create operation with full schema coverage and annotations. However, given the large set of sibling tools (prepare_simulation, start_simulation, stop_simulation, etc.), the description does not clarify where this fits in the simulation lifecycle or what the expected outcome is (e.g., does it return an ID?). The lack of an output schema further amplifies this ambiguity. A more complete description would mention the simulation lifecycle step and result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with clear descriptions (100% coverage). The tool description does not add any parameter-specific meaning beyond what the schema already provides. It only mentions the project as a conceptual source, which the schema already captures via project_id. This aligns with the baseline of 3 for full schema coverage.
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's function: 'Create a new multi-agent simulation from a project.' It identifies the specific verb (create) and resource (simulation), making the core purpose unambiguous. However, it does not explicitly distinguish itself from sibling tools like prepare_simulation or start_simulation, so it falls short of a 5.
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 a clear prerequisite: 'Requires a completed knowledge graph.' This is useful contextual guidance for when to use the tool. However, it does not mention alternatives or explicitly state when NOT to use this tool, leaving the agent without exclusions or comparisons to closely related simulation tools.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat safety traits. It adds the context that the tool targets the OASIS engine, but provides no additional behavioral detail like response format, status values, or prerequisites beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It uses front-loaded phrasing and contains no unnecessary filler or repetition of the title.
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?
This is a simple read-only tool with one parameter and no output schema, so the description should clarify what status information is returned. It does not mention possible status values or the response structure, leaving some ambiguity. However, given the tool's simplicity and annotations, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter 'simulation_id' is already documented. The description adds no further semantic detail about the parameter, such as format or constraints, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the status of the simulation environment, specifying the OASIS engine, which differentiates it from general health checks or simulation run status tools. It has a clear verb+resource structure, though it does not explicitly distinguish it from closely related siblings like simulation_run_status.
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—checking environment status—but provides no explicit when-to-use guidance or exclusions. It does not mention alternatives or scenarios where this tool would be preferred over sibling tools, leaving the agent to infer.
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?
The annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful context by stating that the tool filters by entity types and returns only matching nodes, which goes beyond the structured annotations. It does not cover pagination or return format, but the added filtering behavior merits a 4.
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 short sentences that directly convey the core function and filtering behavior. It contains zero filler, unnecessary detail, or overly technical jargon. Every clause 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?
Given the tool's simplicity, read-only annotations, and complete schema, the description covers the basics. However, it lacks any differentiation from the very similar mirofish_get_entities_by_type and does not clarify the effect of the `enrich` parameter on the returned data. With no output schema, the description should do more to set expectations about the response shape or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all three parameters, including explicit descriptions for `graph_id`, `enrich`, and `entity_types`. The description does not add new parameter details beyond mentioning entity type filtering, which the schema already covers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get all filtered entities') and a clear resource ('knowledge graph'), and it distinguishes the tool's behavior by noting it only returns nodes matching predefined entity types. However, it does not differentiate from the similarly named sibling tool mirofish_get_entities_by_type, leaving ambiguity about which one to choose.
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. It does not mention exclusions, prerequisites, or suggest a preferred scenario. With siblings like mirofish_get_entities_by_type and mirofish_get_graph_data, such guidance is critical.
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?
The description adds the behavioral trait 'chronological', which is useful context beyond the annotations. However, it does not disclose what constitutes 'events', whether the timeline is complete or filtered, or any details about return format or pagination. Given that the annotations already cover safety (readOnly, idempotent, non-destructive), this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the action and the resource. It is front-loaded with the verb and has zero waste. This is exemplary conciseness for a simple read-only tool.
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 one parameter, no output schema, and good annotations. The description is minimally viable but leaves ambiguity about what events are included and how the timeline is structured. Since there is no output schema and many sibling tools, more detail about the nature of events would improve completeness, but the current level is acceptable for a straightforward read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the only parameter, simulation_id, has a basic description. The tool description adds no additional meaning about the parameter—it does not explain how the ID is used, what formats are expected, or any constraints. Baseline 3 is appropriate since the schema carries the parameter 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 tool's function: 'Get a chronological timeline of events during the simulation.' The verb 'Get' plus the specific resource 'chronological timeline of events' is precise. This distinguishes it from siblings like get_simulation_actions (actions only) and simulation_history (broader history), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as mirofish_get_simulation_actions or mirofish_simulation_history. There is no mention of context, prerequisites, or exclusions. The description stands alone without helping the agent decide between similar read-only simulation tools.
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?
Annotations already indicate readOnlyHint=false and openWorldHint=true, so mutation is known. The description adds useful context about async execution, LLM generation, and the creation of a config, which goes beyond annotations. However, it does not explain side effects like what happens if already prepared or the cost/time implications of LLM calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that leads with the main purpose and lists key steps in a readable sequence. No redundant 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?
For a complex async tool with no output schema, the description covers the core workflow and return value (task_id). However, it omits how to check progression (e.g., prepare_status), prerequisites like existing entities, and the effect of force_regenerate on an already-prepared environment. These gaps reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all five parameters are described in the input schema itself. The description only loosely connects to parameters (e.g., 'LLM' implies use_llm_for_profiles) but adds no new meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Prepare a simulation environment') and outlines the concrete steps (reads entities, generates profiles via LLM, creates config). This clearly distinguishes it from sibling tools like create_simulation and start_simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to call this tool versus alternatives (e.g., after create_simulation, before start_simulation). There is no mention of prerequisites or exclusions. The async behavior hints at a follow-up via prepare_status but that is not explicitly stated.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only, non-destructive safety profile is covered. The description adds the scoping detail (by type) but no additional behavioral context such as effect of the enrich parameter, performance implications, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every word contributes to the core meaning: 'Get all entities of a specific type from a knowledge graph.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with fully documented parameters and strong annotations, the description is largely sufficient. It could be slightly improved by naming sibling alternatives for clarity, but the combination of description, schema, and annotations provides enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are documented. The description adds no extra parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 all entities'), the object ('of a specific type'), and the domain ('from a knowledge graph'). This specific scoping distinguishes it from sibling tools like mirofish_get_entities (which likely retrieves all entities without type filtering) and mirofish_get_entity_detail (which targets a single entity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as mirofish_get_entities, mirofish_search_graph, or mirofish_get_entity_detail. There is no mention of preferred contexts, exclusions, or 'instead of' references.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds context about the return including 'context and relationships' but does not disclose additional behavior such as response format or error cases.
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 unnecessary words. It is front-loaded with the primary action and resource, making it efficient and easy to scan.
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 (2 params, no output schema), the description is mostly complete. It conveys that the response includes entity details, context, and relationships. However, it could be slightly more explicit about what 'detailed information' entails, but it is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters (graph_id and entity_uuid) with descriptions, giving 100% coverage. The description does not add parameter-level details beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific entity', also specifying 'context and relationships'. This distinguishes it from sibling tools like get_entities or get_entities_by_type, though it does not explicitly name them as alternatives.
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 needing detailed information on a single entity, but there is no explicit guidance on when to use this versus alternatives or any exclusion criteria. It lacks clear when/when-not statements.
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?
Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower. The description adds minimal context by indicating the comments are 'generated by agents', but does not disclose return format, pagination, error behavior, or any other behavioral traits beyond what annotations provide.
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, front-loaded with the action and resource, with no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with one parameter, the description is almost complete. It states what is returned (comments/replies) and the context (during simulation), while annotations cover safety and schema covers parameters. It lacks explicit return structure but is sufficient for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'simulation_id' parameter, so the schema fully documents it. The description adds no additional parameter semantics, such as format or requiredness, which is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'comments/replies generated by agents during the simulation'. This distinguishes it from sibling tools like 'get_simulation_posts' by specifying 'comments/replies', making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It does not mention when to prefer this over 'get_simulation_posts' or any other tool, nor does it list 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?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the safety profile is well established. The description adds context about the content type (agent-generated, Twitter/Reddit style) but does not disclose any additional behavioral traits such as pagination, sorting, or volume limits. This is acceptable given the strong annotations, but the added value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately communicates the tool's purpose without any filler. Every word adds value, making it exemplary in conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with a single fully-documented parameter and no output schema, the description adequately explains what the tool returns (social media posts) and the context (agent-generated simulation posts). It lacks explicit sibling differentiation but is otherwise complete for the tool's simplicity.
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 only parameter, simulation_id, is fully described in the schema ('The simulation ID'), achieving 100% schema description coverage. The description text does not add any further parameter-specific details, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('social media posts'), further qualified by 'generated by agents during the simulation' and '(Twitter/Reddit style)'. This effectively distinguishes it from sibling tools like get_simulation_comments or get_simulation_actions.
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 explicit usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it offer any exclusions or contrasting sibling tools. Given the large set of similar simulation-related read tools, this lack of differentiation is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says the tool 'clears the graph', which is a destructive action on graph data. However, annotations set destructiveHint=false, directly contradicting the described behavior. Also, while it mentions keeping the ontology, it does not clarify whether the clearing is permanent or if there is any recovery mechanism. This is an Annotation Contradiction.
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 short sentences, front-loaded with the action and outcome. Every word adds value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description adequately covers the main side effect (clears graph, keeps ontology). However, the contradiction with the destructiveHint annotation and the lack of explicit irreversibility information prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full coverage for project_id with a description ('The project ID to reset'). The tool description does not add additional meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Reset' and the resource 'project's state', and clarifies the outcome: the knowledge graph can be rebuilt. It distinguishes from sibling tools like delete_project and delete_graph by explicitly stating it keeps the ontology while clearing the graph.
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 the tool: when a project's knowledge graph needs to be rebuilt while preserving the ontology. It doesn't explicitly mention exclusions or alternative tools, but the context is clear enough for an agent to differentiate from destructive delete operations.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds useful scope ('all agent actions taken during the run') but does not disclose additional behavioral details such as return format or pagination. This aligns with the expected baseline for annotated read-only tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is efficient and clear. Every word contributes to the meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one well-described parameter and strong annotations, the description is complete. It clearly states what the tool returns (all agent actions during the run), and no output schema is needed to understand the basic behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter simulation_id ('The simulation ID'), so the description adds no further meaning beyond what the schema provides. This matches the baseline of 3 for high schema coverage.
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 'Get' and the resource 'action log of a simulation', with scope defined as 'all agent actions taken during the run'. This makes the purpose specific, but it does not explicitly differentiate from sibling tools like get_simulation_timeline or get_agent_stats, so it stops short of a 5.
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 one needs an action log, but it does not provide any when-to-use or when-not-to-use guidance, nor does it name alternative tools. It is not misleading, but it offers no explicit exclusions or comparisons.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. The description adds the batch 'at once' behavior, but no further context such as response format, failure handling, or concurrency side effects, which would add value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. The first states the core action, and the second provides a meaningful use case. Every word earns its place with no redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has no output schema, so the description should cover return behavior. It explains the action but does not mention what the agent can expect as a response (e.g., per-agent answers) or how errors are handled (e.g., missing agent names). This leaves a noticeable gap for a batch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no new parameter-level detail beyond loosely echoing 'same question' (message) and 'multiple agents' (agent_names), which maps naturally to the existing schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource structure: 'Send the same question to multiple agents at once.' This clearly distinguishes the batch tool from siblings like mirofish_interview_agent (single agent) and mirofish_interview_all (all agents), even without naming them explicitly.
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 offers an implied use case ('useful for gathering diverse perspectives') but provides no explicit guidance on when to use this tool over alternatives such as mirofish_interview_agent or mirofish_interview_all. There are no exclusions or decision criteria.
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?
Annotations already indicate it is a write operation (readOnlyHint=false) and non-idempotent. The description adds useful behavioral context by stating that it creates a new project and expects multipart/form-data with actual file uploads. These extra details are not present in the annotations, so credit is given.
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 only two sentences and packs a lot of information, but the note introduces a slight contradiction (URLs/paths vs. actual file uploads). Despite that, it remains compact and front-loaded with the main purpose.
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?
There is no output schema, so the description should compensate by explaining the return value or next steps, but it does not. It covers input methods, file formats, and project creation, but omits what the caller should expect in the response (e.g., project ID, ontology data) and any error context. For a non-trivial generation tool, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minor guidance by mentioning simulation_requirement and project_name as scenario descriptors and notes that document_text can be used as a fallback for file uploads, but it does not enrich the meaning of additional_context or other parameters substantially.
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 that the tool generates an ontology (entity types and edge types) from seed documents and a simulation requirement, and that it creates a new project. This specific verb+resource combination distinguishes it from siblings like build_graph or create_simulation.
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 some usage guidance (e.g., use simulation_requirement and project_name, provide document text directly if no files), but it does not explicitly mention when this tool should be preferred over alternatives or exclusions. The note about multipart/form-data is helpful but also creates confusion with the earlier claim of accepting URLs/paths.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that only completed reports are returned and what components are included, but it does not disclose behavior for missing or incomplete reports or mention any auth/rate limits. This adds some context without overstepping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 15 words that conveys the action, resource, and return contents without unnecessary detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with strong annotations, the description is nearly complete. It names the resource, the retrieval criterion (completed by ID), and the response contents (outline, markdown, metadata). It could be enhanced by noting error handling or explicitly differentiating from get_report_sections, but it is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter report_id is already fully documented by the schema as 'The report ID'. The description does not add additional parameter semantics, such as format constraints or example values, beyond linking the ID to a completed report.
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: 'Get a completed report by its ID' and lists what is included (outline, markdown content, metadata). This distinguishes it from sibling tools like get_report_by_simulation (which retrieves by simulation) and list_reports, making the resource and verb specific.
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 the agent has a report ID and needs the full content, but it does not explicitly state when to use this tool versus alternatives. Sibling tools such as get_report_progress or get_report_sections are not referenced, so the guidance is implied rather than explicit.
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?
Annotations already indicate this is a read-only, idempotent, non-destructive operation. The description adds minimal behavioral context beyond the purpose, such as no mention of error conditions, return format, or authorization requirements. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the main action and target. No wasted words, and it gives sufficient clarity for a simple getter tool.
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 (two parameters, no nested objects, no output schema) and strong annotations, the description covers the essential purpose. However, it does not describe the return shape or any edge-case behavior, which could be useful in the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (report_id and section_index) with descriptions and constraints, so schema coverage is 100%. The description's reference to 'by index' adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the target resource ('content of a specific section'), with a specific selection method ('by index'). This distinguishes it from sibling tools like get_report_sections (plural) and get_report (whole report).
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 report section is needed by index, but it does not explicitly state when to prefer this over alternatives like get_report_sections or get_report. No exclusion criteria or alternative tool references are provided.
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?
Annotations already declare this as a read-only, idempotent, non-destructive operation. The description adds the specific behavioral detail of returning aggregate counts (nodes, edges, entity types), but does not elaborate on return format or error conditions. With annotations covering the safety profile, this modest addition is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and directly lists the output contents. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description adequately conveys the return value (statistics) and the required input (graph_id). It could be slightly more explicit about the response structure, but overall it is sufficient for an agent to know when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents graph_id with a simple description ('The graph ID') and coverage is 100%. The tool description does not add further semantic detail about the parameter, but the schema already provides the necessary meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving statistics (node counts, edge counts, entity type distribution) from a knowledge graph. It uses a specific verb ('Get') and resource ('statistics') and differentiates from sibling tools like get_graph_data or get_entities by focusing on aggregate metrics rather than raw data.
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 aggregate statistics are needed, but it does not explicitly state when to prefer this tool over alternatives such as get_graph_data or get_entities. No exclusions or alternative recommendations are provided.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds that it 'returns service status,' which is consistent but does not provide extra behavioral context such as error handling or meaning of "healthy." No contradiction.
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 short sentences, front-loading the main purpose and then the return value. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool with strong annotations, the description is sufficiently complete: it states the action, the resource, and the return. No additional details are necessary for a simple health check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter syntax. The empty schema is fully covered, and the description appropriately omits parameter details.
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 checks backend health and returns service status, using a specific verb and resource. It does not distinguish from sibling mirofish_env_status, which may overlap, but the purpose itself is unambiguous.
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 you want to know if backend is running) but provides no explicit when-to-use, exclusions, or alternatives. Given the sibling mirofish_env_status, some guidance on distinction would be helpful, but the basic use case is evident.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is safe. The description adds the detail that the same question is sent to all agents and responses are returned, but no additional behavioral traits like latency, ordering, or response format are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys both the action and the result. Every word is purposeful, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-documented parameters and annotations, the description is mostly complete: it states what the tool does and what it returns. It lacks any mention of response structure or potential cost for large simulations, but these are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already described in the schema. The description does not add extra semantics beyond aligning 'message' with 'the same question'. No additional parameter details are provided, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'send', the resource 'the same question to ALL agents', and the outcome 'returns all their responses'. It distinguishes from sibling tools like interview_agent (single agent) and interview_batch (likely a subset) by emphasizing 'ALL 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?
The usage context is implied by the tool name and the word 'ALL' in the description, but there is no explicit statement about when to use this tool versus interview_agent or interview_batch. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the behavior of optional filtering by simulation but does not disclose whether the response contains full report content or just metadata, nor how the 'limit' parameter affects the 'all' claim. Adds some value but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It clearly states the action, the object, and the optional modifier. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with rich annotations and complete parameter schema, the description covers the core functionality. It lacks explicit mention of the return format or pagination behavior, but given the low complexity and the absence of an output schema, it is mostly adequate. A slightly more informative alternative (e.g., naming a sibling for detail retrieval) would push it higher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—both 'limit' and 'simulation_id' are already described in the schema. The description only rephrases the filter option ('optionally filtered by simulation') without adding new parameter meaning, matching the baseline of 3 for high schema 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 uses a specific verb 'List' with a clear resource 'generated reports' and scope 'all'. It distinguishes from siblings like mirofish_get_report by emphasizing the plural/list nature, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to see all reports, optionally filtered by simulation, but it does not explicitly mention alternatives like mirofish_get_report or mirofish_get_report_by_simulation. No when-not-to-use guidance is provided, so it remains at the minimum viable level.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that tasks are 'background' and that statuses are included, which is useful but does not disclose details like pagination, ordering, or filtering 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 a single, focused sentence that conveys the essential purpose without redundancy. Every word earns its place, and it is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with read-only annotations and no output schema, the description is largely sufficient. It names the resource and the information returned (statuses), though it could optionally mention whether the list is exhaustive or paginated, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is trivially 100%. The description correctly does not imply any parameters, and with no parameters needed, the baseline of 4 is appropriate for this simple case.
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 all background tasks and their statuses, with a specific verb ('list') and resource ('background tasks'). The use of 'all' distinguishes it from sibling tools like mirofish_get_task, which retrieves a single 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 is provided on when to use this tool versus alternatives such as mirofish_get_task or other task-related tools. The description is self-contained but offers no exclusions, prerequisites, or context about when a bulk listing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful context that the status includes round progress and agent activity, but does not go beyond that to explain behaviors like response format or any latency considerations. It aligns with annotations and provides some incremental value, but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the verb, resource, and key details without any redundant or filler language. Every word earns its place, making it highly concise and properly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, read-only, no output schema). The description covers the essential content returned (round progress, agent activity) but does not fully specify the structure or exhaustive list of fields one might receive. Given the low complexity and good annotation coverage, the description is nearly complete, though a more explicit listing of return contents would be ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter, 'simulation_id', has the description 'The simulation ID'. The tool description adds no additional semantic meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific phrasing 'Get detailed running status of a simulation' with concrete inclusions ('round progress and agent activity'). It clearly distinguishes from the sibling tool 'mirofish_simulation_run_status' by marking the 'detailed' variant and specifying content, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'detailed' implies this tool is the richer version of the simulation run status, but the description provides no explicit guidance on when to choose this versus the sibling 'mirofish_simulation_run_status' or any other status tools. Usage context is only implied through naming and content, not explicitly stated.
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?
Annotations already indicate non-read-only, non-idempotent, non-destructive behavior. The description adds that agents will begin interacting, which is useful but does not disclose potential side effects like failure if already started or whether invocation is asynchronous. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action, and every word adds value. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter action tool with good annotations and no output schema, the description is mostly adequate. It could mention prerequisites or what happens after starting, but the core behavior is clear enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter simulation_id is fully covered by the schema description ('The simulation ID to start'). The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start running') and the specific resource ('a prepared simulation'), distinguishing it from sibling tools like mirofish_prepare_simulation and mirofish_stop_simulation. The scope is well-defined.
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 word 'prepared' implies a prerequisite (use after preparation), but there is no explicit when-to-use or when-not-to-use guidance, nor mention of alternatives. The usage context is only weakly implied.
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?
The description discloses that the tool deletes associated data, which complements the destructiveHint=true annotation. However, it doesn't add much beyond the annotation, such as irreversibility or cascading effects, though the annotation already covers destructive 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 a single concise sentence that front-loads the action and scope. Every word contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter, destructive annotation, and no output schema, the description provides complete information. It clearly states the target and the scope of deletion ('all its associated data'), making it sufficient for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter project_id, and the description adds no additional semantic meaning. With schema description coverage at 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and names the resource 'MiroFish project', clearly stating the action. It also distinguishes from sibling tools like mirofish_delete_graph and mirofish_delete_report by specifying 'all its associated data'.
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 usage is implied from the name and description, but no explicit guidance is given about when to use this tool vs alternatives like mirofish_reset_project or mirofish_delete_graph. It doesn't mention exclusions or prerequisites.
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?
Annotations already declare read-only, non-destructive, and idempotent behavior. The description adds useful context by stating that the response contains both nodes and edges and covers the entire graph, which is not expressed in the annotations. It does not mention error handling or potential payload size, but the added output shape information justifies a score above baseline.
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 that immediately states the action and object. Every word contributes meaning, and there is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval tool, the description adequately states what is returned (nodes and edges) and identifies the required input. However, it omits edge-case behavior (e.g., invalid graph ID) and does not mention whether the full graph could be large or require pagination. These gaps keep it from a perfect score, but it is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single required parameter (graph_id) with a clear example format. The description adds no new parameter-level information beyond restating that the graph ID is needed, so it meets the baseline but does not exceed it.
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 ('Retrieve'), identifies the resource ('full knowledge graph data'), and specifies the exact scope ('nodes and edges') tied to a graph ID. This clearly distinguishes it from sibling tools like get_entities or search_graph, which have narrower or different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when the full graph structure is needed—but it does not explicitly state alternatives or exclusion criteria. Sibling names such as get_entities_by_type and graph_statistics hint at other options, but the description itself provides no direct guidance.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a small amount of context about project composition (seed documents, ontology definitions) but does not disclose any behavioral traits beyond listing, such as pagination, ordering, or response format.
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 core purpose ('List all MiroFish projects'), and no wasted words. The second sentence adds useful domain context without redundancy.
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?
As a simple read-only list tool with one optional parameter and no output schema, the description adequately covers what it does. It explains the project concept, which is useful for an agent deciding whether to use this tool. It could mention that it returns a list, but that is strongly implied by the verb 'list'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single 'limit' parameter, including type, default, and bounds. The description does not need to elaborate on parameters because the schema already documents them fully; baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pair: 'List all MiroFish projects.' This clearly distinguishes it from sibling tools like mirofish_get_project, which likely fetches a single project. The additional context about projects containing seed documents and ontology definitions further clarifies the resource being listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when the agent needs to enumerate all projects, contrasting with get_project for a single project. However, it does not explicitly name alternatives or exclusion criteria, so it lacks the direct 'use this instead of X' guidance seen in higher-scoring examples.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe read operation. The description adds no behavioral detail beyond what annotations provide—no pagination, ordering, or return format info. Since annotations cover safety, the bar is lower, but this adds minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb and resource, and includes the optional filter information without any redundant wording. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no output schema, the description is reasonably complete: it states what it lists and the available filter. However, since there is no output schema, it ideally would mention return format or pagination behavior, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'limit' and 'project_id'. The description's mention of 'optionally filtered by project' aligns with project_id but adds no new meaning beyond the schema. Baseline of 3 applies because the schema fully documents the 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 uses the specific verb 'list' with the resource 'simulations' and clearly states scope ('all') with an optional filter, distinguishing it from get_simulation (single retrieval) and create_simulation (mutation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for listing simulations with an optional project filter, providing clear context for when to use it. However, it does not explicitly exclude alternatives such as get_simulation for single-item retrieval or simulation_history for historical data, so no explicit when-not guidance is 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?
Annotations already declare idempotentHint=true and destructiveHint=false, covering key behavioral traits. The description itself adds little beyond restating the action ('Stop') and the target state ('running'). No extra context is provided about side effects or resource release. This meets the baseline for annotation-backed tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. Every word ('Stop', 'a running simulation') contributes to the purpose. It is appropriately sized for the tool's simplicity.
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 simple parameter set (one ID), the presence of annotations for idempotency and destructiveness, and no output schema, the description covers the essential purpose. It is brief but adequate; it could mention post-condition behavior (e.g., simulation becomes stopped) but is not critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'simulation_id' already described as 'The simulation ID to stop'. The description does not add any extra meaning beyond the schema, so it stays at the baseline of 3.
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 'Stop a running simulation.' uses a specific verb ('stop') and resource ('a running simulation'), clearly distinguishing it from start/create/simulation tools. It adds scope ('running') that differentiates it from merely referencing simulation management.
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: the simulation must be running to stop it. This is a clear condition, and the tool's placement among sibling tools makes its purpose obvious. However, it does not explicitly mention alternatives or exclusions, though none are needed given the straightforward action.
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 async operation and task_id return, which are not in annotations. Annotations already indicate non-read-only, non-destructive, non-idempotent, so description adds value with polling 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, direct, no filler. Front-loaded with main action.
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?
Provides essential async polling info and scope. Missing details about prerequisites are in schema; output schema absent but return type is mentioned.
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 descriptions cover all 5 parameters (100% coverage), so description adds little beyond noting documents/ontology context. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Build' with specific resource 'knowledge graph' from project documents and ontology. Distinguishes from sibling tools like get_graph_data (retrieval) and delete_graph (deletion).
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?
Explicitly states async behavior and how to poll with mirofish_get_task, giving clear usage context. Does not mention alternatives or prerequisites, but the schema covers the ontology prerequisite.
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?
Annotations already cover read-only and non-destructive behavior. The description adds meaningful behavioral context by stating the agent can search the knowledge graph and use tools, which goes beyond what annotations provide and helps the agent understand the tool's interactive capabilities.
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 that front-loads the primary purpose and key capability. It contains no redundant or extraneous 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 the tool's interactive nature, the presence of full schema coverage, and annotations, the description adequately explains what the tool does and its capabilities. While it doesn't detail response format, 'conversation' implies a textual exchange, and the lack of an output schema makes this acceptable. The schema covers parameter specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description (e.g., message, chat_history, simulation_id). The tool description adds no extra parameter-specific semantics, so the baseline of 3 applies. It could have elaborated on how chat_history is used, but the schema already suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('Have a conversation with the Report Agent about a simulation's results'), uses a specific verb ('Have a conversation'), and names a distinct resource ('Report Agent') that sets it apart from sibling tools like interview_agent or get_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context ('about a simulation's results') and implies usage for querying report-related information through a conversational interface. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer when this tool is appropriate.
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?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false). The description adds behavioral context by indicating it checks existence ('has a report') and status, and connects it to interview unlocking. It doesn't describe possible status values or return format, but with annotations covering side effects, a 4 is appropriate.
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 a purposeful clarification. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with rich annotations and no output schema, the description covers the essential purpose and usage context. It could be improved by explaining what 'status' means or what determines 'unlocked,' but it remains sufficiently complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with a description for simulation_id ('The simulation ID'). The description does not add further parameter details beyond confirming the input is a simulation ID. Baseline 3 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Check if a simulation has a report and its status.' It also distinguishes itself from sibling tools by explaining the purpose: 'Used to determine if interview is unlocked,' which sets it apart from other report and simulation status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Used to determine if interview is unlocked.' This gives context for when to use the tool. However, it does not explicitly mention alternatives or when not to use it, so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds value by specifying the returned content categories (ontology, files, status, graph info), which helps set expectations. It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 17 words, front-loaded with verb and object, no filler. Every phrase ('including ontology, files, status, graph info') earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with one parameter, good annotations, and no output schema, the description provides a solid overview. It names the key included components but doesn't detail the exact response structure, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: `project_id` is described as 'The project ID (e.g. proj_xxxx)'. The description's phrase 'by its ID' adds no semantic value beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'specific MiroFish project by its ID', clearly differentiating from sibling `mirofish_list_projects` (which lists all) and `mirofish_delete_project` (deletes). It also lists included content (ontology, files, status, graph info), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage when you have a specific project ID and need its details. It doesn't explicitly name alternatives or exclusions, but the context (by ID vs list) is clear. A small gap is lack of explicit 'use list_projects to enumerate' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable behavioral context beyond annotations: the tool returns partial results during generation and can be polled. This is not apparent from the annotations alone, providing useful transparency about how the tool behaves over time.
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 exactly two sentences, front-loaded with the core purpose and followed by a concise usage detail. Every word earns its place, with no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and strong annotations, the description is sufficiently complete. It states what the tool does, when to use it (polling during generation), and the partial-result behavior. No output schema exists, but given the low complexity, the description covers the essential context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter report_id with a basic description 'The report ID.' The tool description adds no additional meaning about the parameter beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Get all generated sections of a report.' The inclusion of 'all' clearly distinguishes it from the sibling tool get_report_section (singular), making the scope explicit. The additional note about polling during generation further specifies the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions a use case: 'Can be polled during generation to get sections as they complete.' This gives clear context for when the tool is appropriate. However, it does not explicitly state when not to use it or mention alternatives such as get_report_section for a single section, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe, non-mutating profile. The description adds valuable context that the agent's responses are based on 'its personality, memories, and actions during the simulation,' giving the caller expectations about the content and grounding of responses. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the core action and then add relevant behavioral context. There is no wasted wording or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, full schema coverage, and annotations for read-only and open-world behavior, the description is sufficiently complete. It explains what the tool does and what influences the agent's responses, without needing to detail return values or error cases beyond what annotations and schema imply.
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?
All three parameters (simulation_id, agent_name, message) are fully described in the input schema, so the schema carries the semantic weight. The description adds no additional parameter-level information, which corresponds to the baseline score for full schema 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's purpose: 'Interview (chat with) a specific simulated agent.' The verb 'interview' and resource 'specific simulated agent' distinguish it from batch/all siblings like interview_batch and interview_all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for chatting with a single, specific agent, implying it should be used when an individual agent's perspective is needed. However, it does not explicitly mention alternatives or conditions like 'use interview_batch for multiple agents,' so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds key behavioral context beyond the annotations by stating the operation is asynchronous and 'returns task_id to poll'. This informs the agent that the tool does not immediately return the report and that subsequent polling is needed, which is a critical runtime 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 a single, information-dense sentence that front-loads the verb, resource, and key async behavior. There is no fluff; every phrase contributes meaning, making it easy to read and parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an asynchronous report-generation tool, the description covers the essential points: input prerequisite, action, and return mechanism (task_id). It does not describe the full post-generation workflow (e.g., how to fetch the report), but that falls under sibling tools like mirofish_get_report or mirofish_check_report_status, so the description is complete for its own scope.
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?
With 100% schema description coverage, the baseline is 3, but the description adds semantic value by qualifying simulation_id as requiring a 'completed simulation', which is not stated in the schema. The force_regenerate parameter is not mentioned in the description, but its schema description already covers its meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Generate' with a clear resource ('a prediction/analysis report') and a clear input condition ('from a completed simulation'). This distinguishes it from sibling report tools like mirofish_get_report, mirofish_delete_report, and mirofish_list_reports, as it focuses on creation rather than retrieval or management.
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 a clear prerequisite ('from a completed simulation') that tells the agent when the tool is valid to invoke. However, it does not explicitly mention alternatives or exclusions among the many report- and task-related siblings, so while the context is clear, there is no direct comparison.
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:

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

Score Badge

Copy to your README.md:

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

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/thisisaman408/mirofish-mcp-server'

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