Skip to main content
Glama

SUNAGO Matrix

by com.sunago-matrix

Repair 0-cost time entries

timelog_recalculate_cost
Idempotent

Repair time entries whose historical_cost_price_per_hour was stamped as 0 because the employee had no salary data when the time was logged. Re-stamps them from the employee's CURRENT cost_price_per_hour. Only touches entries that are 0 or null - entries with a real rate are never overwritten. Runs as a preview by default: pass dry_run: false to actually write. Requires 'time.approve'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNotrue (default) reports what WOULD change without writing. Pass false to apply.
to_dateNoISO date YYYY-MM-DD. Only entries on or before this date.
from_dateNoISO date YYYY-MM-DD. Only entries on or after this date.
employee_idNoLimit the repair to one employee. Omit to cover the whole workspace.

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations by disclosing that the tool runs as a preview by default, requires 'time.approve' permission, and never overwrites entries with real rates. This provides rich behavioral context that the annotations alone do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the core purpose, and each sentence adds essential information: target condition, data source, safety guardrail, preview behavior, and required permission. 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?

The description covers the purpose, scope, write behavior, and permission requirement. Since there is no output schema, a brief mention of what the preview returns could strengthen it, but the description is already sufficient for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter already has a clear description. The tool description adds context about dry_run behavior, but does not need to restate the parameter details since the schema fully documents them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific repair action: re-stamping zero-cost time entries with the employee's current cost rate. It differentiates this from general timelog update tools by specifying the exact target condition (historical_cost_price_per_hour was 0 or null) and the source of the new value.

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 use the tool: only for entries stamped 0 due to missing salary data, and only those with 0/null rates are touched. It does not explicitly name alternative tools like timelog_update_entry, but the scoping is precise enough that an agent can decide when this is the correct tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SUNAGO Matrix toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0
Disambiguation4/5

Most tools follow a clear resource+action pattern and the descriptions are unusually precise about boundaries. A few near-overlaps remain: projects_get_finance vs projects_get_financials, and notes_create vs crm_log_activity on a deal are both plausible for recording a note on a deal.

Naming Consistency4/5

The domain_prefix_action convention is consistent across nearly all tools, e.g. crm_create_lead, projects_update_risk, timelog_approve_time. Deviations include standalone list_trash, meta tools like whoami/tool_search/tool_invoke, and the confusing projects_get_finance/projects_get_financials pair.

Tool Count1/5

With 105 tools, this far exceeds the 50+ threshold defined as an extreme mismatch. Even for a full ERP/CRM suite, the fine-grained split—39 project tools alone—creates a massive tool-selection surface that is hard for an agent to navigate reliably.

Completeness4/5

The surface covers CRM, projects, tasks, time/expenses, HR, notes, notifications, contracts, and reporting with create/read/update/delete for most primary entities. Minor gaps exist: crm_log_activity has no read-back path, contracts lack delete/restore, and proposals are intentionally read-only, but agents can work around these.

Resources