Dayze — Life Context

Log Project KPI

log_project_kpi

Record a KPI value for one of the user's projects: project_slug or project_name, kpi_key (mrr, users), value; label, unit (usd, count, percent), target and floor define a new KPI. ($0.10; API key required)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kpi_key": "<kpi_key>",
      "value": "<value>"
    },
    "name": "log_project_kpi"
  }
}

Input Schema

Name	Required	Description
`note`	No	Note about this reading, e.g. Includes the annual plan.
`unit`	No	KPI unit: usd, count or percent, e.g. usd.
`floor`	No	KPI floor below which it is off track, e.g. 1000.
`label`	No	Short label, e.g. Monthly recurring revenue.
`value`	Yes	KPI value, e.g. 12500.
`target`	No	KPI target value, e.g. 20000.
`kpi_key`	Yes	Stable KPI key, e.g. mrr.
`request_id`	No	Client idempotency key (retries return original result).
`project_name`	No	Project name, e.g. Dayze Mobile.
`project_slug`	No	Project slug, e.g. dayze-mobile.
`idempotency_key`	No	Alias for request_id.

Output Schema

Name	Required	Description
`value`	No
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`kpi_key`	No
`message`	No
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`project_slug`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedNov 9, 2026
- addedInput schema / properties / floor / description
```
Added value: +"KPI floor below which it is off track, e.g. 1000."
```
- addedInput schema / properties / kpi_key / description
```
Added value: +"Stable KPI key, e.g. mrr."
```
- addedInput schema / properties / label / description
```
Added value: +"Short label, e.g. Monthly recurring revenue."
```
- addedInput schema / properties / note / description
```
Added value: +"Note about this reading, e.g. Includes the annual plan."
```
- addedInput schema / properties / project_name / description
```
Added value: +"Project name, e.g. Dayze Mobile."
```
- addedInput schema / properties / project_slug / description
```
Added value: +"Project slug, e.g. dayze-mobile."
```
- addedInput schema / properties / target / description
```
Added value: +"KPI target value, e.g. 20000."
```
- addedInput schema / properties / unit / description
```
Added value: +"KPI unit: usd, count or percent, e.g. usd."
```
- addedInput schema / properties / value / description
```
Added value: +"KPI value, e.g. 12500."
```
AddedNov 5, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations declare a non-read-only, non-destructive, closed-world write; the description goes beyond them by disclosing cost ("$0.10") and an API key requirement, plus the side effect that label/unit/target/floor create a new KPI. It omits what happens on a repeated kpi_key or how the idempotency key behaves, which the schema covers but the description does not reinforce.

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 dense sentence front-loads verb and resource, then walks parameters in the order an agent supplies them, with cost and auth appended in parentheses. No filler; every clause carries either a parameter grouping or an operational constraint.

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?

With 11 parameters, a 100% documented schema and an output schema, the heavy lifting is done elsewhere, and cost/auth/create-behavior are covered. The gap is the create-versus-record distinction: an agent cannot tell from this text whether re-posting an existing kpi_key with different target/floor mutates the definition or is rejected.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description groups the parameters into an identifier pair, a value triple, and a definition set, and gives enum examples (mrr, users; usd, count, percent), but it does not resolve whether project_slug and project_name are alternatives or both optional, which the schema leaves ambiguous.

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?

"Record a KPI value for one of the user's projects" gives a specific verb (record) and resource (KPI value scoped to a project), which is enough to separate it from the log_* siblings that target other domains. It stops short of distinguishing itself from a hypothetical KPI-listing or KPI-update tool, but the resource is concrete.

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 through "project_slug or project_name" (either identifier works) and through "label, unit, target and floor define a new KPI", which hints at a create-definition path. It never states when to prefer this over other logging tools, what to do if the KPI already exists, or when the defining fields should be omitted.

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

All Dayze — Life Context tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.