Skip to main content
Glama
Sign In
freee-mcp

freee-mcp

by newbdez33
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Preview a freee monthly attendance approval action

freee_monthly_approval_prepare_action
Read-onlyIdempotent

Review one exact monthly attendance closing application and build a fingerprint from its summary, daily records, alerts, and checks to prepare an approve, return, or cancel-approval action.

Instructions

Review one exact 月次勤怠締め application and bind its explicit payment month, freee-verified work month, detail, monthly summary, daily attendance, alerts, automatic checks, and requested approve, return, or cancel_approval action into a fingerprint. For an exact instruction or active scoped business policy, the Agent evaluates the complete review and matches the fingerprint without per-item user confirmation. Ambiguous mapping produces no fingerprint; no application is changed.

Input Schema

NameRequiredDescriptionDefault
idYesThe numeric No. shown in the freee application list.
actionYesapprove maps to 承認; return maps to 申請者へ差し戻す; cancel_approval maps to 承認を取り消す on an approved application and must verify 差戻し. Canceling approval requires a precise instruction for this application; an approve/return policy does not authorize it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.6.0
    • changedInput schema / properties / action / description
      Previous value: -"approve maps to 承認; return maps to 申請者へ差し戻す."New value: +"approve maps to 承認; return maps to 申請者へ差し戻す; cancel_approval maps to 承認を取り消す on an approved application and must verify 差戻し. Canceling approval requires a precise instruction for this application; an approve/return policy does not authorize it."
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "approve",
-  "return"
-]New value: +[
+  "approve",
+  "return",
+  "cancel_approval"
+]
  2. Addedv0.4.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint, and the description reinforces this non-destructively by stating "no application is changed" and that ambiguous mapping produces no fingerprint — a genuine failure-mode disclosure. It stops short of explaining what a fingerprint looks like or how it is subsequently consumed, which is the one behavioral detail an agent still needs.

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?

Purpose and confirmation policy are front-loaded across three tight sentences with no filler. The middle sentence's phrasing ("bind ... into a fingerprint", "matches the fingerprint") is dense jargon whose mechanics are never unpacked, costing a bit of clarity.

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 no output schema, the description carries the burden of explaining the return value, and it only says a fingerprint is produced without describing its form or how to use it downstream. The confirmation and ambiguity rules are well covered, but the missing output and handoff detail leaves the definition only marginally complete for a two-step prepare/commit flow.

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%, including a rich enum description for action, so the baseline is 3. The description's enumeration of payment month, work month, detail, daily attendance, alerts and automatic checks describes the review payload, not the two input parameters, so it adds little parameter meaning beyond the schema.

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

Purpose4/5

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

The description uses a specific verb and resource — "Review one exact 月次勤怠締め application and bind ... into a fingerprint" — which goes well beyond restating the title. However, it never names its near-siblings (freee_monthly_approval_review, freee_monthly_approval_commit_action), so an agent must infer the prepare/commit split from tool names alone.

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 gives an explicit operating rule: with an exact instruction or active scoped policy the agent may match the fingerprint without per-item confirmation, and ambiguous mapping yields no fingerprint. What is missing is an explicit statement that the fingerprint must then be handed to freee_monthly_approval_commit_action, so the workflow boundary is only implied.

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

Deploy Server

Other Tools