runn-mcp

Server Quality Checklist

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

Latest release: v0.2.1
Disambiguation5/5
Each tool targets a distinct resource/action combination. Even closely related tools like runn_list_people vs runn_list_placeholders are clearly separated by entity, and runn_list_actuals vs runn_bulk_actuals are list vs create/update. No two tools appear to do the same thing.
Naming Consistency3/5
Most tools follow the `runn_<verb>_<noun>` pattern (e.g., runn_create_project, runn_list_phases). However, several deviate: runn_report_totals_project, runn_report_hours_project, runn_bulk_actuals, runn_server_info, and runn_whoami are not clearly verb_noun. This mixed convention slightly reduces predictability.
Tool Count2/5
32 tools is well above the recommended range for a coherent set. Even accounting for the broad domain (projects, phases, milestones, assignments, actuals, workstreams, reports, auth), the count feels heavy and could overwhelm agents. Some consolidation might be possible.
Completeness4/5
The set covers the core lifecycle for projects, phases, milestones, assignments, actuals, workstreams, and people. Minor gaps exist (e.g., no delete_project, no update_assignment, no delete_milestone), but these may reflect API constraints and are typically workable (e.g., delete and recreate assignment). Reports cover the key planning vs. actuals use cases.
Average 3.8/5 across 32 of 32 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions filters and placeholders but does not disclose pagination behavior, default limits, return format, or whether the operation is read-only. The word 'List' implies read, but no explicit safety or behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences convey the core purpose and key options with zero waste. Perfectly concise for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters and no output schema, the description omits pagination defaults, cursor usage, fetchAll behavior, and return shape. It is minimally adequate but leaves significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, so the description partially compensates by naming filterable fields (name/email/externalId). However, it does not explain filter semantics (e.g., exact vs partial match, AND/OR combination), and the schema already covers limit/cursor/fetchAll/includePlaceholders.
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 lists people with optional placeholders and filtering by name/email/externalId. It is specific and distinct from sibling list tools, though it doesn't explicitly contrast with runn_list_placeholders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like runn_list_placeholders. The mention of 'optionally include placeholders' hints at overlap but doesn't explain when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List workstreams,' omitting critical behaviors like pagination (limit, cursor), fetchAll support, response shape, or whether this is a read-only operation. The schema's parameter descriptions cover some mechanics, but the description itself adds no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, containing no wasted words. However, it is under-specified for a tool with pagination options, so it misses an opportunity to pack useful context while remaining 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?
The tool has no output schema and no annotations, so the description must explain return values and usage context. It does not mention what the response contains, pagination behavior, or the relationship to other workstream tools. Although the schema documents all parameters, the description is too thin for an agent to fully understand invocation outcomes.
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 even with no parameter info in the description. The description adds no additional meaning beyond what the schema already provides for limit, cursor, and fetchAll, so it neither helps nor hurts.
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 'List workstreams.' uses a specific verb and resource, clearly indicating the tool's function. It distinguishes from sibling list tools by naming 'workstreams' as the target resource, though it lacks any scope details (e.g., 'all' or 'by project').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., runn_create_workstream, runn_list_phases). It also does not mention prerequisites or context like whether it lists all workstreams in a workspace or for a specific project.
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?
There are no annotations, so the description must fully disclose behavioral traits. It states the core behavior (by-day plan vs actual hours) and that it's a GET request, but it does not mention pagination behavior, date range handling, or output format. It reveals basic purpose but omits operational nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that includes the endpoint path, making it front-loaded and free of fluff. It is appropriately sized for a simple report tool, though it could have included more 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 no annotations, the description is incomplete. It does not explain return values, pagination details, or how this report differs from similar project/hour reports. The presence of 6 parameters, including pagination controls, demands more context than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description adds no parameter details beyond what the schema already provides. The path indicates personId is the main identifier, but the description does not explain the semantics of startDate/endDate, cursor, or fetchAll. It fails to compensate for the gaps in 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 clearly states the tool's function: 'By-day plan-vs-actual hours for a person' with an explicit HTTP GET endpoint. It identifies the resource (person hours) and the context (by-day plan vs actual), distinguishing it from sibling tools like runn_report_hours_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions or sibling tools (e.g., 'for project hours use runn_report_hours_project'). The description only states what it does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden for behavioral disclosure. It only says 'list' and defines the resource; it does not mention pagination defaults, cursor behavior, fetchAll caps, or the read-only nature of 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, front-loaded sentence that states the action and resource, followed by a compact definition. Every word earns its place, with 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 simple list tool with complete parameter schema descriptions, this is largely sufficient. The definition adds useful context, though the absence of an output schema and lack of details about default pagination or return shape leave minor gaps.
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 have full schema descriptions (100% coverage), so the description does not need to repeat parameter semantics. It adds no additional param meaning beyond the schema, which aligns with the baseline 3.
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 'List placeholders' with a useful parenthetical defining what a placeholder is. It distinguishes the resource from other list tools by adding domain context, but does not explicitly differentiate it from sibling runn_list_roles.
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 guidance on when to use this tool versus alternatives like runn_list_roles or runn_list_assignments. The definition implies a business use case but does not provide conditions, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that it lists entries and can be filtered, but does not mention pagination behavior (limit, cursor, fetchAll), whether filters combine with AND/OR, or any default ordering. It also does not indicate potential side effects or performance characteristics. The description is minimal and hides significant behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently structured sentence that front-loads the action ('List') and resource ('actual (timesheet) entries') before listing filters. Every word earns its place; there is no redundant detail or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no annotations, and no output schema, the description covers the core purpose and filters but omits pagination behavior, ordering, and usage context. It is sufficient for an agent to understand what the tool does, but not fully complete for complex invocation scenarios such as handling large result sets or understanding default limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 56%, so the description partially compensates by naming the filterable fields. However, it only repeats the parameter names (project, person, role, workstream) without explaining semantics like whether multiple IDs are allowed or how dates are inclusive (which the schema does partially). It adds marginal clarity over the property names but does not deeply explain parameter relationships or format beyond identifiers.
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: 'List actual (timesheet) entries' with specific filter dimensions (project, person, role, workstream, date range). This is a specific verb+resource definition that distinguishes it from sibling reporting tools like runn_report_hours_* or runn_bulk_actuals, which are either aggregate/reporting or mutation 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. It does not mention that runn_report_hours_* are aggregate reports, that runn_bulk_actuals creates/updates actuals, or when a filtered list is preferred. There is no explicit when-to-use, exclusions, 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?
The description discloses a key behavioral trait: 'billableMinutes/totalMinutes use actuals where present, else assignments.' However, no annotations are present, and the description does not state whether the operation is read-only, how pagination behaves, or what happens with missing dates. It provides some transparency but not comprehensive coverage.
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, each carrying distinct value: the first states the purpose and endpoint, the second clarifies the data fallback logic. No redundant phrases.
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 no annotations, the description should explain the return structure and parameter interplay. It only mentions two output fields and leaves date handling and pagination behavior unspecified. It is inadequate for a 6-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (limit, cursor, fetchAll have descriptions; projectId, startDate, endDate do not). The description adds no parameter explanations, such as the meaning or constraints of startDate/endDate. It does not compensate for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'By-day plan-vs-actual hours for a project' with the endpoint. This clearly distinguishes from sibling report tools like runn_report_totals_project (totals) and runn_report_hours_person (person-level).
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. It does not mention that runn_report_totals_project should be used for aggregated totals or runn_report_hours_person for person-level reports. The usage context is implied only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the HTTP method (GET), the return shape (a single totals object), and explicitly notes the absence of pagination. However, it does not mention authentication, error behavior, or the specific fields in the totals object, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that includes the core function, the endpoint, and the return characteristic (no pagination). There is no wasted wording, and it is immediately front-loaded with the 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?
For a simple tool with one parameter and no output schema, the description provides the essential purpose and return shape but omits usage context and the structure of the totals object. It is minimally viable for an agent to invoke, but it lacks details about when to use it and what fields are returned.
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 only provides an integer type for projectId with 0% description coverage. The description compensates by embedding the parameter in the endpoint path (projects/{id}), indicating it is the project's ID. This adds semantic meaning beyond the schema, though it does not explain how to obtain or format the ID.
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 reports aggregated plan/actual minutes for a project, with the specific endpoint GET /reports/totals/projects/{id}. It identifies the resource (project) and the action (report totals). However, it does not explicitly differentiate from the sibling runn_report_hours_project, so it misses the top tier.
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 offers no guidance on when to use this tool versus alternatives like runn_report_hours_project or runn_get_project. It only states what it returns, leaving the agent to infer the appropriate context without explicit exclusions 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?
With no annotations provided, the description must carry the behavioral disclosure. It does disclose the PATCH method and partial-update semantics ('Only provided fields change'), which is useful. However, it does not mention auth requirements, error handling, or what happens if the milestone does not exist, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the action and resource. The additional clarifying clause about partial updates adds value without unnecessary verbosity. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are 6 parameters, no annotations, and no output schema, the description is too sparse. It lacks parameter documentation, usage scenarios, and any mention of return values or side effects. The PATCH endpoint and partial-update note help, but the description is not complete enough for an agent to use the tool confidently without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the six parameters. While field names (date, icon, note, title) are self-explanatory and the path includes projectId and milestoneId, the description adds no detail about allowed values, formats, or required versus optional fields beyond what the schema already provides. The general statement 'Only provided fields change' is too generic to compensate for the lack of parameter-specific guidance.
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: 'Update a milestone' with a specific REST endpoint (PATCH /projects/{id}/milestones/{milestoneId}). It uses a specific verb+resource combination and distinguishes it from sibling tools like create_milestone or delete_milestone.
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 ('Update a milestone') but does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites. The addition of 'Only provided fields change' gives some context for partial updates, but there is no direct guidance on when to choose this over other milestone-related 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It does disclose the PATCH method and partial-update semantics, which is helpful. However, it lacks any mention of side effects, required authentication, idempotency, or return behavior, leaving notable gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and includes a key behavioral note. There is zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 12 parameters, no annotations, and no output schema, the description is severely under-specified. It provides only the partial-update semantic and does not explain return values, parameter usage, or any operational context, making it inadequate for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for any of the 12 parameters. The field names and types in the schema are the only guidance, which is insufficient for correctly invoking the tool, especially for ambiguous enums like rateType and pricingModel.
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 ('Update a project') and the resource (project), and includes the specific HTTP method and path (PATCH /projects/{id}). This unambiguously distinguishes it from sibling tools like runn_create_project, runn_get_project, and runn_list_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Only provided fields change' provides clear context that this is a partial update tool, which helps the agent understand when to use it versus a full replacement or create. However, it does not explicitly compare to alternatives or state conditions for non-use, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses only that the tool lists/filters assignments, but omits important behavioral details like pagination (default one page, fetchAll for all items) and the nature of the response. This is a significant gap, even for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that immediately states the operation and then lists filters. It has no filler and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description is too thin. It covers filtering but not pagination behavior, return value expectations, or additional usage context. For a tool with this complexity, the description should provide more guidance.
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 63%, so the baseline is 3. The description adds minimal value by grouping filters into categories (project, person, role, date range), but it does not elaborate on parameters like limit, cursor, or fetchAll, which remain explained only in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List assignments') and the resource, and it distinguishes the tool from siblings by listing filterable dimensions (project, person, role, date range). This is a specific, non-tautological statement of 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 implies when to use the tool (when needing to list/filter assignments by project, person, role, or date range), which is clear contextual guidance. However, it does not explicitly mention alternatives or exclusions, so it stops 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds a useful behavioral note that the response may contain multiple segments if the period overlaps leave, which is beyond what the schema shows. However, it does not disclose other side effects, permissions, or failure modes, so it is only partially transparent.
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: first states the action and endpoint, second lists required fields and a key behavioral note. It is front-loaded, efficient, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and very low schema coverage, this description is incomplete. It mentions segment multiplicity in the response but does not explain the broader response structure, optional parameters, or how dates and minutesPerDay interact. The tool's complexity is not matched by the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 9%, so the description must compensate. It merely repeats the required parameter names from the JSON schema without explaining their meaning, types, or formats. The only schema description (for isBillable) is not echoed in the text. Thus minimal value is added beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create an assignment (POST /assignments)', explicitly stating the verb and resource. This clearly differentiates it from sibling tools like runn_create_phase or runn_create_project, which target different entities.
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 implied usage is clear: use when creating an assignment. It lists the six required fields, giving actionable guidance. However, it does not explicitly name alternatives (e.g., use runn_update_assignment for modifications) or state when not to use this tool, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some behavioral context (case-insensitive substring filter, archived toggle) but omits important traits like pagination defaults, fetchAll behavior, or that includeArchived defaults to true. It does not disclose potential side effects (none expected) but leaves room for more clarity.
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 primary action and then summarizes the most useful optional filters. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameters well, the description does not mention return format or pagination behavior, especially since there is no output schema. It is adequate for a simple list operation but incomplete for an agent that needs to understand result structure and paging upfront.
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 high (86%) and already describes most parameters. The description only paraphrases the name filter and includeArchived, adding no new semantic meaning beyond what the schema provides. It does not clarify undocumented fields like externalId.
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 'List projects' with a specific verb and resource, distinguishing it from singular get_project and mutation tools. It also mentions key filtering options, making its scope unambiguous among sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for enumerating projects but provides no explicit guidance on when to choose this over similar tools like runn_get_project or runn_list_phases. It lacks exclusions or alternative references, relying on the tool name to convey usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It only says 'list roles' and gives a use case; it does not mention that this is a read-only operation, pagination defaults, rate limits, or return format. For a list tool with no annotations, this 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 sentence that front-loads the core action ('List roles') and immediately clarifies the purpose in a parenthetical. No redundant or filler content; every word 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?
For a simple list operation, the description plus well-documented schema suffice for basic invocation. However, there is no output schema and no mention of what a response looks like or any behavioral edge cases (e.g., capping of fetchAll). The description is adequate but not complete for an agent unfamiliar with the API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all three parameters (limit, cursor, fetchAll) with clear descriptions. The tool description does not add parameter-specific semantics beyond the schema, so baseline 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?
Description uses a specific verb ('list') and resource ('roles'), and adds a clear use case: 'for resolving roleId values used in assignments/actuals'. This distinguishes the tool from sibling list tools (people, projects, etc.) and makes its intent obvious.
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 parenthetical provides clear context on when to use this tool: when you need roleId values for assignments/actuals. While no explicit exclusions or named alternatives are given, the tool is unique among siblings, so the guidance is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action and HTTP method. It does not disclose permissions, reversibility, error behavior, or other side effects, which is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with the endpoint in parentheses. It is concise and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operation is simple with only two required parameters, but the description lacks details on return values, error handling, or prerequisites. It is sufficient for basic tool selection but not comprehensive.
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 0%, but the verb 'rename' implies that 'name' is the new name and 'workstreamId' is the target. This adds semantic meaning beyond the schema's type definitions, though it is not explicit.
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 verb and resource: 'Rename a workstream' with the endpoint. It clearly distinguishes from sibling tools like runn_create_workstream and runn_delete_workstream.
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 use when renaming a workstream. It does not explicitly mention alternatives or exclusions, but the context is clear enough given the tool's name and the action described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the operation is a POST request and mentions required fields, but does not discuss permissions, response format, idempotency, or side effects beyond creation. This gives some transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the main purpose and following with required inputs and icon options. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter create tool with no annotations and no output schema, the description provides the key requirements and endpoint, but leaves out nuances like the optional note, projectId semantics, and any response behavior. It is minimally sufficient but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20% of params). The description repeats that title, icon, and date are required (already in schema) and restates the icon preset/emoji option (already in schema's icon description). It adds no new meaning for projectId or note, so it fails to compensate for low 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 identifies the action (create), the resource (milestone), and the target (project), and includes the REST endpoint. It distinguishes from sibling tools like runn_update_milestone and runn_list_milestones through the verb 'create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating milestones, but does not explicitly mention alternatives or when not to use it (e.g., for updates, use runn_update_milestone). It provides clear context of its purpose, but no exclusionary 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?
With no annotations, the description carries the full burden. It discloses the PATCH method and partial-update behavior ('Only provided fields are changed'), which is valuable. However, it does not mention permanence, permissions, side effects, or return behavior, leaving some transparency gaps for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose, endpoint, and key behavior with zero filler. Perfectly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and partial-update nuance, but given the lack of output schema and annotations, it omits return format, error scenarios, and any prerequisites. For a tool with 6 parameters and no structured context, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining parameter meanings. It only references projectId and phaseId in the endpoint path, without elaborating on their semantics or the optional fields (name, color, dates). This provides minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Update a phase', with the specific PATCH endpoint, distinguishing it from sibling tools like runn_create_phase and runn_delete_phase. The phrase 'Only provided fields are changed' further clarifies partial update semantics.
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 only provided fields are updated, implying partial updates and that not all fields are required. However, it does not explicitly mention when to avoid using this tool or reference alternatives (e.g., use runn_create_phase for new phases), 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a mutating POST operation, which indicates a write action. However, it omits details about permissions, error behavior, or prerequisites like project existence. Since no annotations are provided, the description carries the full burden, but the core mutation is clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and endpoint, with no unnecessary words. It efficiently includes required fields and color constraints.
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 adequate for a simple create action, covering the action, endpoint, and key parameters. However, it lacks information about return values, error handling, and prerequisites such as project existence. Given no output schema or annotations, slightly more context would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only has a description for color, and the description text adds that color defaults to #67D0D5 and lists required fields. It does not explain projectId or date formats beyond the schema's pattern, but parameter names are self-explanatory. The description partially compensates for low 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 function with a specific verb ('Create') and resource ('a phase on a project'), and includes the endpoint. It distinguishes from sibling tools like update_phase and create_milestone by specifying phase creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by listing required fields (name, startDate, endDate) and the endpoint, implying when this tool should be used to add a phase. It does not explicitly exclude any scenarios or mention alternatives, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It explains the creation action and the template duplication behavior, and it notes the requirement of name + clientId in standard mode. However, it does not disclose side effects, return value, or any permission prerequisites, which are relevant for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the tool's purpose ('Create a project'). It efficiently conveys the main usage modes without unnecessary filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters and a nested object with no output schema, the description covers the two main creation paths but omits many other parameters and does not mention the return value or response behavior. It is workable for an agent, but leaves gaps especially in understanding optional fields and expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at only 15%, the description partially compensates by explaining the key parameters: name, clientId, and the fromTemplate object with templateId and startDate. This adds meaning beyond the raw schema, particularly the two-mode logic. However, most parameters (emoji, budget, rateType, etc.) are undocumented, making the description insufficient for fully understanding all inputs.
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 'Create a project' with the API endpoint 'POST /projects', specifying the verb and resource. It distinguishes this from sibling tools like update_project and get_project by focusing on creation. The mention of standard vs template modes further clarifies the two distinct creation paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by outlining two modes: standard requires name + clientId, and alternative fromTemplate requires templateId + startDate. It does not explicitly state when not to use this tool or mention alternatives, but the modes serve as implicit guidelines for when each 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?
With no annotations provided, the description carries the full burden. It discloses the HTTP method (DELETE) and explicitly states 'hard delete', indicating the action is permanent and irreversible. This is valuable behavioral context, though it doesn't cover return values, errors, or permissions.
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 with no unnecessary words. It front-loads the primary action and includes the endpoint and hard-delete caveat, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter delete tool, the description covers the core action and irreversibility, but lacks information about expected return values, failure modes, or side effects. Given there is no output schema and no annotations, a bit more detail would improve completeness, but it's minimally viable for a simple 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?
The input schema has 0% description coverage, but the only parameter (assignmentId) is self-explanatory. The description adds 'by ID' which maps directly to the parameter, but doesn't provide additional details like accepted formats or constraints. The parameter is simple enough that this is adequate, but not exceptional.
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 specifies the action (Delete), the resource (an assignment), and the method (by ID, DELETE /assignments/{id}). It distinguishes this from sibling tools like runn_create_assignment or runn_delete_phase by focusing on assignments.
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 this tool is for deleting assignments, but it doesn't provide explicit guidance on when to use it versus alternatives or mention any prerequisites. It notes it's a hard delete, which subtly signals it's not for soft-delete scenarios, but this isn't fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the HTTP GET method, which signals a safe, read-only operation. However, it does not elaborate on response format, error behaviors, or authentication requirements, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the operation and the endpoint. No unnecessary 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 single-parameter GET tool, the description is adequately complete. It mentions the resource and how to identify it, and the lack of an output schema reduces the need to describe return values. It does not add context about when to use it vs. alternatives, but the simplicity of the operation makes that less critical.
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 projectId as 'Runn project ID' with 100% coverage. The description only refers to 'by ID' without adding further semantic detail 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 clearly states the tool fetches a single project by ID, using the specific verb 'Fetch' and identifying the resource as 'single project'. This distinguishes it from sibling tools like runn_list_projects and runn_update_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this when you have a project ID and need that specific project. It does not explicitly mention alternatives or exclusions, but the singular 'by ID' implies the usage scenario and differentiates it from list 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?
With no annotations, the description carries the full burden. It discloses the key behavioral nuance of projectId scoping and the underlying API endpoint. However, it does not mention pagination behavior (though the schema covers that), output ordering, or response structure, which could be valuable for an agent.
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 action 'List milestones', and uses a clear conditional structure to explain the two modes. Every word earns its place; 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?
Given the tool's simplicity, a list operation with four well-documented parameters and no output schema, the description is sufficiently complete. It covers the principal distinction (projectId vs. all projects) and leaves pagination details to the schema. Minor missing context like sorting order prevents a 5.
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 all four parameters, so the baseline is 3. The description adds minor context by showing the API endpoint for the project-scoped call, but it largely restates the projectId behavior already present in the parameter description. No additional meaning beyond the schema is provided.
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 'List milestones' with a specific verb and resource, and it distinguishes between project-scoped and all-project listing via the projectId parameter. This makes it unambiguous and differentiates from sibling list tools like runn_list_phases or runn_list_people.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: with projectId for a specific project's milestones, without it for all projects. It does not explicitly mention alternatives or exclusions, but given the lack of an alternative milestones-listing sibling, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the PATCH method and states 'Only provided fields change', which is useful partial-update semantics. Missing are details about error handling, return values, or permissions, so this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action ('Update a person or placeholder'), and every clause earns its place. It includes the endpoint, common use cases, and a key behavioral note without wasteful words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 6 parameters and no output schema or annotations. The description covers purpose, usage examples, and partial-update behavior, which is sufficient for basic invocation. However, it lacks details such as how to obtain personId, implications of null teamId, or expected response, leaving some gaps for a fully self-contained description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps parameters to use cases: firstName/lastName for renaming, email and team for changes, isArchived for archiving, and personId is implied by the resource path. This covers all six parameters with meaningful semantic context, exceeding the baseline.
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: 'Update a person or placeholder (PATCH /people/{id})'. It outlines specific use cases (rename placeholder, change email/team, archive) and distinguishes from sibling tools like runn_update_project or runn_create_placeholder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage scenarios: 'Use to rename a freshly created placeholder (firstName/lastName), change email/team, or archive.' This provides clear context for when to invoke the tool. However, it does not explicitly mention when not to use it or alternatives (e.g., using create_placeholder for creation), so it stops 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It discloses that the call is a POST with no body and that it should be done once, adding valuable context. However, it does not mention what happens if the workstream is already attached, error responses, 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?
Two short sentences deliver the action, endpoint, no-body requirement, and usage guidance without 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 simple two-parameter association operation, the description is largely complete: it explains purpose, endpoint, no body, and sequencing. It could be more complete with error/duplicate behavior, but the lack of an output schema and simple parameters make this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the endpoint template '/projects/{projectId}/project-workstreams/{workstreamId}/' in the description maps the two parameters to path positions, clarifying their roles. It also states 'existing workstream' and 'before allocating assignments' to convey the workflow context. More explicit per-parameter details would elevate it further.
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 ('Attach') and resource ('existing workstream to a project'), includes the HTTP endpoint, and clearly differentiates from siblings like 'remove_project_workstream' or 'create_workstream'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: 'Do this once per workstream/project before allocating assignments or actuals on that workstream.' This provides clear usage context and a sequencing constraint. It does not name alternatives or explicit 'when not' cases, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well by disclosing that workstreams are account-level, that assignments on the same person/role but different workstreams may overlap (Runn sums the load), and that the created id is used for later allocation. This is meaningful behavioral context beyond a simple 'create' statement, though it doesn't detail return formatting or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action. Each sentence provides distinct value: the HTTP endpoint, the definition and next step, the allocation path, and a caveat about overlap. 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 simple one-parameter create tool with no output schema, the description covers purpose, workflow, and a key behavioral nuance. It doesn't state what the response includes, but for a create the returned object with id is implied, and the complexity is low. The description is nearly complete for an agent to invoke and use the 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?
Schema coverage is 100% (the single 'name' parameter has a description). The tool description adds context about what a workstream is and how the id is used, but it does not elaborate further on the 'name' parameter itself. Baseline 3 is appropriate because the schema already documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a workstream (POST /workstreams)' — a specific verb and resource. It also defines a workstream as 'account-level bands of work' and distinguishes it from related create tools (project, phase, milestone) by clarifying that a workstream is attached to a project later via runn_add_project_workstream.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear sequential context: 'create one, then attach it to a project' and 'To allocate work to it, pass its id as workstreamId on runn_create_assignment / runn_bulk_actuals.' It does not explicitly state 'use this instead of X' or mention exclusions, but the workflow context is strong enough to guide correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that without projectId, the tool lists phases across all projects, which is a potentially large result set. It also exposes the REST endpoint. However, it does not mention pagination behavior, default page size, or whether fetchAll caps results, though these are in parameter descriptions. The scoping behavior is a useful addition, but not fully comprehensive.
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 with no fluff. It front-loads the core purpose ('List project phases') and then adds necessary scoping details. Every sentence earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no output schema, the description covers the essential behavior and scoping. It is complete enough for an agent to know what the tool does and how to use projectId. Pagination details are left to the parameter descriptions, which is acceptable. A minor gap is not mentioning that the tool supports pagination in the description, but the schema covers this, so overall it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema by explicitly stating the behavior when projectId is absent (lists phases across all projects) and providing the REST endpoint for the project-scoped query. This clarifies the default semantics in a way the schema description does not fully convey, so it earns a 4.
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 project phases, with a specific verb ('list') and resource ('phases'). It distinguishes between two scopes: with projectId, it lists that project's phases; without it, lists all projects' phases. This differentiates it from sibling list tools like runn_list_milestones or runn_list_assignments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to include projectId vs omit it, effectively providing usage guidance. However, it does not explicitly mention alternatives or when not to use this tool, though the scoping guidance is useful. This is clear context without exclusions, fitting a score of 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavior disclosure. It reveals three non-obvious behaviors: auto-naming after the role, the need for a follow-up update to rename, and automatic deletion within 24 hours without a project/assignment. This goes beyond simple CRUD semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundant phrasing. It front-loads the main action and places the deletion warning at the end. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-param creation tool with no annotations or output schema, the description covers the essential operational aspects: required field, auto-naming, follow-up, and deletion risk. It even implies the return value (the id) via the follow-up instruction. Slightly lacking is contextualization for tags and teamId, but the overall picture is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only costPerHour has a description). The description adds meaning for roleId by explaining auto-naming, but leaves tags and teamId undocumented. It does not compensate sufficiently for the low 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 function: 'Create a placeholder (POST /placeholders) for allocating external/contractor work.' It distinguishes from siblings by specifying the external/contractor context and the auto-naming behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage context by noting that only roleId is required and that a follow-up with runn_update_person is needed to give the placeholder a real name. It also includes the critical caveat about deletion within 24 hours if unassigned. However, it does not explicitly state when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses the HTTP method (GET) and that it is a read-only operation with no side effects, and states it returns the authenticated identity. It adds value beyond the empty schema, though it does not detail error behavior 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 short sentences, front-loaded with the purpose, and no unnecessary words. Every sentence 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 parameterless tool with no output schema, the description is complete. It covers the purpose, the HTTP call, and the return value, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100% (vacuously). The description does not need to add parameter semantics, and the baseline for zero-parameter tools is 4.
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 verifies the token/account and returns the authenticated identity, using a specific verb and resource (GET /me). This distinguishes it from sibling tools like runn_server_info, which are about server details rather than identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool is used to verify authentication and get the current user identity. However, it does not explicitly state when to use it over alternatives or provide exclusions, so it falls short of clear context with no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses three critical non-obvious traits: overwrite semantics (same project/person/role/date), validation requirement (either billable or nonbillable minutes > 0), and atomicity (none written if any entry invalid). This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences deliver purpose, behavior, and validation without any filler. The most important information is front-loaded, and each sentence 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 tool with a nested array schema and no output schema, the description covers the essential invocation semantics: limit, overwrite behavior, validation, and atomicity. It omits the response format or error handling, but the core operation is sufficiently described for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds the important validation rule and mentions the identifying fields (project/person/role/date), but does not explain all nested fields or required properties. The schema provides structure, but the description only partially fills the semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource statement ('Create or update up to 100 actuals') and specifies the endpoint (POST /actuals/bulk). It also distinguishes itself from sibling tools like runn_list_actuals by emphasizing the bulk write nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (bulk operations) by mentioning 'in one call' and the 100-item limit, but it does not explicitly name alternatives or exclusions. The context is clear enough without explicit 'use when' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explicitly says 'Hard delete', indicating irreversibility, and includes the HTTP DELETE method. It also notes the account-wide scope. This provides solid behavioral transparency, though it omits potential permission requirements 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 extremely concise, delivering the essential information in one short sentence. No unnecessary words or repetition. It front-loads the action and key attributes.
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 parameter and no output schema, the description provides key information: HTTP method, hard-delete behavior, and account-wide scope. It lacks a few details like required permissions or response format, but the tool's simplicity makes this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The URL pattern `DELETE /workstreams/{workstreamId}` clearly identifies `workstreamId` as the identifier used in the path. For a single integer parameter, this is sufficient to understand its meaning, though not explicitly phrased as 'the ID of the workstream to delete'.
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 workstream, with the HTTP method and resource path. It distinguishes from siblings like runn_create_workstream and runn_update_workstream by indicating a delete operation. The phrase 'account-wide' clarifies scope relative to tools like runn_remove_project_workstream.
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 this tool: when a workstream should be permanently deleted across the entire account. It differentiates from `runn_remove_project_workstream` via 'account-wide', but does not explicitly state exclusions or alternatives. The context is clear enough for an agent to select it over create/update/list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the HTTP method (DELETE), the precise effect (removes project link only), and the non-destructive nature toward the workstream. It does not cover error conditions or return format, but for a simple unlink operation, the key behavioral traits are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the action with the endpoint, the second clarifies the crucial side effect. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required integer parameters and no output schema, the description covers the core operation and its key nuance (not deleting the workstream). It lacks information about idempotency or error handling, but these are not essential for a straightforward detach operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by embedding the parameters in a URL template (/projects/{projectId}/project-workstreams/{workstreamId}), clarifying that projectId and workstreamId are path IDs. While it doesn't elaborate on their meaning, the endpoint context sufficiently conveys their roles.
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 ('Detach') and resource ('workstream from a project'), and clarifies the scope ('Removes the project link only; the workstream itself is not deleted.'). This fully distinguishes it from sibling tools like runn_delete_workstream, which deletes the workstream entirely.
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 implicitly tells when to use this tool by explicitly stating what it does NOT do ('the workstream itself is not deleted'), which contrasts with delete_workstream. However, it does not explicitly name alternatives or provide exclusion criteria, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It reveals that deletion may fail if the phase still has attached data and advises migrating first, which is valuable behavioral context beyond the bare 'delete' action.
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 action and endpoint, and every sentence adds value. 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 delete operation with two IDs, the description covers purpose, usage prerequisites, and failure mode. It lacks mention of return value or whether deletion is permanent, but these are arguably implied by 'Delete'. Given no output schema and no annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions the endpoint with {id} and {phaseId}, which implies both parameters, but does not explicitly define their meanings or types. The parameter names are self-explanatory, but the description could have clarified which ID corresponds to project vs phase.
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 "Delete a phase" with the HTTP endpoint, making the action and resource explicit. It distinguishes from sibling tools like create_phase and update_phase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool (after actuals/assignments have been migrated) and warns when it may fail (if attached data remains), including a 'migrate first' directive. This is clear when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: returns version and config, does not reveal the token, and does not call the API. This is exemplary transparency for a tool with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and then a critical safety clarification. Every word earns its place, and 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no input schema parameters, no output schema, and no annotations, the description provides a complete picture: what is returned, what is not returned, and that no external call is made. This fully satisfies the agent's need to use the tool correctly.
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 the rubric sets a baseline of 4. The description adds no parameter information because none is needed; it focuses on return value instead.
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 returns server version and effective configuration, listing specific fields. It explicitly distinguishes itself from siblings by noting it does NOT call the Runn API, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (whenever server info is needed) and provides a clear 'when-not' by stating it does not call the API. However, it lacks an explicit 'use this when...' statement or reference to alternatives, 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.

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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CodecoolGlobal/runn-mcp'

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