Skip to main content
Glama

TOISE — intelligence foncière

Quotas du jour, plan du compte et offres TOISE

toise_compte
Read-onlyIdempotent

Combien d'unités me reste-t-il aujourd'hui et quelles offres : état d'usage du compte. Quotas du jour, offres et coût de chaque outil. Ne modifie rien.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "toise_compte"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
planYes
liensNoLiens vers la fiche TOISE et vers des services de…
quotaNoQuota du jour après cet appel : { fonction, limite…
offresYes
quotasYesPar fonction comptée : { intitule, limite, utilise, restant…
unitesYesPlafond global d’usage : unités du jour…
curseurNo
partielNotrue : une source n’a pas répondu, des champs manquent…
sourcesYes
connecteYes
has_moreYes
warningsYes
cout_outilsYes
quota_unitesNoUnités d’usage du jour : consommees_par_cet_appel…
avertissementNo
remise_a_zeroNoProchain minuit UTC (ISO 8601), heure où les compteurs…
champs_absentsNoDonnées absentes du résultat partiel.
limite_atteinteNoPrésent quand un quota, une limite d’offre ou une fonction…
paiement_requisNoPrésent quand le résultat complet est un achat à l’acte…

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=false, so 'Ne modifie rien' merely restates structured data and earns no credit. What the description does add is the content scope (daily quota, offers, per-tool cost), which helps the agent know what it will get back, though no mention of auth, rate limits, or quota-refresh timing.

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?

At three short sentences it is not bloated, but the content overlaps heavily: 'Quotas du jour, offres' repeats the title and the first sentence nearly verbatim, and 'Ne modifie rien' is redundant with the annotations. The core information is front-loaded, but a third of the text is restatement.

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 zero-parameter, read-only status tool with full annotations and an output schema, the description supplies enough: what is returned (quota, plan/offers, per-tool cost) and confirmation that nothing is mutated. Return-value details are correctly left to the output schema, leaving only minor gaps such as quota reset timing.

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

Parameters4/5

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly does not invent arguments, and the empty schema is consistent with the account-scoped phrasing.

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 names a specific resource and scope: remaining daily units, account usage state, offers, and per-tool cost. It is clearly a read-only account-status lookup, distinguishable from the analytical siblings listed. It stops short of explicitly naming a sibling it is not, but the purpose is unmistakable.

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 opening question ('Combien d'unités me reste-t-il aujourd'hui') implies the use case of checking quota before consuming units, but no explicit when-to-use or when-not-to-use guidance is given, and no alternative is named. Usage is inferable rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources