RogerRoger MCP Server

Official

by RogerRogerHQ

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

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

Latest release: v1.0.3
Disambiguation5/5
Each tool targets a distinct resource (people, tasks, organizations, lists, tags) with a clear action (get_/create_/update_/delete_). No two tools appear to do the same thing. The distinction between get_people (all) and get_person (specific by ID) is clear.
Naming Consistency5/5
All tool names follow a strict verb_noun snake_case convention throughout: get_/create_/update_/delete_ as the verb prefix, followed by the resource name. The naming is perfectly predictable and consistent across all 22 tools.
Tool Count4/5
22 tools is at the high end but still reasonable for a CRM server covering 5 distinct resource types (persons, tasks, organizations, lists, tags) each with CRUD operations. The number is slightly heavy but each tool earns its place.
Completeness3/5
The people, organizations, lists, and tags resources have full CRUD coverage. However, tasks have only get_tasks and create_task - missing get_task by ID, update_task, and delete_task. This is a notable inconsistency in lifecycle coverage across resource types.
Average 2.9/5 across 22 of 22 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'delete' implies destructive action, the description doesn't state whether deletion requires confirmation, whether it cascades to related resources (people, tasks, lists), or whether it's reversible. For an organization that likely contains many dependent resources, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence), which is efficient but potentially under-specified. It doesn't actively waste words, but for a destructive operation with likely side effects, more content would be warranted—so this isn't exemplary conciseness, it's more under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool operating on an organization (likely a parent resource containing people, lists, and tasks per the sibling tools), the one-line description is insufficient. There's no output schema and no annotations to compensate, and the description doesn't convey the potential impact of orphaned or cascaded resources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single 'id' parameter is described as 'The ID of the organization to delete'), so the schema fully documents the only parameter. The description adds no extra semantic detail beyond what the schema provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an organization' states the verb (delete) and resource (organization) clearly. It distinguishes from sibling tools like delete_person and delete_list, though it's a minimal description that doesn't add scope or detail beyond what the tool name itself conveys.
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 or what prerequisites exist (e.g., whether the organization must have no members/tasks before deletion). Sibling tools like delete_list and delete_person exist but no exclusions or context are offered.
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 of behavioral disclosure. For a deletion tool, it doesn't state whether deletion is reversible, whether related records (people, tags, segments) are cascade-deleted, whether there are any dependencies that block deletion, or what happens to associated data. The term 'delete' implies irreversibility but offers no specifics about scope or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or repetition. It's appropriately short for a simple single-parameter deletion tool, though it could arguably do slightly more in the same space.
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?
This is a destructive operation (delete) with no annotations and no output schema. Despite having only one simple parameter, the description provides no detail on behavioral side effects, return values, or failure conditions. For a mutation tool with zero annotation coverage, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (id), and the schema already describes it as 'The ID of the list to delete.' The description adds essentially nothing beyond what the schema provides — it doesn't explain where to obtain the ID, whether it accepts objects/admin IDs vs regular list IDs, or format expectations. Baseline 3 is appropriate since the schema already covers the sole parameter fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a list/segment' states the verb (delete) and resource (list/segment), which is clear for basic purposes. However, it doesn't distinguish whether this is a soft or hard delete, and while sibling delete_* tools exist, the description is functionally identical to them in pattern, offering no differentiation beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., must the list be empty first?), consequences (e.g., does deleting a list remove its members from campaigns?), or when one might prefer using update_list instead. Zero context about when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not disclose whether deletion is permanent/irreversible, whether related references to the tag become invalidated, whether authorization/permissions are required, or what happens on success/failure. For a destructive mutation tool with zero annotation coverage, this is a significant gap.
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 efficient—three words, zero waste. It's appropriately short for a simple delete operation. However, this brevity is borderline under-specification rather than genuine conciseness, since critical behavioral details are omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, no output schema, and a single parameter, the description fails to cover critical context: irreversibility, cascading effects on tasks/other entities that reference the tag, and what error conditions might occur. The tool is simple in interface but the consequences of use are not disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the single 'id' parameter is fully documented in the schema as 'The ID of the tag to delete.' The description adds no additional meaning beyond the schema. Baseline 3 applies since the schema does the heavy lifting and there's only one self-explanatory parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Delete a tag'), and the sibling tools include get_tag, create_tag, update_tag, so the purpose is reasonably distinct. However, it doesn't go beyond the tool name itself—'Delete a tag' essentially restates the name without adding scope, constraints, or differentiating detail beyond what the name implies.
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's no mention of check-before-delete patterns (e.g., get_tag first), cascading effects, or whether deletion is permanent or reversible. Given sibling tools like get_tag and update_tag exist, some guidance on prerequisites or ordering would be valuable.
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 doesn't mention pagination behavior despite the schema having page/itemsPerPage parameters. It also doesn't disclose whether results are sorted, what fields each tag includes, whether it returns all data in one call or requires multiple pages, or the response format since there's no output schema.
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 concise at one short sentence. It is appropriately structured with no wasted words. However, it borders on under-specification rather than being optimally concise, which is why it doesn't reach a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-retrieval tool with 2 parameters and no output schema, the description is too sparse. It doesn't explain the pagination implications, response structure, or how this relates to the broader tag CRUD family (get_tag, create_tag, update_tag, delete_tag). A tag listing tool should at minimum mention pagination behavior and what data it returns.
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%, meaning both page and itemsPerPage have descriptions in the schema itself. The description adds nothing about parameter semantics beyond what the schema documents. Baseline of 3 is appropriate since the schema handles parameter documentation adequately, though the description itself contributes zero parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retrieve all tags from RogerRoger' with a clear verb+resource ('Retrieve all tags'). However, it doesn't differentiate from sibling tools like get_tag (singular) which likely retrieves a single tag, nor does it mention how it differs from other list tools. The schema's two pagination parameters imply it's a paginated list tool, but the description lacks this detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Although sibling get_tag exists, the description mentions no differentiation between fetching all tags versus a single tag. No context is provided about pagination usage, when filtering would be needed, or scenarios where another tool would be preferable.
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 of behavioral disclosure. It doesn't mention whether 'retrieve' limits to a certain user's tasks, whether results are sorted in a particular order, whether deleted/hidden tasks are included, or any rate limits. For a read operation with zero annotation coverage, this is a thin description.
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 concise at a single sentence. It's efficient and front-loaded, though it arguably errs on the side of being under-specified rather than genuinely focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (3 optional params, no output schema, no nested objects), the description is too sparse for the available context. No output schema means the description or schema should explain return format. No annotations means behavioral expectations need to come from the description. For a read tool with zero annotation coverage, more completeness is expected.
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 all three parameters (page, status, itemsPerPage) are documented in the schema. The description adds marginally by implying tasks can be retrieved with filtering/pagination, but doesn't add semantic meaning beyond what the schema offers. Baseline 3 is appropriate when schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Retrieve tasks from RogerRoger' which names the verb (retrieve) and resource (tasks) clearly. However, it does not distinguish from siblings like create_task or provide scope nuances beyond basic retrieval. It barely adds value over the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention pagination use cases, status filtering scenarios, or when to prefer this over other task-related tools. Without exclusions or when-not guidance, the agent gets minimal direction on appropriate 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 carries the full burden of behavioral disclosure. 'Update' implies mutation, but the description does not state whether updates are partial (only provided fields) or require all fields, whether the operation is idempotent, whether it requires ownership/permissions, or what the response looks like. For a mutation tool with zero annotation coverage, this is under-disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that communicates the core purpose without waste. It is appropriately concise but leaves room for more behavioral/usage detail that would be valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is notably thin. It doesn't clarify the update semantics (full vs partial update), the meaning of 'segment' in the description, requirements around the required fields, or whether sequence is optional for a reason. With 4 parameters and mutation semantics, more context should be provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters with descriptions. The description adds nothing beyond the schema: it doesn't clarify the 'icon' values, what 'sequence' affects, or how id, title, and icon relate. Baseline 3 is appropriate when the schema carries the parameter documentation load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing list/segment' states the verb (update) and resource (list/segment), which is clear enough. However, it doesn't distinguish details from sibling update_* tools beyond naming the resource, and the sibling set includes delete_list, create_list, get_list, get_lists - so context helps. The verb+resource is specific, so purpose is mostly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (create_list, delete_list, get_list). It doesn't mention when lists should be created vs updated, when a list must exist first, or any prerequisites such as needing an existing ID. No exclusions or alternatives are named.
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 of behavioral disclosure. 'Update' implies mutation but the description doesn't state whether partial updates are supported, what happens to unspecified fields, whether there are access/permission requirements, or what the response format is. For a mutation tool with zero annotation coverage, this is a significant gap.
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, efficient sentence with zero waste. It's appropriately minimal, though it could be argued it's under-specified rather than concise. However, for a simple update tool, this brevity is acceptable.
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?
This is a mutation tool with no annotations and no output schema, yet the description provides minimal context. It doesn't mention partial-vs-full update behavior, required fields beyond the ID (which the schema doesn't specify as required either), or any side effects. Given six parameters and a mutation nature, the description should provide more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters clearly. The description adds no parameter-specific meaning beyond 'Update an existing organization.' Baseline 3 is appropriate since the schema handles the heavy lifting and the description title accurately reflects the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing organization' uses a specific verb+resource combination that clearly indicates the mutation operation. However, it doesn't specify which fields can be updated or differentiate from sibling tools like update_person or update_list, though the resource name implicitly distinguishes it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like create_organization or delete_organization. No context about preconditions such as needing the organization to already exist or how to obtain the id. The description simply states the operation without 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 carries full behavioral burden. 'Create' implies a write/mutation operation, but the description doesn't disclose whether creation has side effects, whether icon values are validated against a set, what happens with the optional sequence parameter, or what the response/return behavior is. For a creation tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is brief and front-loaded with the action. No wasted words. However, it's arguably under-specified for a creation tool—brevity here borders on minimalism rather than impactful conciseness, but there's no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation/creation tool with no annotations, no output schema, and a 'list/segment' concept that suggests possible data model nuances (list vs segment distinction could have different semantics), the description is thin. It doesn't address what distinguishes a list from a segment, whether special characters or constraints on titles exist, or the behavior of the optional sequence field. Given this tool creates an entity, more context would meaningfully aid correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three parameters are documented in the schema. The description doesn't add additional meaning beyond what the schema provides—it doesn't explain what the icon identifier references, how sequence ordering behaves, or any constraints. Baseline 3 is appropriate since schema handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new list/segment' with a clear verb (Create) and resource (list/segment), and identifies the owner platform (RogerRoger). It's clear and distinct from sibling tools like get_lists/update_list/delete_list, though it doesn't explicitly differentiate itself from create_tag/create_organization, the resource type is sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as create_tag or create_organization. There's no statement about prerequisites (e.g., whether an icon is validated) or exclusions. The description provides no context for when a list should be created versus updating an existing one via update_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden of behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't note whether duplicate names are rejected, whether creation is idempotent, what happens on failure, or whether the tool returns the created object's ID. For a mutation tool with zero annotation coverage, this is a significant 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 short sentence that states the exact purpose with no wasted words. For a CRUD creation tool, this length is appropriate given the schema already documents all parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description should disclose return behavior, error cases, or post-creation state (e.g., does it auto-assign relationships?). None of that is present. The 5-parameter, 0-required tool would benefit from guidance on which fields matter, but the description stops at the bare statement of purpose.
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 all 5 parameters are already documented in the schema. The description adds no parameter-level detail beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting; the description offers nothing extra for parameter understanding.
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?
Description uses a specific verb ('Create') plus resource ('a new organization in RogerRoger'), clearly stating the action. It distinguishes from siblings like update_organization and delete_organization by the create verb, though it doesn't explicitly name alternatives. Clear enough for basic selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention prerequisites (e.g., whether you need to check if the org already exists), nor excludes scenarios where another tool would be better. All parameters optional (0 required) but no hints on which are commonly needed.
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 (no readOnlyHint, destructiveHint), so the description carries the full burden of behavioral disclosure. 'Create' implies mutation, but the description doesn't state whether this requires authentication, whether it's idempotent, what happens if a person with the same name/email already exists, or whether it triggers any side effects. For a write operation with zero annotation coverage, this is a significant transparency 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?
The description is a single efficient sentence: 'Create a new person/contact in RogerRoger'. It's appropriately front-loaded with the verb and resource, contains zero filler, and every word earns its place. Minimalist but not under-specified at the purpose level.
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?
This is a mutation tool with no annotations, no output schema, and a description that only states the basic purpose. It doesn't describe the expected return value (e.g., created person object with ID), any validation rules, how duplicates are handled, or permission/auth requirements. While the schema documents the 5 parameters adequately, the overall contextual picture for a create operation is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema descriptions (name, email, notes, phone, company) are self-evident — each parameter has a clear one-line description in the schema. The tool description adds no parameter-level information beyond what the schema provides, but the baseline of 3 applies since the schema fully covers all 5 parameters. However, the description doesn't indicate which (if any) fields are essential, since there are 0 required parameters.
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 'Create a new person/contact in RogerRoger' uses a specific verb ('Create') and resource ('person/contact') and places it in the context of the RogerRoger system. It clearly distinguishes from siblings like get_person, update_person, and delete_person based on the verb. However, it doesn't elaborate on what fields are essential or any constraints, so it's clear but not maximally specific.
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's no mention of prerequisites, when not to use it, or how it differs from create_task, create_organization, create_list, or create_tag. The sibling tools like update_person suggest an obvious companion use case, but this is only implied. The description provides no exclusions or alternative guidance.
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 of behavioral disclosure. 'Create' implies mutation (adds a new resource), but the description doesn't disclose whether creating is idempotent, whether duplicate titles are rejected, what happens on success/failure, or whether any side effects occur. For a mutation tool with zero annotation coverage, this is a meaningful gap.
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 efficient sentence that conveys the core purpose with zero wasted words. However, it may be slightly under-specified given the tool has four parameters and zero annotation coverage, but as a concise purpose statement it's appropriately brief.
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 annotations, no output schema, four parameters, and mute sibling context, the single-sentence description is insufficient. The tool creates a resource and the description provides no information about return values, error handling, validation rules, or when/why to use it. For a mutation tool with zero annotation coverage, this is a notable completeness deficit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description itself adds no parameter information beyond what the schema provides. Per guidelines, baseline 3 applies when schema does the heavy lifting. The description adds no additional semantic context like format constraints or defaults that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with a clear resource ('a new tag in RogerRoger'). It clearly communicates the action and scope. However, it doesn't distinguish itself from sibling tools beyond identifying which resource it targets, and the sibling set includes update_tag and delete_tag so the purpose is adequately clear but not elaborate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The sibling set includes get_tags/create_tag/update_tag/delete_tag, and the description offers no context on when creating is appropriate, prerequisites (e.g., does a tag require an organization or list context?), or what conditions should be met before invocation. No exclusions or alternatives noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. 'Create' implies mutation and returns the created resource (or an error), but the description doesn't state whether created tasks require a list, what happens with validation failures, whether assignee_id must reference an existing person, or what the response shape is. For a mutation tool with zero annotation coverage, this is a significant gap.
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 an efficient single sentence with zero wasted words. It's appropriately brief for a tool whose parameters are fully documented in the schema. Could add a bit more context but is not bloated.
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 annotations, no output schema, and the description provides only a minimal sentence. For a creation tool with 5 parameters (including an assignee_id that likely references the people resource), the description should clarify return behavior, validation rules, required relationships, and default behaviors. Schema covers parameter meaning but not operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema itself documents all 5 parameters with descriptions. Each parameter has a clear description (e.g., 'Task priority (low, medium, high)'). The description adds nothing beyond the schema beyond identifying it as a task creation operation with a required title, which is baseline-3 territory given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new task in RogerRoger' has a clear verb (create) and resource (task), specifying the action and the system context. It doesn't fully distinguish from sibling tools since there is no create_task sibling among the listed tools, but the verb+resource pairing is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description doesn't mention whether valid assignee IDs must come from get_people, whether the task should belong to a list, or any prerequisite relationships with sibling resources. The agent must infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (delete) which implies destruction, but does not disclose whether the operation is permanent/reversible, what happens to associated data (contacts' linked tasks, organizations, or lists), or require any confirmation. For a destructive operation with zero annotation coverage, this is a significant 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?
The description is a single, efficient sentence with zero waste. It front-loads the verb and resource clearly. In terms of brevity, it's perfectly economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is inadequate. It should disclose whether the operation is irreversible, whether deletion cascades to related records (tasks, contacts in organizations/lists), and what the response looks like on success or failure. Given sibling tools like delete_organization and delete_list exist, clarifying scope of deletion would be especially valuable. The single-sentence description does not satisfy the completeness burden for a destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the 'id' parameter is already documented by the schema ('The ID of the person to delete'). The description adds no additional meaning about the parameter beyond what the schema provides, hitting the baseline of 3. No value clarification is needed since there's only one clear parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb-resource pair ('Delete a person/contact') that precisely states what the tool does. It aligns with the sibling naming and clearly differentiates from get/create/update_person operations. However, it doesn't add significant scope information beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. There are no hints about what situations warrant deletion, whether delete is irreversible, or any conditions that should be checked before invoking. This is a bare minimum that gives no 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 carries the full burden of behavioral disclosure. It names the resource ('lists/segments from RogerRoger') but doesn't state pagination limits (max 30 items per page), what happens if no lists exist, or whether this is a read-only operation (though 'Retrieve' implies read-only). The alternative term 'segments' adds useful context about what these objects represent.
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, efficient sentence with zero wasted words. It's front-loaded with the action verb and resource. Could arguably be slightly more informative without violating conciseness, but the current form is appropriately terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with pagination, key information is missing: there's no output schema explaining the response structure, no mention of sorting/ordering, and no note about pagination defaults beyond what the schema provides. The schema documents parameters well, but the description doesn't clarify behavior around the 'lists/segments' naming (are these email marketing lists? CRM segments? The term 'RogerRoger' is unexplained).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (page and itemsPerPage) with defaults and max values. The description adds no additional parameter meaning beyond what the schema provides, but given the high coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all lists/segments from the system, using a specific verb + resource. It's distinct from sibling tools (get_list for single, create_list/update_list for mutations), though it doesn't explicitly differentiate from get_list in the description itself.
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. It doesn't mention pagination behavior in prose, alternative filtering approaches, or when one might prefer another tool. 'All lists/segments' implies full retrieval, but there's no explicit context about trade-offs vs get_list.
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 of behavioral disclosure. It doesn't mention whether this is a read-only operation, whether results are paginated by default, what the response shape looks like, or any rate limits. The 'all organizations' phrasing implies a full listing but no behavioral detail beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the purpose. No wasted words or redundant information. Could not be meaningfully shorter while retaining its message, making this an appropriately sized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively simple filtered-list tool with 100% schema coverage and no output schema. The description covers the core purpose adequately. However, with no annotations and no output schema, slightly more context about the return format or pagination default behavior would improve completeness. The schema documents parameters well, so the overall package is functional but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 3 parameters (q, page, itemsPerPage). The description's mention of 'all organizations' and the schema's 'Search query to filter' add some context on how q narrows the result set, but the description itself adds no parameter info beyond what the schema provides. Baseline 3 applies since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pattern ('Retrieve all organizations from RogerRoger CRM'), clearly stating the action and source system. It distinguishes from the singular sibling get_organization since it retrieves all organizations, though it doesn't explicitly contrast with that sibling.
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 vs alternatives. It doesn't mention that get_organization exists for retrieving a single organization, nor any pagination hints beyond what the schema provides. Context on 'all' vs specific lookup scenarios is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of behavioral disclosure. The description only says 'Update an existing person/contact' and gives no detail on behavioral traits: partial-update semantics, whether missing optional fields null out existing values, permission requirements, or whether the operation is reversible. 'Update' implies mutation but the description adds essentially nothing beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero wasted words. It's appropriately front-loaded and concise for its purpose.
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 annotations and no output schema, the description is underspecified for a mutation tool. It has 6 params (5 mutable) and no behavioral detail about update semantics. The description is adequate at a high level but should clarify whether this is a full-replace or patch-style update, which is critical for an agent deciding how to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all 6 parameters. However, the description adds no parameter semantics beyond what the schema already provides. It doesn't indicate which fields are mutable in update context, whether partial updates are supported, or any constraints. Baseline 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Update an existing person/contact'. It clearly distinguishes from siblings like create_person and delete_person, and complements get_people/get_person. The mention of 'existing' clarifies it operates on records that already exist, differentiating from create_person.
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. It doesn't mention that id is required, what happens with partial updates (whether unspecified fields are preserved or cleared), or when to prefer create_person over update_person. The context is implied but no explicit exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries some burden. The description implies mutation but doesn't disclose whether the update is partial (PATCH-like) or full replacement, what happens to fields not specified, or whether tags can be renamed freely. It's somewhat transparent about being a mutation but lacks depth on update mechanics and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It's appropriately concise given the schema already carries the parameter details. Could arguably be slightly more detailed about what 'update' entails, but for conciseness this is well-calibrated.
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?
This is a mutation tool with no output schema and no annotations. The description is thin—it doesn't explain partial vs full update semantics, whether all optional fields must be provided together, potential validation failures on the title field, or whether missing optional fields are reset to defaults. For a write operation, this leaves meaningful ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all 5 parameters with meaningful descriptions. The description itself adds no parameter information beyond the schema, which is acceptable per the baseline-3 rule when schema coverage is high. The schema provides field-level semantics adequately.
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 'Update an existing tag' uses a specific verb plus resource, clearly indicating this tool modifies an existing tag. It doesn't explicitly differentiate from siblings, but the creation/deletion siblings have distinct names (create_tag, delete_tag), so the purpose is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't mention required fields, partial update semantics (whether unspecified optional fields are preserved or cleared), or any preconditions like the tag needing to exist. Around the same domain, create_tag/delete_tag are alternative operations but no usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It states it's a read operation ('Retrieve'), which is safe, but doesn't mention pagination limits (max 30, default 15 from schema), default behavior with no query, or whether results are ordered. For a read tool this is acceptable basic transparency but lacks richer context.
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?
Single concise sentence that clearly states the tool's purpose. No waste, no fluff. Efficient and to the point, though it could arguably include a bit more usage detail without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only collection tool with fully documented parameters, the description is adequate but minimal. With no annotations and no output schema, it could mention pagination requirements or result format. It's not incomplete enough to be problematic but doesn't add safety or expectation context beyond what's obvious.
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 all three parameters (q, page, itemsPerPage) are documented in the schema. The description adds 'filter by name, email, or other fields' context for q but the schema already explains these. Baseline 3 is appropriate since the schema does the heavy lifting and description adds minimal extra value.
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?
Clear verb+resource: 'Retrieve all people/contacts from RogerRoger CRM'. Distinguishes from siblings like get_person (singular) and create/update/delete operations. However, it doesn't explicitly distinguish from get_person or note that this is the plural/list operation, though 'all people/contacts' implies it.
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 is for retrieving a collection of people, which is differentiated by siblings (get_person is singular). But there's no explicit guidance on when to choose this over get_person, no mention of pagination behavior, and no mention that q is optional for full listing. Usage context is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states it retrieves a list but doesn't disclose what the returned structure contains, edge cases (e.g., behavior for non-existent IDs), or any filtering/scoping constraints. This is a significant gap given zero annotation 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?
A single concise sentence that is completely front-loaded with the essential information. No filler, no redundancy, no waste. 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 single-parameter retrieval tool, the description is mostly adequate. The tool has no output schema and no annotations, so the description could note what the returned list/segment object looks like. Given the tool's simplicity and full schema coverage, the gaps are minor but the lack of any return-value context keeps it from scoring higher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'id' parameter fully. The description adds the semantic nuance that 'id' refers to a list/segment identifier, complementing rather than repeating the schema. With only one parameter and full coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Retrieve a specific list/segment by ID'). It distinguishes from sibling tools like get_lists (plural, which retrieves all lists) and create_list/update_list/delete_list. Could be slightly more explicit about the list/segment relationship but purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it retrieves a specific single entity, implying it's used for single-item retrieval by ID, contrasting with get_lists for all lists. However, there's no explicit when-not-to-use guidance or mention of alternatives. The 'list/segment' phrasing hints at dual identity but doesn't clarify when to use each.
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. The description does not reveal anything beyond the basic retrieve behavior—no information about error cases (e.g., what happens for a non-existent ID), read-only nature, authentication, or return format. However, 'Retrieve' clearly implies a non-destructive read, which is somewhat self-evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero wasted words. Efficient and front-loaded. There is nothing extraneous in this description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-tag retrieval tool with one documented parameter and no output schema. For a simple read operation, the description is near-adequate. However, with no annotations and no output schema, it could benefit from stating what is returned or handling of not-found cases. Given minimal complexity, it is reasonably complete but leaves a few 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?
Schema description coverage is 100%, so the schema documents the single parameter ('id': 'The ID of the tag to retrieve'). The description adds no additional parameter context beyond what the schema already provides. Baseline 3 is appropriate when the schema handles the documentation.
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 'Retrieve a specific tag by ID' clearly states the verb (retrieve), the resource (tag), and the scoping (by ID). It distinguishes from sibling get_tags (list all) by singling out an individual tag. Clear and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_tags (which presumably lists all tags). No exclusions or context provided. The description implies usage (retrieving a single tag) but there is no explicit comparison or selection help.
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 of behavioral disclosure. The description only says 'Retrieve a specific organization by ID' and does not mention return format, whether it throws for missing IDs, error behavior, or any side effects. For a read-only lookup tool this is minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, front-loaded with the verb and resource. Appropriately concise for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter read-only retrieval tool. The description plus schema is largely sufficient for an agent to invoke it correctly. It could benefit from noting return format, but for a simple lookup with 100% schema coverage this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single 'id' parameter described as 'The ID of the organization to retrieve.' The description adds essentially no new meaning beyond the schema. Baseline 3 applies since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Retrieve') and resource ('a specific organization by ID'). It distinguishes from get_organizations (plural, list) and create/update/delete variants. Clear purpose.
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 retrieves a single organization by ID, which distinguishes it from get_organizations (list). However, it does not explicitly state when to prefer this over alternatives or mention any pruning/excluded scenarios.
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, but it only states the basic operation. For a read-only lookup tool this is relatively low-risk, so the absence of annotation coverage is somewhat mitigated. However, it doesn't disclose any behavior like null returns, errors on missing IDs, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with zero wasted words. It's appropriately sized for a simple one-parameter lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter get-by-ID tool with full schema coverage and no output schema, this is reasonably complete. The description plus schema cover the essentials. One could argue for error/not-found behavior notes, but for this simple tool the coverage is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single 'id' parameter fully described in the schema as 'The ID of the person to retrieve.' The description adds no new semantic content beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') with a clear resource ('person') and scope ('by ID'). It clearly distinguishes from siblings like get_people (plural, retrieves all) and get_tasks. While it's clear, it doesn't explicitly contrast against sibling retrieval tools, which keeps it at a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a basic lookup use case (retrieving by ID) but provides no explicit guidance on when to use vs. get_people, or any context like error behavior when ID doesn't exist. It's adequate but minimal—clear context for a simple lookup tool, but no exclusions or alternative tool mentions.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RogerRogerHQ/rogerroger-mcp-server'

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